From: Jesper Dangaard Brouer <jbrouer@redhat.com> To: David Ahern <dsahern@gmail.com> Cc: "John Fastabend" <john.fastabend@gmail.com>, "Daniel Borkmann" <daniel@iogearbox.net>, "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, 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: Tue, 8 Dec 2020 09:28:03 +0100 [thread overview] Message-ID: <20201208092803.05b27db3@carbon> (raw) In-Reply-To: <431a53bd-25d7-8535-86e1-aa15bf94e6c3@gmail.com> On Mon, 7 Dec 2020 18:01:00 -0700 David Ahern <dsahern@gmail.com> wrote: > On 12/7/20 1:52 PM, John Fastabend wrote: > >> > >> 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. > > > > How about we discover this at load time though. Nitpick at XDP "attach" time. The general disconnect between BPF and XDP is that BPF can verify at "load" time (as kernel knows what it support) while XDP can have different support/features per driver, and cannot do this until attachment time. (See later issue with tail calls). (All other BPF-hooks don't have this issue) > > Meaning if the program > > doesn't use XDP_TX then the hardware can skip resource allocations for > > it. I think we could have verifier or extra pass discover the use of > > XDP_TX and then pass a bit down to driver to enable/disable TX caps. > > > > This was discussed in the context of virtio_net some months back - it is > hard to impossible to know a program will not return XDP_TX (e.g., value > comes from a map). It is hard, and sometimes not possible. For maps the workaround is that BPF-programmer adds a bound check on values from the map. If not doing that the verifier have to assume all possible return codes are used by BPF-prog. The real nemesis is program tail calls, that can be added dynamically after the XDP program is attached. It is at attachment time that changing the NIC resources is possible. So, for program tail calls the verifier have to assume all possible return codes are used by BPF-prog. BPF now have function calls and function replace right(?) How does this affect this detection of possible return codes? > Flipping that around, what if the program attach indicates whether > XDP_TX could be returned. If so, driver manages the resource needs. If > not, no resource needed and if the program violates that and returns > XDP_TX the packet is dropped. I do like this idea, as IMHO we do need something that is connected with the BPF-prog, that describe what resources the program request (either like above via detecting this in verifier, or simply manually configuring this in the BPF-prog ELF file) The main idea is that we all (I assume) want to provide a better end-user interface/experience. By direct feedback to the end-user that "loading+attaching" this XDP BPF-prog will not work, as e.g. driver don't support a specific return code. Thus, we need to reject "loading+attaching" if features cannot be satisfied. We need a solution as; today it is causing frustration for end-users that packets can be (silently) dropped by XDP, e.g. if driver don't support 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: Tue, 8 Dec 2020 09:28:03 +0100 [thread overview] Message-ID: <20201208092803.05b27db3@carbon> (raw) In-Reply-To: <431a53bd-25d7-8535-86e1-aa15bf94e6c3@gmail.com> On Mon, 7 Dec 2020 18:01:00 -0700 David Ahern <dsahern@gmail.com> wrote: > On 12/7/20 1:52 PM, John Fastabend wrote: > >> > >> 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. > > > > How about we discover this at load time though. Nitpick at XDP "attach" time. The general disconnect between BPF and XDP is that BPF can verify at "load" time (as kernel knows what it support) while XDP can have different support/features per driver, and cannot do this until attachment time. (See later issue with tail calls). (All other BPF-hooks don't have this issue) > > Meaning if the program > > doesn't use XDP_TX then the hardware can skip resource allocations for > > it. I think we could have verifier or extra pass discover the use of > > XDP_TX and then pass a bit down to driver to enable/disable TX caps. > > > > This was discussed in the context of virtio_net some months back - it is > hard to impossible to know a program will not return XDP_TX (e.g., value > comes from a map). It is hard, and sometimes not possible. For maps the workaround is that BPF-programmer adds a bound check on values from the map. If not doing that the verifier have to assume all possible return codes are used by BPF-prog. The real nemesis is program tail calls, that can be added dynamically after the XDP program is attached. It is at attachment time that changing the NIC resources is possible. So, for program tail calls the verifier have to assume all possible return codes are used by BPF-prog. BPF now have function calls and function replace right(?) How does this affect this detection of possible return codes? > Flipping that around, what if the program attach indicates whether > XDP_TX could be returned. If so, driver manages the resource needs. If > not, no resource needed and if the program violates that and returns > XDP_TX the packet is dropped. I do like this idea, as IMHO we do need something that is connected with the BPF-prog, that describe what resources the program request (either like above via detecting this in verifier, or simply manually configuring this in the BPF-prog ELF file) The main idea is that we all (I assume) want to provide a better end-user interface/experience. By direct feedback to the end-user that "loading+attaching" this XDP BPF-prog will not work, as e.g. driver don't support a specific return code. Thus, we need to reject "loading+attaching" if features cannot be satisfied. We need a solution as; today it is causing frustration for end-users that packets can be (silently) dropped by XDP, e.g. if driver don't support 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-08 8:30 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 2020-12-07 12:54 ` [Intel-wired-lan] " 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 [this message] 2020-12-08 8:28 ` 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=20201208092803.05b27db3@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=dsahern@gmail.com \ --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: linkBe 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.