From: Lorenzo Bianconi <lorenzo@kernel•org>
To: "Niklas Söderlund" <niklas.soderlund@corigine•com>
Cc: bpf@vger•kernel.org, netdev@vger•kernel.org, ast@kernel•org,
daniel@iogearbox•net, andrii@kernel•org, davem@davemloft•net,
kuba@kernel•org, hawk@kernel•org, pabeni@redhat•com,
edumazet@google•com, toke@redhat•com, memxor@gmail•com,
alardam@gmail•com, saeedm@nvidia•com, anthony.l.nguyen@intel•com,
gospo@broadcom•com, vladimir.oltean@nxp•com, nbd@nbd•name,
john@phrozen•org, leon@kernel•org, simon.horman@corigine•com,
aelior@marvell•com, christophe.jaillet@wanadoo•fr,
ecree.xilinx@gmail•com, mst@redhat•com, bjorn@kernel•org,
magnus.karlsson@intel•com, maciej.fijalkowski@intel•com,
intel-wired-lan@lists•osuosl.org, lorenzo.bianconi@redhat•com
Subject: Re: [RFC v2 bpf-next 2/7] drivers: net: turn on XDP features
Date: Wed, 18 Jan 2023 10:38:45 +0100 [thread overview]
Message-ID: <Y8e+JVtrEqtZemF3@lore-desk> (raw)
In-Reply-To: <Y8ey7Sg3BcPfsU9d@sleipner.dyn.berto.se>
[-- Attachment #1: Type: text/plain, Size: 3473 bytes --]
> Hi Lorenzo,
>
> On 2023-01-18 00:45:44 +0100, Lorenzo Bianconi wrote:
> > > 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.
>
> Thanks. I have just been informed from Yinjun Zhang that this check is
> not enough as this function is reused for VF where nn->app is not set. I
> think a better check would be
>
> if (nn->app && nn->app->type->id == NFP_APP_BPF_NIC)
>
> Yinjun also informed me that you can make this code a bit neater by,
>
> s/nn->dp.netdev->xdp_features/netdev->xdp_features/
>
> Thanks again for your work.
ack thx Niklas, I will fix it.
Regards,
Lorenzo
>
> >
> > >
> > > > +
> > > > /* 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
>
>
>
> --
> Kind Regards,
> Niklas Söderlund
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-01-18 10:35 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-14 15:54 [RFC v2 bpf-next 0/7] xdp: introduce xdp-feature support Lorenzo Bianconi
2023-01-14 15:54 ` [RFC v2 bpf-next 1/7] netdev-genl: create a simple family for netdev stuff Lorenzo Bianconi
2023-01-14 15:54 ` [RFC v2 bpf-next 2/7] drivers: net: turn on XDP features Lorenzo Bianconi
2023-01-17 21:29 ` Niklas Söderlund
2023-01-17 21:58 ` Toke Høiland-Jørgensen
2023-01-17 22:05 ` Niklas Söderlund
2023-01-17 22:15 ` Toke Høiland-Jørgensen
2023-01-17 22:29 ` Niklas Söderlund
2023-01-17 22:42 ` Toke Høiland-Jørgensen
2023-01-17 23:45 ` Lorenzo Bianconi
2023-01-18 8:50 ` Niklas Söderlund
2023-01-18 9:38 ` Lorenzo Bianconi [this message]
2023-01-18 20:30 ` sdf
2023-01-19 14:23 ` Lorenzo Bianconi
2023-01-14 15:54 ` [RFC v2 bpf-next 3/7] xsk: add usage of XDP features flags Lorenzo Bianconi
2023-01-17 22:07 ` Yonghong Song
2023-01-17 23:34 ` Lorenzo Bianconi
2023-01-17 23:37 ` Yonghong Song
2023-01-14 15:54 ` [RFC v2 bpf-next 4/7] libbpf: add the capability to specify netlink proto in libbpf_netlink_send_recv Lorenzo Bianconi
2023-01-14 15:54 ` [RFC v2 bpf-next 5/7] libbpf: add API to get XDP/XSK supported features Lorenzo Bianconi
2023-01-18 0:58 ` Jakub Kicinski
2023-01-19 22:39 ` Lorenzo Bianconi
2023-01-14 15:54 ` [RFC v2 bpf-next 6/7] bpf: devmap: check XDP features in bpf_map_update_elem and __xdp_enqueue Lorenzo Bianconi
2023-01-14 15:54 ` [RFC v2 bpf-next 7/7] selftests/bpf: introduce XDP compliance test tool Lorenzo Bianconi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y8e+JVtrEqtZemF3@lore-desk \
--to=lorenzo@kernel$(echo .)org \
--cc=aelior@marvell$(echo .)com \
--cc=alardam@gmail$(echo .)com \
--cc=andrii@kernel$(echo .)org \
--cc=anthony.l.nguyen@intel$(echo .)com \
--cc=ast@kernel$(echo .)org \
--cc=bjorn@kernel$(echo .)org \
--cc=bpf@vger$(echo .)kernel.org \
--cc=christophe.jaillet@wanadoo$(echo .)fr \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=ecree.xilinx@gmail$(echo .)com \
--cc=edumazet@google$(echo .)com \
--cc=gospo@broadcom$(echo .)com \
--cc=hawk@kernel$(echo .)org \
--cc=intel-wired-lan@lists$(echo .)osuosl.org \
--cc=john@phrozen$(echo .)org \
--cc=kuba@kernel$(echo .)org \
--cc=leon@kernel$(echo .)org \
--cc=lorenzo.bianconi@redhat$(echo .)com \
--cc=maciej.fijalkowski@intel$(echo .)com \
--cc=magnus.karlsson@intel$(echo .)com \
--cc=memxor@gmail$(echo .)com \
--cc=mst@redhat$(echo .)com \
--cc=nbd@nbd$(echo .)name \
--cc=netdev@vger$(echo .)kernel.org \
--cc=niklas.soderlund@corigine$(echo .)com \
--cc=pabeni@redhat$(echo .)com \
--cc=saeedm@nvidia$(echo .)com \
--cc=simon.horman@corigine$(echo .)com \
--cc=toke@redhat$(echo .)com \
--cc=vladimir.oltean@nxp$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox