From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: "Sarkar, Tirthendu" <tirthendu.sarkar@intel.com>,
"Fijalkowski, Maciej" <maciej.fijalkowski@intel.com>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
"ast@kernel.org" <ast@kernel.org>,
"daniel@iogearbox.net" <daniel@iogearbox.net>,
"andrii@kernel.org" <andrii@kernel.org>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"Karlsson, Magnus" <magnus.karlsson@intel.com>,
"bjorn@kernel.org" <bjorn@kernel.org>,
"Fijalkowski, Maciej" <maciej.fijalkowski@intel.com>,
"simon.horman@corigine.com" <simon.horman@corigine.com>
Subject: RE: [PATCH v4 bpf-next 06/22] xsk: introduce wrappers and helpers for supporting multi-buffer in Tx path
Date: Wed, 21 Jun 2023 15:27:16 +0200 [thread overview]
Message-ID: <87r0q5c5e3.fsf@toke.dk> (raw)
In-Reply-To: <SN7PR11MB665536C0588850F0374EFBA3905DA@SN7PR11MB6655.namprd11.prod.outlook.com>
"Sarkar, Tirthendu" <tirthendu.sarkar@intel.com> writes:
>> -----Original Message-----
>> From: Toke Høiland-Jørgensen <toke@redhat.com>
>> Sent: Tuesday, June 20, 2023 10:56 PM
>>>
>> Subject: Re: [PATCH v4 bpf-next 06/22] xsk: introduce wrappers and helpers
>> for supporting multi-buffer in Tx path
>>
>> Maciej Fijalkowski <maciej.fijalkowski@intel.com> writes:
>>
>> > From: Tirthendu Sarkar <tirthendu.sarkar@intel.com>
>> >
>> > In Tx path, xsk core reserves space for each desc to be transmitted in
>> > the completion queue and it's address contained in it is stored in the
>> > skb destructor arg. After successful transmission the skb destructor
>> > submits the addr marking completion.
>> >
>> > To handle multiple descriptors per packet, now along with reserving
>> > space for each descriptor, the corresponding address is also stored in
>> > completion queue. The number of pending descriptors are stored in skb
>> > destructor arg and is used by the skb destructor to update completions.
>> >
>> > Introduce 'skb' in xdp_sock to store a partially built packet when
>> > __xsk_generic_xmit() must return before it sees the EOP descriptor for
>> > the current packet so that packet building can resume in next call of
>> > __xsk_generic_xmit().
>> >
>> > Helper functions are introduced to set and get the pending descriptors
>> > in the skb destructor arg. Also, wrappers are introduced for storing
>> > descriptor addresses, submitting and cancelling (for unsuccessful
>> > transmissions) the number of completions.
>> >
>> > Signed-off-by: Tirthendu Sarkar <tirthendu.sarkar@intel.com>
>> > ---
>> > include/net/xdp_sock.h | 6 ++++
>> > net/xdp/xsk.c | 74 ++++++++++++++++++++++++++++++------------
>> > net/xdp/xsk_queue.h | 19 ++++-------
>> > 3 files changed, 67 insertions(+), 32 deletions(-)
>> >
>> > diff --git a/include/net/xdp_sock.h b/include/net/xdp_sock.h
>> > index 36b0411a0d1b..1617af380162 100644
>> > --- a/include/net/xdp_sock.h
>> > +++ b/include/net/xdp_sock.h
>> > @@ -68,6 +68,12 @@ struct xdp_sock {
>> > u64 rx_dropped;
>> > u64 rx_queue_full;
>> >
>> > + /* When __xsk_generic_xmit() must return before it sees the EOP
>> descriptor for the current
>> > + * packet, the partially built skb is saved here so that packet building
>> can resume in next
>> > + * call of __xsk_generic_xmit().
>> > + */
>> > + struct sk_buff *skb;
>>
>> What ensures this doesn't leak? IIUC, when the loop in
>> __xsk_generic_xmit() gets to the end of a batch, userspace will get an
>> EAGAIN error and be expected to retry the call later, right? But if
>> userspace never retries, could the socket be torn down with this pointer
>> still populated? I looked for something that would prevent this in
>> subsequent patches, but couldn't find it; am I missing something?
>>
>> -Toke
>>
>
> Thanks for catching this. We will add cleanup during socket termination in v5.
Awesome! :)
-Toke
next prev parent reply other threads:[~2023-06-21 13:27 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-15 17:25 [PATCH v4 bpf-next 00/22] xsk: multi-buffer support Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 01/22] xsk: prepare 'options' in xdp_desc for multi-buffer use Maciej Fijalkowski
2023-06-22 19:02 ` Benjamin Poirier
2023-06-26 13:18 ` Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 02/22] xsk: introduce XSK_USE_SG bind flag for xsk socket Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 03/22] xsk: prepare both copy and zero-copy modes to co-exist Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 04/22] xsk: move xdp_buff's data length check to xsk_rcv_check Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 05/22] xsk: add support for AF_XDP multi-buffer on Rx path Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 06/22] xsk: introduce wrappers and helpers for supporting multi-buffer in Tx path Maciej Fijalkowski
2023-06-20 17:25 ` Toke Høiland-Jørgensen
2023-06-21 8:15 ` Sarkar, Tirthendu
2023-06-21 13:27 ` Toke Høiland-Jørgensen [this message]
2023-06-15 17:25 ` [PATCH v4 bpf-next 07/22] xsk: allow core/drivers to test EOP bit Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 08/22] xsk: add support for AF_XDP multi-buffer on Tx path Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 09/22] xsk: discard zero length descriptors in " Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 10/22] xsk: support mbuf on ZC RX Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 11/22] ice: xsk: add RX multi-buffer support Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 12/22] xsk: support ZC Tx multi-buffer in batch API Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 13/22] xsk: report zero-copy multi-buffer capability via xdp_features Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 14/22] ice: xsk: Tx multi-buffer support Maciej Fijalkowski
2023-06-15 17:25 ` [PATCH v4 bpf-next 15/22] xsk: add multi-buffer documentation Maciej Fijalkowski
2023-06-20 17:34 ` Toke Høiland-Jørgensen
2023-06-21 8:06 ` Magnus Karlsson
2023-06-21 13:30 ` Toke Høiland-Jørgensen
2023-06-21 14:15 ` Magnus Karlsson
2023-06-21 20:34 ` Jakub Kicinski
2023-06-22 8:24 ` Magnus Karlsson
2023-06-22 10:56 ` Toke Høiland-Jørgensen
[not found] ` <ZJx9WkB/dfB5EFjE@boxer>
2023-06-28 20:28 ` Jakub Kicinski
2023-06-28 21:02 ` Toke Høiland-Jørgensen
2023-06-29 20:28 ` Maciej Fijalkowski
2023-06-29 20:57 ` Toke Høiland-Jørgensen
2023-06-30 18:00 ` Maciej Fijalkowski
2023-07-01 13:51 ` Toke Høiland-Jørgensen
2023-06-15 17:26 ` [PATCH v4 bpf-next 16/22] selftests/xsk: transmit and receive multi-buffer packets Maciej Fijalkowski
2023-06-15 17:26 ` [PATCH v4 bpf-next 17/22] selftests/xsk: add basic multi-buffer test Maciej Fijalkowski
2023-06-15 17:26 ` [PATCH v4 bpf-next 18/22] selftests/xsk: add unaligned mode test for multi-buffer Maciej Fijalkowski
2023-06-15 17:26 ` [PATCH v4 bpf-next 19/22] selftests/xsk: add invalid descriptor " Maciej Fijalkowski
2023-06-15 17:26 ` [PATCH v4 bpf-next 20/22] selftests/xsk: add metadata copy test for multi-buff Maciej Fijalkowski
2023-06-15 17:26 ` [PATCH v4 bpf-next 21/22] selftests/xsk: add test for too many frags Maciej Fijalkowski
2023-06-15 17:26 ` [PATCH v4 bpf-next 22/22] selftests/xsk: reset NIC settings to default after running test suite Maciej Fijalkowski
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=87r0q5c5e3.fsf@toke.dk \
--to=toke@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).