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 --]
WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Bianconi <lorenzo@kernel.org>
To: "Niklas Söderlund" <niklas.soderlund@corigine.com>
Cc: mst@redhat.com, vladimir.oltean@nxp.com, ast@kernel.org,
edumazet@google.com, anthony.l.nguyen@intel.com,
daniel@iogearbox.net, andrii@kernel.org,
intel-wired-lan@lists.osuosl.org, simon.horman@corigine.com,
kuba@kernel.org, pabeni@redhat.com, aelior@marvell.com,
hawk@kernel.org, christophe.jaillet@wanadoo.fr, memxor@gmail.com,
john@phrozen.org, bjorn@kernel.org, bpf@vger.kernel.org,
magnus.karlsson@intel.com, leon@kernel.org,
netdev@vger.kernel.org, toke@redhat.com, ecree.xilinx@gmail.com,
alardam@gmail.com, gospo@broadcom.com, saeedm@nvidia.com,
davem@davemloft.net, nbd@nbd.name
Subject: Re: [Intel-wired-lan] [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.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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 162 bytes --]
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
next prev parent reply other threads:[~2023-01-18 10:35 UTC|newest]
Thread overview: 53+ 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 ` [Intel-wired-lan] " 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 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-14 17:07 ` kernel test robot
2023-01-14 17:17 ` kernel test robot
2023-01-14 15:54 ` [RFC v2 bpf-next 2/7] drivers: net: turn on XDP features Lorenzo Bianconi
2023-01-14 15:54 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-14 17:38 ` kernel test robot
2023-01-17 21:29 ` Niklas Söderlund
2023-01-17 21:29 ` [Intel-wired-lan] " Niklas Söderlund
2023-01-17 21:58 ` Toke Høiland-Jørgensen
2023-01-17 21:58 ` [Intel-wired-lan] " Toke Høiland-Jørgensen
2023-01-17 22:05 ` Niklas Söderlund
2023-01-17 22:05 ` [Intel-wired-lan] " Niklas Söderlund
2023-01-17 22:15 ` Toke Høiland-Jørgensen
2023-01-17 22:15 ` [Intel-wired-lan] " Toke Høiland-Jørgensen
2023-01-17 22:29 ` Niklas Söderlund
2023-01-17 22:29 ` [Intel-wired-lan] " Niklas Söderlund
2023-01-17 22:42 ` Toke Høiland-Jørgensen
2023-01-17 22:42 ` [Intel-wired-lan] " Toke Høiland-Jørgensen
2023-01-17 23:45 ` Lorenzo Bianconi
2023-01-17 23:45 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-18 8:50 ` Niklas Söderlund
2023-01-18 8:50 ` [Intel-wired-lan] " Niklas Söderlund
2023-01-18 9:38 ` Lorenzo Bianconi [this message]
2023-01-18 9:38 ` Lorenzo Bianconi
2023-01-18 20:30 ` sdf
2023-01-18 20:30 ` [Intel-wired-lan] " sdf
2023-01-19 14:23 ` Lorenzo Bianconi
2023-01-19 14:23 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-14 15:54 ` [RFC v2 bpf-next 3/7] xsk: add usage of XDP features flags Lorenzo Bianconi
2023-01-14 15:54 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-17 22:07 ` Yonghong Song
2023-01-17 22:07 ` [Intel-wired-lan] " Yonghong Song
2023-01-17 23:34 ` Lorenzo Bianconi
2023-01-17 23:34 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-17 23:37 ` Yonghong Song
2023-01-17 23:37 ` [Intel-wired-lan] " 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 ` [Intel-wired-lan] " 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-14 15:54 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-18 0:58 ` Jakub Kicinski
2023-01-18 0:58 ` [Intel-wired-lan] " Jakub Kicinski
2023-01-19 22:39 ` Lorenzo Bianconi
2023-01-19 22:39 ` [Intel-wired-lan] " 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 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-14 15:54 ` [RFC v2 bpf-next 7/7] selftests/bpf: introduce XDP compliance test tool Lorenzo Bianconi
2023-01-14 15:54 ` [Intel-wired-lan] " Lorenzo Bianconi
-- strict thread matches above, loose matches on Subject: below --
2023-01-15 0:22 [RFC v2 bpf-next 1/7] netdev-genl: create a simple family for netdev stuff kernel test robot
2023-01-16 9:04 ` Dan Carpenter
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.org \
--cc=aelior@marvell.com \
--cc=alardam@gmail.com \
--cc=andrii@kernel.org \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=christophe.jaillet@wanadoo.fr \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=ecree.xilinx@gmail.com \
--cc=edumazet@google.com \
--cc=gospo@broadcom.com \
--cc=hawk@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=john@phrozen.org \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=lorenzo.bianconi@redhat.com \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=memxor@gmail.com \
--cc=mst@redhat.com \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=niklas.soderlund@corigine.com \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=simon.horman@corigine.com \
--cc=toke@redhat.com \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.