On Tue, Aug 06, 2024 at 12:35:44PM +0800, Jason Wang wrote:
> On Fri, Aug 2, 2024 at 6:00 PM Louis Peens wrote:
> >
> > From: Kyle Xu
> >
> > Add a new kernel module ‘nfp_vdpa’ for the NFP vDPA networking driver.
> >
> > The vDPA driver initializes th
of kernel vDPA framework.
Signed-off-by: Kyle Xu
Signed-off-by: Louis Peens
---
MAINTAINERS| 1 +
drivers/vdpa/Kconfig | 10 +
drivers/vdpa/Makefile | 1 +
drivers/vdpa/netronome/Makefile| 5 +
drivers/vdpa/netronome
ialized
as auxiliary device and registered to the auxiliary bus. Otherwise
the VF device will be initialized as PCI VF device as usual.
Signed-off-by: Kyle Xu
Signed-off-by: Louis Peens
---
drivers/net/ethernet/netronome/Kconfig| 1 +
drivers/net/ethernet/netronome/nfp/nfp_net.h |
e true cmode runtime
devlink dev param set pci/:01:00.0 \
name enable_vnet value false cmode runtime
devlink dev param show pci/:01:00.0 name enable_vnet
Signed-off-by: Kyle Xu
Signed-off-by: Louis Peens
---
.../ethernet/netronome/nfp/devlink_param.c| 49
This is the first foray into upstreaming a vDPA driver for the nfp.
Submitting it as RFC initially, since this is touching a new component,
not sure if there are potentially any new-to-us requirements this needs
to fulfill. We are hoping that this is already in a state to
resubmit as PATCH, dependi
On 2021/03/26 18:58, Marcelo Leitner wrote:
> On Tue, Mar 16, 2021 at 05:12:22PM +0200, Louis Peens wrote:
>> So in the end I think there are two problems - the on you identified with
>> only checking
>> the mask in commit 1bcc51ac0731. And then the second bigger one is t
On 2021/03/16 09:00, wenxu wrote:
>
> On 3/15/2021 11:29 PM, Louis Peens wrote:
>> Hi Marcelo
>>
>> Thanks for taking time to take a look. I've replied inline - and also found
>> a bit more info, although I'm not sure if it clears things up much. I do
.
Regards
Louis
On 2021/03/15 17:29, Louis Peens wrote:
> Hi Marcelo
>
> Thanks for taking time to take a look. I've replied inline - and also found
> a bit more info, although I'm not sure if it clears things up much. I do think
> that the main problem is the different u
ction as that is common conntrack code. I suspect
that ideally this is something we can try and address from the OVS side,
but at this moment I have no idea how this will be achieved, hence this
email.
Looking forward to get some suggestions on this
Regards
Louis Peens
PS: Tested on:
net-next k
From: Louis Peens
emit_obj_refs_json needs to added the same as with emit_obj_refs_plain
to prevent segfaults, similar to Commit "8ae4121bd89e bpf: Fix bpftool
without skeleton code enabled"). See the error below:
# ./bpftool -p prog
{
"error": "
From: Louis Peens
The 'fw_load_policy' devlink parameter supports the 'disk' value
since kernel v5.4, seems like there was some oversight in adding
this to iproute, fixed by this patch.
Signed-off-by: Louis Peens
Reviewed-by: Simon Horman
---
devlink/devlink.c | 5
11 matches
Mail list logo
