From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: alardam@gmail.com, magnus.karlsson@intel.com,
bjorn.topel@intel.com, andrii.nakryiko@gmail.com,
kuba@kernel.org, ast@kernel.org, daniel@iogearbox.net,
netdev@vger.kernel.org, davem@davemloft.net,
john.fastabend@gmail.com, hawk@kernel.org
Cc: maciej.fijalkowski@intel.com, jonathan.lemon@gmail.com,
bpf@vger.kernel.org, jeffrey.t.kirsher@intel.com,
maciejromanfijalkowski@gmail.com,
intel-wired-lan@lists.osuosl.org,
Marek Majtyka <marekx.majtyka@intel.com>
Subject: Re: [PATCH 0/8] New netdev feature flags for XDP
Date: Mon, 16 Nov 2020 14:25:35 +0100 [thread overview]
Message-ID: <875z655t80.fsf@toke.dk> (raw)
In-Reply-To: <20201116093452.7541-1-marekx.majtyka@intel.com>
alardam@gmail.com writes:
> From: Marek Majtyka <marekx.majtyka@intel.com>
>
> Implement support for checking if a netdev has native XDP and AF_XDP zero
> copy support. Previously, there was no way to do this other than to try
> to create an AF_XDP socket on the interface or load an XDP program and
> see if it worked. This commit changes this by extending existing
> netdev_features in the following way:
> * xdp - full XDP support (XDP_{TX, PASS, DROP, ABORT, REDIRECT})
> * af-xdp-zc - AF_XDP zero copy support
> NICs supporting these features are updated by turning the corresponding
> netdev feature flags on.
Thank you for working on this! The lack of a way to discover whether an
interface supports XDP is really annoying.
However, I don't think just having two separate netdev feature flags for
XDP and AF_XDP is going to cut it. Whatever mechanism we end up will
need to be able to express at least the following, in addition to your
two flags:
- Which return codes does it support (with DROP/PASS, TX and REDIRECT as
separate options)?
- Does this interface be used as a target for XDP_REDIRECT
(supported/supported but not enabled)?
- Does the interface support offloaded XDP?
That's already five or six more flags, and we can't rule out that we'll
need more; so I'm not sure if just defining feature bits for all of them
is a good idea.
In addition, we should be able to check this in a way so we can reject
XDP programs that use features that are not supported. E.g., program
uses REDIRECT return code (or helper), but the interface doesn't support
it? Reject at attach/load time! Or the user attempts to insert an
interface into a redirect map, but that interface doesn't implement
ndo_xdp_xmit()? Reject the insert! Etc.
That last bit can be added later, of course, but we need to make sure we
design the support in a way that it is possible to do so...
-Toke
next prev parent reply other threads:[~2020-11-16 13:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-16 9:34 [PATCH 0/8] New netdev feature flags for XDP alardam
2020-11-16 9:34 ` [PATCH 1/8] net: ethtool: extend netdev_features flag set alardam
2020-11-16 9:34 ` [PATCH 2/8] drivers/net: turn XDP flags on alardam
2020-11-16 9:34 ` [PATCH 3/8] xsk: add usage of xdp netdev_features flags alardam
2020-11-16 9:34 ` [PATCH 4/8] xsk: add check for full support of XDP in bind alardam
2020-11-16 9:34 ` [PATCH 5/8] libbpf: extend netlink attribute API alardam
2020-11-16 9:34 ` [PATCH 6/8] libbpf: add functions to get XSK modes alardam
2020-11-17 7:05 ` kernel test robot
2020-11-16 9:34 ` [PATCH 7/8] libbpf: add API to get XSK/XDP caps alardam
2020-11-16 9:34 ` [PATCH 8/8] samples/bpf/xdp: apply netdev XDP/XSK modes info alardam
2020-11-16 13:25 ` Toke Høiland-Jørgensen [this message]
2020-11-17 7:37 ` [Intel-wired-lan] [PATCH 0/8] New netdev feature flags for XDP Magnus Karlsson
2020-11-17 8:55 ` Marek Majtyka
2020-11-17 18:38 ` Toke Høiland-Jørgensen
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=875z655t80.fsf@toke.dk \
--to=toke@redhat.com \
--cc=alardam@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bjorn.topel@intel.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=hawk@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=john.fastabend@gmail.com \
--cc=jonathan.lemon@gmail.com \
--cc=kuba@kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=maciejromanfijalkowski@gmail.com \
--cc=magnus.karlsson@intel.com \
--cc=marekx.majtyka@intel.com \
--cc=netdev@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).