netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net
Cc: netdev@vger.kernel.org, magnus.karlsson@intel.com,
	bjorn@kernel.org, kuba@kernel.org,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Subject: RE: [PATCH v4 bpf-next 09/10] selftests: xsk: rely on pkts_in_flight in wait_for_tx_completion()
Date: Fri, 17 Jun 2022 19:56:17 -0700	[thread overview]
Message-ID: <62ad3ed172224_24b342084d@john.notmuch> (raw)
In-Reply-To: <20220616180609.905015-10-maciej.fijalkowski@intel.com>

Maciej Fijalkowski wrote:
> Some of the drivers that implement support for AF_XDP Zero Copy (like
> ice) can have lazy approach for cleaning Tx descriptors. For ZC, when
> descriptor is cleaned, it is placed onto AF_XDP completion queue. This
> means that current implementation of wait_for_tx_completion() in
> xdpxceiver can get onto infinite loop, as some of the descriptors can
> never reach CQ.
> 
> This function can be changed to rely on pkts_in_flight instead.
> 
> Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
> Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> ---

Sorry I'm going to need more details to follow whats going on here.

In send_pkts() we do the expected thing and send all the pkts and
then call wait_for_tx_completion().

Wait for completion is obvious,

 static void wait_for_tx_completion(struct xsk_socket_info *xsk)               
 {                                                   
        while (xsk->outstanding_tx)                                                      
                complete_pkts(xsk, BATCH_SIZE);
 }  

the 'outstanding_tx' counter appears to be decremented in complete_pkts().
This is done by looking at xdk_ring_cons__peek() makes sense to me until
it shows up here we don't know the pkt has been completely sent and
can release the resources.

Now if you just zero it on exit and call it good how do you know the
resources are safe to clean up? Or that you don't have a real bug
in the driver that isn't correctly releasing the resource.

How are users expected to use a lazy approach to tx descriptor cleaning
in this case e.g. on exit like in this case. It seems we need to
fix the root cause of ice not putting things on the completion queue
or I misunderstood the patch.


>  tools/testing/selftests/bpf/xdpxceiver.c | 3 ++-
>  tools/testing/selftests/bpf/xdpxceiver.h | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/testing/selftests/bpf/xdpxceiver.c b/tools/testing/selftests/bpf/xdpxceiver.c
> index de4cf0432243..13a3b2ac2399 100644
> --- a/tools/testing/selftests/bpf/xdpxceiver.c
> +++ b/tools/testing/selftests/bpf/xdpxceiver.c
> @@ -965,7 +965,7 @@ static int __send_pkts(struct ifobject *ifobject, u32 *pkt_nb)
>  
>  static void wait_for_tx_completion(struct xsk_socket_info *xsk)
>  {
> -	while (xsk->outstanding_tx)
> +	while (pkts_in_flight)
>  		complete_pkts(xsk, BATCH_SIZE);
>  }
>  
> @@ -1269,6 +1269,7 @@ static void *worker_testapp_validate_rx(void *arg)
>  		pthread_mutex_unlock(&pacing_mutex);
>  	}
>  
> +	pkts_in_flight = 0;
>  	pthread_exit(NULL);
>  }

  reply	other threads:[~2022-06-18  2:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-16 18:05 [PATCH v4 bpf-next 00/10] AF_XDP ZC selftests Maciej Fijalkowski
2022-06-16 18:06 ` [PATCH v4 bpf-next 01/10] ice: compress branches in ice_set_features() Maciej Fijalkowski
2022-06-18  1:46   ` John Fastabend
2022-06-20  9:48     ` Maciej Fijalkowski
2022-06-16 18:06 ` [PATCH v4 bpf-next 02/10] ice: allow toggling loopback mode via ndo_set_features callback Maciej Fijalkowski
2022-06-16 18:21   ` Jakub Kicinski
2022-06-18  1:57   ` John Fastabend
2022-06-20  9:52     ` Maciej Fijalkowski
2022-06-16 18:06 ` [PATCH v4 bpf-next 03/10] ice: check DD bit on Rx descriptor rather than (EOP | RS) Maciej Fijalkowski
2022-06-18  1:58   ` John Fastabend
2022-06-20 10:53     ` Maciej Fijalkowski
2022-06-16 18:06 ` [PATCH v4 bpf-next 04/10] ice: do not setup vlan for loopback VSI Maciej Fijalkowski
2022-06-18  2:01   ` John Fastabend
2022-06-16 18:06 ` [PATCH v4 bpf-next 05/10] selftests: xsk: query for native XDP support Maciej Fijalkowski
2022-06-18  2:12   ` John Fastabend
2022-06-20 10:55     ` Maciej Fijalkowski
2022-06-16 18:06 ` [PATCH v4 bpf-next 06/10] selftests: xsk: add missing close() on netns fd Maciej Fijalkowski
2022-06-18  2:14   ` John Fastabend
2022-06-16 18:06 ` [PATCH v4 bpf-next 07/10] selftests: xsk: introduce default Rx pkt stream Maciej Fijalkowski
2022-06-18  2:41   ` John Fastabend
2022-06-20  8:41     ` Magnus Karlsson
2022-06-16 18:06 ` [PATCH v4 bpf-next 08/10] selftests: xsk: add support for executing tests on physical device Maciej Fijalkowski
2022-06-16 18:06 ` [PATCH v4 bpf-next 09/10] selftests: xsk: rely on pkts_in_flight in wait_for_tx_completion() Maciej Fijalkowski
2022-06-18  2:56   ` John Fastabend [this message]
2022-06-20 12:02     ` Maciej Fijalkowski
2022-06-20 16:36       ` John Fastabend
2022-06-16 18:06 ` [PATCH v4 bpf-next 10/10] selftests: xsk: add support for zero copy testing 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=62ad3ed172224_24b342084d@john.notmuch \
    --to=john.fastabend@gmail.com \
    --cc=ast@kernel.org \
    --cc=bjorn@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kuba@kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=magnus.karlsson@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).