Intel-Wired-Lan Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander H Duyck <alexander.duyck@gmail.com>
To: Tirthendu Sarkar <tirthendu.sarkar@intel.com>,
	tirtha@gmail.com,  jesse.brandeburg@intel.com,
	anthony.l.nguyen@intel.com, davem@davemloft.net,
	 edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	ast@kernel.org,  daniel@iogearbox.net, hawk@kernel.org,
	john.fastabend@gmail.com,  intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
	linux-kernel@vger.kernel.org, magnus.karlsson@intel.com
Subject: Re: [Intel-wired-lan] [PATCH intel-next 4/5] i40e: pull out rx buffer allocation to end of i40e_clean_rx_irq()
Date: Tue, 13 Dec 2022 08:09:15 -0800	[thread overview]
Message-ID: <08bd63d5de4ea8814ddd58c51ca6d1c17d0990e6.camel@gmail.com> (raw)
In-Reply-To: <20221213105023.196409-5-tirthendu.sarkar@intel.com>

On Tue, 2022-12-13 at 16:20 +0530, Tirthendu Sarkar wrote:
> Previously i40e_alloc_rx_buffers() was called for every 32 cleaned
> buffers. For multi-buffers this may not be optimal as there may be more
> cleaned buffers in each i40e_clean_rx_irq() call. So this is now pulled
> out of the loop and moved to the end of i40e_clean_rx_irq().
> 
> As a consequence instead of counting the number of buffers to be cleaned,
> I40E_DESC_UNUSED() can be used to call i40e_alloc_rx_buffers().
> 
> Signed-off-by: Tirthendu Sarkar <tirthendu.sarkar@intel.com>

I suspect this will lead to performance issues on systems configured
with smaller ring sizes. Specifically with this change you are limiting
things to only allocating every 64 (NAPI_POLL_WEIGHT/budget) packets.

> ---
>  drivers/net/ethernet/intel/i40e/i40e_txrx.c | 12 ++----------
>  1 file changed, 2 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> index e01bcc91a196..dc9dc0acdd37 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> @@ -2425,7 +2425,6 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget,
>  			     unsigned int *rx_cleaned)
>  {
>  	unsigned int total_rx_bytes = 0, total_rx_packets = 0, frame_sz = 0;
> -	u16 cleaned_count = I40E_DESC_UNUSED(rx_ring);
>  	unsigned int offset = rx_ring->rx_offset;
>  	struct sk_buff *skb = rx_ring->skb;
>  	u16 ntp = rx_ring->next_to_process;
> @@ -2450,13 +2449,6 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget,
>  		unsigned int size;
>  		u64 qword;
>  
> -		/* return some buffers to hardware, one at a time is too slow */
> -		if (cleaned_count >= I40E_RX_BUFFER_WRITE) {
> -			failure = failure ||
> -				  i40e_alloc_rx_buffers(rx_ring, cleaned_count);
> -			cleaned_count = 0;
> -		}
> -
>  		rx_desc = I40E_RX_DESC(rx_ring, ntp);
>  
>  		/* status_error_len will always be zero for unused descriptors
> @@ -2479,7 +2471,6 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget,
>  			rx_buffer = i40e_rx_bi(rx_ring, ntp);
>  			I40E_INC_NEXT(ntp, ntc, rmax);
>  			i40e_reuse_rx_page(rx_ring, rx_buffer);
> -			cleaned_count++;
>  			continue;
>  		}
>  
> @@ -2531,7 +2522,6 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget,
>  		}
>  
>  		i40e_put_rx_buffer(rx_ring, rx_buffer);
> -		cleaned_count++;
>  
>  		I40E_INC_NEXT(ntp, ntc, rmax);
>  		if (i40e_is_non_eop(rx_ring, rx_desc))
> @@ -2558,6 +2548,8 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget,
>  	rx_ring->next_to_process = ntp;
>  	rx_ring->next_to_clean = ntc;
>  
> +	failure = i40e_alloc_rx_buffers(rx_ring, I40E_DESC_UNUSED(rx_ring));
> +
>  	i40e_finalize_xdp_rx(rx_ring, xdp_xmit);
>  	rx_ring->skb = skb;

I am not a fan of this "failure" approach either. I hadn't noticed it
before but it is problematic. It would make much more sense to take an
approach similar to what we did for Tx where we kick the ring
periodically if it looks like it is stuck, in this case empty.

The problem is if you have memory allocation issues the last thing you
probably need is a NIC deciding to become memory hungry itself and
sticking in an allocation loop.
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

  reply	other threads:[~2022-12-13 16:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-13 10:50 [Intel-wired-lan] [PATCH intel-next 0/5] i40e: support XDP multi-buffer Tirthendu Sarkar
2022-12-13 10:50 ` [Intel-wired-lan] [PATCH intel-next 1/5] i40e: add pre-xdp page_count in rx_buffer Tirthendu Sarkar
2022-12-13 10:50 ` [Intel-wired-lan] [PATCH intel-next 2/5] i40e: avoid per buffer next_to_clean access from i40e_ring Tirthendu Sarkar
2022-12-13 10:50 ` [Intel-wired-lan] [PATCH intel-next 3/5] i40e: introduce next_to_process to i40e_ring Tirthendu Sarkar
2022-12-13 10:50 ` [Intel-wired-lan] [PATCH intel-next 4/5] i40e: pull out rx buffer allocation to end of i40e_clean_rx_irq() Tirthendu Sarkar
2022-12-13 16:09   ` Alexander H Duyck [this message]
2022-12-13 10:50 ` [Intel-wired-lan] [PATCH intel-next 5/5] i40e: add support for XDP multi-buffer Rx Tirthendu Sarkar
2022-12-13 13:14   ` kernel test robot
2022-12-13 15:58 ` [Intel-wired-lan] [PATCH intel-next 0/5] i40e: support XDP multi-buffer Alexander H Duyck
2022-12-14 15:56   ` Sarkar, Tirthendu
2022-12-14 17:16     ` Alexander Duyck

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=08bd63d5de4ea8814ddd58c51ca6d1c17d0990e6.camel@gmail.com \
    --to=alexander.duyck@gmail.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=tirtha@gmail.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