From: Jakub Kicinski <kuba@kernel.org>
To: Lorenzo Bianconi <lorenzo@kernel.org>
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, davem@davemloft.net,
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, grygorii.strashko@ti.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 bpf-next 2/8] net: introduce XDP features flag
Date: Mon, 19 Dec 2022 17:13:21 -0800 [thread overview]
Message-ID: <20221219171321.7a67002b@kernel.org> (raw)
In-Reply-To: <43c340d440d8a87396198b301c5ffbf5ab56f304.1671462950.git.lorenzo@kernel.org>
On Mon, 19 Dec 2022 16:41:31 +0100 Lorenzo Bianconi wrote:
> +=====================
> +Netdev XDP features
> +=====================
> +
> + * XDP FEATURES FLAGS
> +
> +Following netdev xdp features flags can be retrieved over route netlink
> +interface (compact form) - the same way as netdev feature flags.
How likely is it that I'll be able to convince you that cramming more
stuff in rtnl is a bad idea? I can convert this for you to a YAML-
-compatible genetlink family for you in a jiffy, just say yes :S
rtnl is hard to parse, and already overloaded with random stuff.
And the messages are enormous.
> +These features flags are read only and cannot be change at runtime.
> +
> +* XDP_ABORTED
> +
> +This feature informs if netdev supports xdp aborted action.
> +
> +* XDP_DROP
> +
> +This feature informs if netdev supports xdp drop action.
> +
> +* XDP_PASS
> +
> +This feature informs if netdev supports xdp pass action.
> +
> +* XDP_TX
> +
> +This feature informs if netdev supports xdp tx action.
> +
> +* XDP_REDIRECT
> +
> +This feature informs if netdev supports xdp redirect action.
> +It assumes the all beforehand mentioned flags are enabled.
> +
> +* XDP_SOCK_ZEROCOPY
> +
> +This feature informs if netdev driver supports xdp zero copy.
> +It assumes the all beforehand mentioned flags are enabled.
Why is this "assumption" worth documenting?
> +* XDP_HW_OFFLOAD
> +
> +This feature informs if netdev driver supports xdp hw oflloading.
> +
> +* XDP_TX_LOCK
> +
> +This feature informs if netdev ndo_xdp_xmit function requires locking.
Why is it relevant to the user?
> +* XDP_REDIRECT_TARGET
> +
> +This feature informs if netdev implements ndo_xdp_xmit callback.
Does it make sense to rename XDP_REDIRECT -> XDP_REDIRECT_SOURCE then?
> +* XDP_FRAG_RX
> +
> +This feature informs if netdev implements non-linear xdp buff support in
> +the driver napi callback.
Who's the target audience? Maybe FRAG is not the best name?
Scatter-gather or multi-buf may be more widely understood.
> +* XDP_FRAG_TARGET
> +
> +This feature informs if netdev implements non-linear xdp buff support in
> +ndo_xdp_xmit callback. XDP_FRAG_TARGET requires XDP_REDIRECT_TARGET is properly
> +supported.
WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Lorenzo Bianconi <lorenzo@kernel.org>
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,
pabeni@redhat.com, grygorii.strashko@ti.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 bpf-next 2/8] net: introduce XDP features flag
Date: Mon, 19 Dec 2022 17:13:21 -0800 [thread overview]
Message-ID: <20221219171321.7a67002b@kernel.org> (raw)
In-Reply-To: <43c340d440d8a87396198b301c5ffbf5ab56f304.1671462950.git.lorenzo@kernel.org>
On Mon, 19 Dec 2022 16:41:31 +0100 Lorenzo Bianconi wrote:
> +=====================
> +Netdev XDP features
> +=====================
> +
> + * XDP FEATURES FLAGS
> +
> +Following netdev xdp features flags can be retrieved over route netlink
> +interface (compact form) - the same way as netdev feature flags.
How likely is it that I'll be able to convince you that cramming more
stuff in rtnl is a bad idea? I can convert this for you to a YAML-
-compatible genetlink family for you in a jiffy, just say yes :S
rtnl is hard to parse, and already overloaded with random stuff.
And the messages are enormous.
> +These features flags are read only and cannot be change at runtime.
> +
> +* XDP_ABORTED
> +
> +This feature informs if netdev supports xdp aborted action.
> +
> +* XDP_DROP
> +
> +This feature informs if netdev supports xdp drop action.
> +
> +* XDP_PASS
> +
> +This feature informs if netdev supports xdp pass action.
> +
> +* XDP_TX
> +
> +This feature informs if netdev supports xdp tx action.
> +
> +* XDP_REDIRECT
> +
> +This feature informs if netdev supports xdp redirect action.
> +It assumes the all beforehand mentioned flags are enabled.
> +
> +* XDP_SOCK_ZEROCOPY
> +
> +This feature informs if netdev driver supports xdp zero copy.
> +It assumes the all beforehand mentioned flags are enabled.
Why is this "assumption" worth documenting?
> +* XDP_HW_OFFLOAD
> +
> +This feature informs if netdev driver supports xdp hw oflloading.
> +
> +* XDP_TX_LOCK
> +
> +This feature informs if netdev ndo_xdp_xmit function requires locking.
Why is it relevant to the user?
> +* XDP_REDIRECT_TARGET
> +
> +This feature informs if netdev implements ndo_xdp_xmit callback.
Does it make sense to rename XDP_REDIRECT -> XDP_REDIRECT_SOURCE then?
> +* XDP_FRAG_RX
> +
> +This feature informs if netdev implements non-linear xdp buff support in
> +the driver napi callback.
Who's the target audience? Maybe FRAG is not the best name?
Scatter-gather or multi-buf may be more widely understood.
> +* XDP_FRAG_TARGET
> +
> +This feature informs if netdev implements non-linear xdp buff support in
> +ndo_xdp_xmit callback. XDP_FRAG_TARGET requires XDP_REDIRECT_TARGET is properly
> +supported.
_______________________________________________
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:[~2022-12-20 1:14 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-19 15:41 [RFC bpf-next 0/8] xdp: introduce xdp-feature support Lorenzo Bianconi
2022-12-19 15:41 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-19 15:41 ` [RFC bpf-next 1/8] tools: uapi: align if_link.h Lorenzo Bianconi
2022-12-19 15:41 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-19 15:41 ` [RFC bpf-next 2/8] net: introduce XDP features flag Lorenzo Bianconi
2022-12-19 15:41 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-19 20:03 ` sdf
2022-12-19 20:03 ` [Intel-wired-lan] " sdf
2022-12-19 23:52 ` Marek Majtyka
2022-12-20 0:20 ` Stanislav Fomichev
2022-12-20 0:20 ` [Intel-wired-lan] " Stanislav Fomichev
2022-12-20 10:11 ` Lorenzo Bianconi
2022-12-20 10:11 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-20 18:03 ` Stanislav Fomichev
2022-12-20 18:03 ` [Intel-wired-lan] " Stanislav Fomichev
2022-12-20 22:25 ` Lorenzo Bianconi
2022-12-20 22:25 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-20 23:36 ` Stanislav Fomichev
2022-12-20 23:36 ` [Intel-wired-lan] " Stanislav Fomichev
2022-12-21 10:39 ` Lorenzo Bianconi
2022-12-21 10:39 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-21 17:50 ` Stanislav Fomichev
2022-12-21 17:50 ` [Intel-wired-lan] " Stanislav Fomichev
2022-12-20 1:13 ` Jakub Kicinski [this message]
2022-12-20 1:13 ` Jakub Kicinski
2022-12-20 9:20 ` Lorenzo Bianconi
2022-12-20 9:20 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-20 22:51 ` Marek Majtyka
2022-12-20 22:51 ` [Intel-wired-lan] " Marek Majtyka
2022-12-20 23:39 ` Jakub Kicinski
2022-12-20 23:39 ` [Intel-wired-lan] " Jakub Kicinski
2022-12-21 4:41 ` Jakub Kicinski
2022-12-21 4:41 ` [Intel-wired-lan] " Jakub Kicinski
2022-12-21 10:47 ` Lorenzo Bianconi
2022-12-21 10:47 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-20 6:43 ` kernel test robot
2022-12-19 15:41 ` [RFC bpf-next 3/8] drivers: net: turn on XDP features Lorenzo Bianconi
2022-12-19 15:41 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-19 15:41 ` [RFC bpf-next 4/8] xsk: add usage of XDP features flags Lorenzo Bianconi
2022-12-19 15:41 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-19 15:41 ` [RFC bpf-next 5/8] xsk: add check for full support of XDP in bind Lorenzo Bianconi
2022-12-19 15:41 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-19 15:41 ` [RFC bpf-next 6/8] libbpf: add API to get XDP/XSK supported features Lorenzo Bianconi
2022-12-19 15:41 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-20 4:52 ` kernel test robot
2022-12-21 0:18 ` Andrii Nakryiko
2022-12-21 0:18 ` [Intel-wired-lan] " Andrii Nakryiko
2023-01-10 17:26 ` Lorenzo Bianconi
2023-01-10 17:26 ` [Intel-wired-lan] " Lorenzo Bianconi
2023-01-13 18:22 ` Andrii Nakryiko
2023-01-13 18:22 ` [Intel-wired-lan] " Andrii Nakryiko
2023-01-14 15:33 ` Lorenzo Bianconi
2023-01-14 15:33 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-19 15:41 ` [RFC bpf-next 7/8] bpf: devmap: check XDP features in bpf_map_update_elem and __xdp_enqueue Lorenzo Bianconi
2022-12-19 15:41 ` [Intel-wired-lan] " Lorenzo Bianconi
2022-12-19 15:41 ` [RFC bpf-next 8/8] selftests/bpf: introduce XDP compliance test tool Lorenzo Bianconi
2022-12-19 15:41 ` [Intel-wired-lan] " 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=20221219171321.7a67002b@kernel.org \
--to=kuba@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=grygorii.strashko@ti.com \
--cc=hawk@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=john@phrozen.org \
--cc=leon@kernel.org \
--cc=lorenzo.bianconi@redhat.com \
--cc=lorenzo@kernel.org \
--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=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.