From: "Toke Høiland-Jørgensen" <toke@kernel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org
Cc: netdev@vger.kernel.org, magnus.karlsson@intel.com,
bjorn@kernel.org, tirthendu.sarkar@intel.com,
maciej.fijalkowski@intel.com, simon.horman@corigine.com
Subject: Re: [PATCH v3 bpf-next 00/22] xsk: multi-buffer support
Date: Mon, 05 Jun 2023 18:58:25 +0200 [thread overview]
Message-ID: <87edmp3ky6.fsf@toke.dk> (raw)
In-Reply-To: <20230605144433.290114-1-maciej.fijalkowski@intel.com>
Great to see this proceeding! Thought I'd weigh in on this part:
> Unfortunately, we had to introduce a new bind flag (XDP_USE_SG) on the
> AF_XDP level to enable multi-buffer support. It would be great if you
> have ideas on how to get rid of it. The reason we need to
> differentiate between non multi-buffer and multi-buffer is the
> behaviour when the kernel gets a packet that is larger than the frame
> size. Without multi-buffer, this packet is dropped and marked in the
> stats. With multi-buffer on, we want to split it up into multiple
> frames instead.
>
> At the start, we thought that riding on the .frags section name of
> the XDP program was a good idea. You do not have to introduce yet
> another flag and all AF_XDP users must load an XDP program anyway
> to get any traffic up to the socket, so why not just say that the XDP
> program decides if the AF_XDP socket should get multi-buffer packets
> or not? The problem is that we can create an AF_XDP socket that is Tx
> only and that works without having to load an XDP program at
> all. Another problem is that the XDP program might change during the
> execution, so we would have to check this for every single packet.
I agree that it's better to tie the enabling of this to a socket flag
instead of to the XDP program, for a couple of reasons:
- The XDP program can, as you say, be changed, but it can also be shared
between several sockets in a single XSK, so this really needs to be
tied to the socket.
- The XDP program is often installed implicitly by libxdp, in which case
the program can't really set the flag on the program itself.
There's a related question of whether the frags flag on the XDP program
should be a prerequisite for enabling it at the socket? I think probably
it should, right?
Also, related to the first point above, how does the driver respond to
two different sockets being attached to the same device with two
different values of the flag? (As you can probably tell I didn't look at
the details of the implementation...)
-Toke
next prev parent reply other threads:[~2023-06-05 16:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-05 14:44 [PATCH v3 bpf-next 00/22] xsk: multi-buffer support Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 01/22] xsk: prepare 'options' in xdp_desc for multi-buffer use Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 02/22] xsk: introduce XSK_USE_SG bind flag for xsk socket Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 03/22] xsk: prepare both copy and zero-copy modes to co-exist Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 04/22] xsk: move xdp_buff's data length check to xsk_rcv_check Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 05/22] xsk: add support for AF_XDP multi-buffer on Rx path Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 06/22] xsk: introduce wrappers and helpers for supporting multi-buffer in Tx path Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 07/22] xsk: allow core/drivers to test EOP bit Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 08/22] xsk: add support for AF_XDP multi-buffer on Tx path Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 09/22] xsk: discard zero length descriptors in " Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 10/22] xsk: support mbuf on ZC RX Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 11/22] ice: xsk: add RX multi-buffer support Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 12/22] xsk: support ZC Tx multi-buffer in batch API Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 13/22] xsk: report zero-copy multi-buffer capability via xdp_features Maciej Fijalkowski
2023-06-05 21:43 ` Jakub Kicinski
2023-06-06 12:52 ` Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 14/22] ice: xsk: Tx multi-buffer support Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 15/22] xsk: add multi-buffer documentation Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 16/22] selftests/xsk: transmit and receive multi-buffer packets Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 17/22] selftests/xsk: add basic multi-buffer test Maciej Fijalkowski
2023-06-05 20:17 ` Simon Horman
2023-06-05 14:44 ` [PATCH v3 bpf-next 18/22] selftests/xsk: add unaligned mode test for multi-buffer Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 19/22] selftests/xsk: add invalid descriptor " Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 20/22] selftests/xsk: add metadata copy test for multi-buff Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 21/22] selftests/xsk: add test for too many frags Maciej Fijalkowski
2023-06-05 14:44 ` [PATCH v3 bpf-next 22/22] selftests/xsk: reset NIC settings to default after running test suite Maciej Fijalkowski
2023-06-05 16:58 ` Toke Høiland-Jørgensen [this message]
2023-06-06 12:50 ` [PATCH v3 bpf-next 00/22] xsk: multi-buffer support Maciej Fijalkowski
2023-06-06 20:35 ` 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=87edmp3ky6.fsf@toke.dk \
--to=toke@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=netdev@vger.kernel.org \
--cc=simon.horman@corigine.com \
--cc=tirthendu.sarkar@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox