[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y8czKD8/yXywbl+f@lore-desk>
Date: Wed, 18 Jan 2023 00:45:44 +0100
From: Lorenzo Bianconi <lorenzo@...nel.org>
To: Niklas Söderlund
<niklas.soderlund@...igine.com>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, ast@...nel.org,
daniel@...earbox.net, andrii@...nel.org, davem@...emloft.net,
kuba@...nel.org, hawk@...nel.org, pabeni@...hat.com,
edumazet@...gle.com, toke@...hat.com, memxor@...il.com,
alardam@...il.com, saeedm@...dia.com, anthony.l.nguyen@...el.com,
gospo@...adcom.com, vladimir.oltean@....com, nbd@....name,
john@...ozen.org, leon@...nel.org, simon.horman@...igine.com,
aelior@...vell.com, christophe.jaillet@...adoo.fr,
ecree.xilinx@...il.com, mst@...hat.com, bjorn@...nel.org,
magnus.karlsson@...el.com, maciej.fijalkowski@...el.com,
intel-wired-lan@...ts.osuosl.org, lorenzo.bianconi@...hat.com
Subject: Re: [RFC v2 bpf-next 2/7] drivers: net: turn on XDP features
> Hi Lorenzo and Marek,
>
> Thanks for your work.
>
> On 2023-01-14 16:54:32 +0100, Lorenzo Bianconi wrote:
>
> [...]
>
> >
> > Turn 'hw-offload' feature flag on for:
> > - netronome (nfp)
> > - netdevsim.
>
> Is there a definition of the 'hw-offload' written down somewhere? From
> reading this series I take it is the ability to offload a BPF program?
correct
> It would also be interesting to read documentation for the other flags
> added in this series.
maybe we can add definitions in Documentation/netlink/specs/netdev.yaml?
>
> [...]
>
> > diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
> > b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
> > index 18fc9971f1c8..5a8ddeaff74d 100644
> > --- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
> > +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
> > @@ -2529,10 +2529,14 @@ static void nfp_net_netdev_init(struct nfp_net *nn)
> > netdev->features &= ~NETIF_F_HW_VLAN_STAG_RX;
> > nn->dp.ctrl &= ~NFP_NET_CFG_CTRL_RXQINQ;
> >
> > + nn->dp.netdev->xdp_features = NETDEV_XDP_ACT_BASIC |
> > + NETDEV_XDP_ACT_HW_OFFLOAD;
>
> If my assumption about the 'hw-offload' flag above is correct I think
> NETDEV_XDP_ACT_HW_OFFLOAD should be conditioned on that the BPF firmware
> flavor is in use.
>
> nn->dp.netdev->xdp_features = NETDEV_XDP_ACT_BASIC;
>
> if (nn->app->type->id == NFP_APP_BPF_NIC)
> nn->dp.netdev->xdp_features |= NETDEV_XDP_ACT_HW_OFFLOAD;
ack, I will fix it.
>
> > +
> > /* Finalise the netdev setup */
> > switch (nn->dp.ops->version) {
> > case NFP_NFD_VER_NFD3:
> > netdev->netdev_ops = &nfp_nfd3_netdev_ops;
> > + nn->dp.netdev->xdp_features |= NETDEV_XDP_ACT_XSK_ZEROCOPY;
> > break;
> > case NFP_NFD_VER_NFDK:
> > netdev->netdev_ops = &nfp_nfdk_netdev_ops;
>
> This is also a wrinkle I would like to understand. Currently NFP support
> zero-copy on NFD3, but not for offloaded BPF programs. But with the BPF
> firmware flavor running the device can still support zero-copy for
> non-offloaded programs.
>
> Is it a problem that the driver advertises support for both
> hardware-offload _and_ zero-copy at the same time, even if they can't be
> used together but separately?
xdp_features should export NIC supported features in the current
configuration and it is expected they can be used concurrently.
Regards,
Lorenzo
>
> --
> Kind Regards,
> Niklas Söderlund
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists