From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: "Maciej Fijalkowski" <maciej.fijalkowski@intel.com>,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
alardam@gmail.com, magnus.karlsson@intel.com,
bjorn.topel@intel.com, andrii.nakryiko@gmail.com,
kuba@kernel.org, ast@kernel.org, netdev@vger.kernel.org,
davem@davemloft.net, john.fastabend@gmail.com, hawk@kernel.org,
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 v2 bpf 1/5] net: ethtool: add xdp properties flag set
Date: Mon, 7 Dec 2020 13:54:33 +0100 [thread overview]
Message-ID: <20201207135433.41172202@carbon> (raw)
In-Reply-To: <048bd986-2e05-ee5b-2c03-cd8c473f6636@iogearbox.net>
On Fri, 4 Dec 2020 16:21:08 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 12/4/20 1:46 PM, Maciej Fijalkowski wrote:
> > On Fri, Dec 04, 2020 at 01:18:31PM +0100, Toke Høiland-Jørgensen wrote:
> >> alardam@gmail.com writes:
> >>> From: Marek Majtyka <marekx.majtyka@intel.com>
> >>>
> >>> Implement support for checking what kind of xdp functionality a netdev
> >>> supports. 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 adding a new variable which
> >>> describes all xdp supported functions on pretty detailed level:
> >>
> >> I like the direction this is going! :)
(Me too, don't get discouraged by our nitpicking, keep working on this! :-))
> >>
> >>> - aborted
> >>> - drop
> >>> - pass
> >>> - tx
>
> I strongly think we should _not_ merge any native XDP driver patchset
> that does not support/implement the above return codes.
I agree, with above statement.
> Could we instead group them together and call this something like
> XDP_BASE functionality to not give a wrong impression?
I disagree. I can accept that XDP_BASE include aborted+drop+pass.
I think we need to keep XDP_TX action separate, because I think that
there are use-cases where the we want to disable XDP_TX due to end-user
policy or hardware limitations.
Use-case(1): Cloud-provider want to give customers (running VMs) ability
to load XDP program for DDoS protection (only), but don't want to allow
customer to use XDP_TX (that can implement LB or cheat their VM
isolation policy).
Use-case(2): Disable XDP_TX on a driver to save hardware TX-queue
resources, as the use-case is only DDoS. Today we have this problem
with the ixgbe hardware, that cannot load XDP programs on systems with
more than 192 CPUs.
> If this is properly documented that these are basic must-have
> _requirements_, then users and driver developers both know what the
> expectations are.
We can still document that XDP_TX is a must-have requirement, when a
driver implements XDP.
> >>> - redirect
> >>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
WARNING: multiple messages have this Message-ID (diff)
From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH v2 bpf 1/5] net: ethtool: add xdp properties flag set
Date: Mon, 7 Dec 2020 13:54:33 +0100 [thread overview]
Message-ID: <20201207135433.41172202@carbon> (raw)
In-Reply-To: <048bd986-2e05-ee5b-2c03-cd8c473f6636@iogearbox.net>
On Fri, 4 Dec 2020 16:21:08 +0100
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 12/4/20 1:46 PM, Maciej Fijalkowski wrote:
> > On Fri, Dec 04, 2020 at 01:18:31PM +0100, Toke H?iland-J?rgensen wrote:
> >> alardam at gmail.com writes:
> >>> From: Marek Majtyka <marekx.majtyka@intel.com>
> >>>
> >>> Implement support for checking what kind of xdp functionality a netdev
> >>> supports. 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 adding a new variable which
> >>> describes all xdp supported functions on pretty detailed level:
> >>
> >> I like the direction this is going! :)
(Me too, don't get discouraged by our nitpicking, keep working on this! :-))
> >>
> >>> - aborted
> >>> - drop
> >>> - pass
> >>> - tx
>
> I strongly think we should _not_ merge any native XDP driver patchset
> that does not support/implement the above return codes.
I agree, with above statement.
> Could we instead group them together and call this something like
> XDP_BASE functionality to not give a wrong impression?
I disagree. I can accept that XDP_BASE include aborted+drop+pass.
I think we need to keep XDP_TX action separate, because I think that
there are use-cases where the we want to disable XDP_TX due to end-user
policy or hardware limitations.
Use-case(1): Cloud-provider want to give customers (running VMs) ability
to load XDP program for DDoS protection (only), but don't want to allow
customer to use XDP_TX (that can implement LB or cheat their VM
isolation policy).
Use-case(2): Disable XDP_TX on a driver to save hardware TX-queue
resources, as the use-case is only DDoS. Today we have this problem
with the ixgbe hardware, that cannot load XDP programs on systems with
more than 192 CPUs.
> If this is properly documented that these are basic must-have
> _requirements_, then users and driver developers both know what the
> expectations are.
We can still document that XDP_TX is a must-have requirement, when a
driver implements XDP.
> >>> - redirect
> >>
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2020-12-07 12:56 UTC|newest]
Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 10:28 [PATCH v2 bpf 0/5] New netdev feature flags for XDP alardam
2020-12-04 10:28 ` [Intel-wired-lan] " alardam
2020-12-04 10:28 ` [PATCH v2 bpf 1/5] net: ethtool: add xdp properties flag set alardam
2020-12-04 10:28 ` [Intel-wired-lan] " alardam
2020-12-04 12:18 ` Toke Høiland-Jørgensen
2020-12-04 12:18 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2020-12-04 12:46 ` Maciej Fijalkowski
2020-12-04 12:46 ` [Intel-wired-lan] " Maciej Fijalkowski
2020-12-04 15:21 ` Daniel Borkmann
2020-12-04 15:21 ` [Intel-wired-lan] " Daniel Borkmann
2020-12-04 17:20 ` Toke Høiland-Jørgensen
2020-12-04 17:20 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2020-12-04 22:19 ` Daniel Borkmann
2020-12-04 22:19 ` [Intel-wired-lan] " Daniel Borkmann
2020-12-07 11:54 ` Jesper Dangaard Brouer
2020-12-07 11:54 ` [Intel-wired-lan] " Jesper Dangaard Brouer
2020-12-07 12:08 ` Toke Høiland-Jørgensen
2020-12-07 12:08 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2020-12-07 12:03 ` Toke Høiland-Jørgensen
2020-12-07 12:03 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2020-12-07 12:54 ` Jesper Dangaard Brouer [this message]
2020-12-07 12:54 ` Jesper Dangaard Brouer
2020-12-07 20:52 ` John Fastabend
2020-12-07 20:52 ` [Intel-wired-lan] " John Fastabend
2020-12-07 22:38 ` Saeed Mahameed
2020-12-07 22:38 ` [Intel-wired-lan] " Saeed Mahameed
2020-12-07 23:07 ` Maciej Fijalkowski
2020-12-07 23:07 ` [Intel-wired-lan] " Maciej Fijalkowski
2020-12-09 6:03 ` John Fastabend
2020-12-09 6:03 ` [Intel-wired-lan] " John Fastabend
2020-12-09 9:54 ` Maciej Fijalkowski
2020-12-09 9:54 ` [Intel-wired-lan] " Maciej Fijalkowski
2020-12-09 11:52 ` Jesper Dangaard Brouer
2020-12-09 11:52 ` [Intel-wired-lan] " Jesper Dangaard Brouer
2020-12-09 15:41 ` David Ahern
2020-12-09 15:41 ` [Intel-wired-lan] " David Ahern
2020-12-09 17:15 ` Saeed Mahameed
2020-12-09 17:15 ` [Intel-wired-lan] " Saeed Mahameed
2020-12-10 3:34 ` David Ahern
2020-12-10 3:34 ` [Intel-wired-lan] " David Ahern
2020-12-10 6:48 ` Saeed Mahameed
2020-12-10 6:48 ` [Intel-wired-lan] " Saeed Mahameed
2020-12-10 15:30 ` David Ahern
2020-12-10 15:30 ` [Intel-wired-lan] " David Ahern
2020-12-10 18:58 ` Saeed Mahameed
2020-12-10 18:58 ` [Intel-wired-lan] " Saeed Mahameed
2021-01-05 11:56 ` Marek Majtyka
2021-01-05 11:56 ` [Intel-wired-lan] " Marek Majtyka
2021-02-01 16:16 ` Toke Høiland-Jørgensen
2021-02-01 16:16 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2021-02-02 11:26 ` Marek Majtyka
2021-02-02 11:26 ` [Intel-wired-lan] " Marek Majtyka
2021-02-02 12:05 ` Toke Høiland-Jørgensen
2021-02-02 12:05 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2021-02-02 19:34 ` Jakub Kicinski
2021-02-02 19:34 ` [Intel-wired-lan] " Jakub Kicinski
2021-02-03 12:50 ` Marek Majtyka
2021-02-03 12:50 ` [Intel-wired-lan] " Marek Majtyka
2021-02-03 17:02 ` Jakub Kicinski
2021-02-03 17:02 ` [Intel-wired-lan] " Jakub Kicinski
2021-02-10 10:53 ` Toke Høiland-Jørgensen
2021-02-10 10:53 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2021-02-10 18:31 ` Jakub Kicinski
2021-02-10 18:31 ` [Intel-wired-lan] " Jakub Kicinski
2021-02-10 22:52 ` Toke Høiland-Jørgensen
2021-02-10 22:52 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2021-02-12 1:26 ` Jakub Kicinski
2021-02-12 1:26 ` [Intel-wired-lan] " Jakub Kicinski
2021-02-12 2:05 ` Alexei Starovoitov
2021-02-12 2:05 ` [Intel-wired-lan] " Alexei Starovoitov
2021-02-12 7:02 ` Marek Majtyka
2021-02-12 7:02 ` [Intel-wired-lan] " Marek Majtyka
2021-02-16 14:30 ` Toke Høiland-Jørgensen
2021-02-16 14:30 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2020-12-09 15:44 ` David Ahern
2020-12-09 15:44 ` [Intel-wired-lan] " David Ahern
2020-12-10 13:32 ` Explaining XDP redirect bulk size design (Was: [PATCH v2 bpf 1/5] net: ethtool: add xdp properties flag set) Jesper Dangaard Brouer
2020-12-10 13:32 ` [Intel-wired-lan] " Jesper Dangaard Brouer
2020-12-10 14:14 ` Magnus Karlsson
2020-12-10 14:14 ` Magnus Karlsson
2020-12-10 17:30 ` Jesper Dangaard Brouer
2020-12-10 17:30 ` Jesper Dangaard Brouer
2020-12-10 19:20 ` Saeed Mahameed
2020-12-10 19:20 ` [Intel-wired-lan] " Saeed Mahameed
2020-12-08 1:01 ` [PATCH v2 bpf 1/5] net: ethtool: add xdp properties flag set David Ahern
2020-12-08 1:01 ` [Intel-wired-lan] " David Ahern
2020-12-08 8:28 ` Jesper Dangaard Brouer
2020-12-08 8:28 ` [Intel-wired-lan] " Jesper Dangaard Brouer
2020-12-08 11:58 ` Toke Høiland-Jørgensen
2020-12-08 11:58 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2020-12-09 5:50 ` John Fastabend
2020-12-09 5:50 ` [Intel-wired-lan] " John Fastabend
2020-12-09 10:26 ` Toke Høiland-Jørgensen
2020-12-09 10:26 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2020-12-08 9:00 ` Jesper Dangaard Brouer
2020-12-08 9:00 ` [Intel-wired-lan] " Jesper Dangaard Brouer
2020-12-08 9:42 ` Daniel Borkmann
2020-12-08 9:42 ` [Intel-wired-lan] " Daniel Borkmann
2020-12-04 12:57 ` Maciej Fijalkowski
2020-12-04 12:57 ` [Intel-wired-lan] " Maciej Fijalkowski
2020-12-04 10:28 ` [PATCH v2 bpf 2/5] drivers/net: turn XDP properties on alardam
2020-12-04 10:28 ` [Intel-wired-lan] " alardam
2020-12-04 12:19 ` Toke Høiland-Jørgensen
2020-12-04 12:19 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2020-12-09 19:05 ` kernel test robot
2020-12-09 19:05 ` kernel test robot
2020-12-04 10:28 ` [PATCH v2 bpf 3/5] xsk: add usage of xdp properties flags alardam
2020-12-04 10:28 ` [Intel-wired-lan] " alardam
2020-12-04 10:29 ` [PATCH v2 bpf 4/5] xsk: add check for full support of XDP in bind alardam
2020-12-04 10:29 ` [Intel-wired-lan] " alardam
2020-12-04 10:29 ` [PATCH v2 bpf 5/5] ethtool: provide xdp info with XDP_PROPERTIES_GET alardam
2020-12-04 10:29 ` [Intel-wired-lan] " alardam
2020-12-04 17:20 ` [PATCH v2 bpf 0/5] New netdev feature flags for XDP Jakub Kicinski
2020-12-04 17:20 ` [Intel-wired-lan] " Jakub Kicinski
2020-12-04 17:26 ` Toke Høiland-Jørgensen
2020-12-04 17:26 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
2020-12-04 19:22 ` Jakub Kicinski
2020-12-04 19:22 ` [Intel-wired-lan] " Jakub Kicinski
2020-12-07 12:04 ` Toke Høiland-Jørgensen
2020-12-07 12:04 ` [Intel-wired-lan] " Toke =?unknown-8bit?q?H=C3=B8iland-J=C3=B8rgensen?=
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=20201207135433.41172202@carbon \
--to=jbrouer@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 \
--cc=toke@redhat.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.