[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y6F+YJSkI19m/kMv@lore-desk>
Date: Tue, 20 Dec 2022 10:20:32 +0100
From: Lorenzo Bianconi <lorenzo.bianconi@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Lorenzo Bianconi <lorenzo@...nel.org>, 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
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.
Hi Jakub,
I am fine to use YAML for this, but I will let Marek comment since he is the
original author of this patch.
>
> > +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?
I guess we can remove it.
@Marek: any comment?
>
> > +* 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?
Probably not, I kept it since it was in Marek's original patch.
@Marek: any comment?
>
> > +* 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?
yes, naming is always hard :)
>
> > +* 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.
ack, fine. I will rename it in the formal series.
Regards,
Lorenzo
>
> > +* 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.
>
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists