[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221219171321.7a67002b@kernel.org>
Date: Mon, 19 Dec 2022 17:13:21 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Lorenzo Bianconi <lorenzo@...nel.org>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, ast@...nel.org,
daniel@...earbox.net, andrii@...nel.org, davem@...emloft.net,
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,
grygorii.strashko@...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 bpf-next 2/8] net: introduce XDP features flag
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.
Powered by blists - more mailing lists