All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Jesper Dangaard Brouer <jbrouer@redhat.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
	magnus.karlsson@intel.com, bjorn@kernel.org, brouer@redhat.com,
	netdev@vger.kernel.org, maximmi@nvidia.com,
	alexandr.lobakin@intel.com
Subject: Re: [PATCH bpf-next 05/10] ixgbe: xsk: terminate NAPI when XSK Rx queue gets full
Date: Tue, 5 Apr 2022 15:52:36 +0200	[thread overview]
Message-ID: <YkxJpLPMkUrl1hoZ@boxer> (raw)
In-Reply-To: <88cf07a2-3bb6-5eda-0d99-d9491fd18669@redhat.com>

On Tue, Apr 05, 2022 at 02:36:41PM +0200, Jesper Dangaard Brouer wrote:
> 
> On 05/04/2022 13.06, Maciej Fijalkowski wrote:
> > Correlate -ENOBUFS that was returned from xdp_do_redirect() with a XSK
> > Rx queue being full. In such case, terminate the softirq processing and
> > let the user space to consume descriptors from XSK Rx queue so that
> > there is room that driver can use later on.
> > 
> > Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> > ---
> >   .../ethernet/intel/ixgbe/ixgbe_txrx_common.h  |  1 +
> >   drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c  | 23 ++++++++++++-------
> >   2 files changed, 16 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_txrx_common.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_txrx_common.h
> > index bba3feaf3318..f1f69ce67420 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_txrx_common.h
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_txrx_common.h
> > @@ -8,6 +8,7 @@
> >   #define IXGBE_XDP_CONSUMED	BIT(0)
> >   #define IXGBE_XDP_TX		BIT(1)
> >   #define IXGBE_XDP_REDIR		BIT(2)
> > +#define IXGBE_XDP_EXIT		BIT(3)
> >   #define IXGBE_TXD_CMD (IXGBE_TXD_CMD_EOP | \
> >   		       IXGBE_TXD_CMD_RS)
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> > index dd7ff66d422f..475244a2c6e4 100644
> > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> > @@ -109,9 +109,10 @@ static int ixgbe_run_xdp_zc(struct ixgbe_adapter *adapter,
> >   	if (likely(act == XDP_REDIRECT)) {
> >   		err = xdp_do_redirect(rx_ring->netdev, xdp, xdp_prog);
> > -		if (err)
> > -			goto out_failure;
> > -		return IXGBE_XDP_REDIR;
> > +		if (!err)
> > +			return IXGBE_XDP_REDIR;
> > +		result = (err == -ENOBUFS) ? IXGBE_XDP_EXIT : IXGBE_XDP_CONSUMED;
> > +		goto out_failure;
> >   	}
> >   	switch (act) {
> > @@ -130,6 +131,9 @@ static int ixgbe_run_xdp_zc(struct ixgbe_adapter *adapter,
> >   		if (result == IXGBE_XDP_CONSUMED)
> >   			goto out_failure;
> >   		break;
> > +	case XDP_DROP:
> > +		result = IXGBE_XDP_CONSUMED;
> > +		break;
> >   	default:
> >   		bpf_warn_invalid_xdp_action(rx_ring->netdev, xdp_prog, act);
> >   		fallthrough;
> > @@ -137,9 +141,6 @@ static int ixgbe_run_xdp_zc(struct ixgbe_adapter *adapter,
> >   out_failure:
> >   		trace_xdp_exception(rx_ring->netdev, xdp_prog, act);
> >   		fallthrough; /* handle aborts by dropping packet */
> > -	case XDP_DROP:
> > -		result = IXGBE_XDP_CONSUMED;
> > -		break;
> >   	}
> >   	return result;
> >   }
> > @@ -304,10 +305,16 @@ int ixgbe_clean_rx_irq_zc(struct ixgbe_q_vector *q_vector,
> >   		xdp_res = ixgbe_run_xdp_zc(adapter, rx_ring, bi->xdp);
> >   		if (xdp_res) {
> > -			if (xdp_res & (IXGBE_XDP_TX | IXGBE_XDP_REDIR))
> > +			if (xdp_res == IXGBE_XDP_EXIT) {
> 
> Micro optimization note: Having this as the first if()-statement
> defaults the compiler to think this is the likely() case. (But compilers
> can obviously be smarter and can easily choose that the IXGBE_XDP_REDIR
> branch is so simple that it takes it as the likely case).
> Just wanted to mention this, given this is fash-path code.

Good point. Since we're 'likely-fying' redirect path in
ixgbe_run_xdp_zc(), maybe it would make sense to make the branch that does
xdp_res & IXGBE_XDP_REDIR check as the likely() one.

> 
> > +				failure = true;
> > +				xsk_buff_free(bi->xdp);
> > +				ixgbe_inc_ntc(rx_ring);
> > +				break;
> 
> I was wondering if we have a situation where we should set xdp_xmit bit
> to trigger the call to xdp_do_flush_map later in function, but I assume
> you have this covered.

For every previous successful redirect xdp_xmit will be set with
corresponding bits that came out of ixgbe_run_xdp_zc(), so if we got to
the point of full XSK Rx queue, xdp_do_flush_map() will be called
eventually. Before doing so, idea is to give the current buffer back to
the XSK buffer pool and increment the "next_to_clean" which acts as the
head pointer on HW Rx ring. IOW, consume the current buffer/descriptor and
yield the CPU to the user space.

> 
> > +			} else if (xdp_res & (IXGBE_XDP_TX | IXGBE_XDP_REDIR)) {
> >   				xdp_xmit |= xdp_res;
> > -			else
> > +			} else {
> >   				xsk_buff_free(bi->xdp);
> > +			}
> >   			bi->xdp = NULL;
> >   			total_rx_packets++;
> 

  reply	other threads:[~2022-04-06  0:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-05 11:06 [PATCH bpf-next 00/10] xsk: stop softirq processing on full XSK Rx queue Maciej Fijalkowski
2022-04-05 11:06 ` [PATCH bpf-next 01/10] xsk: improve xdp_do_redirect() error codes Maciej Fijalkowski
2022-04-05 12:18   ` Jesper Dangaard Brouer
2022-04-05 11:06 ` [PATCH bpf-next 02/10] xsk: diversify return codes in xsk_rcv_check() Maciej Fijalkowski
2022-04-05 13:00   ` Jesper Dangaard Brouer
2022-04-05 13:35     ` Maciej Fijalkowski
2022-04-05 11:06 ` [PATCH bpf-next 03/10] ice: xsk: terminate NAPI when XSK Rx queue gets full Maciej Fijalkowski
2022-04-05 11:34   ` Alexander Lobakin
2022-04-05 12:02     ` Maciej Fijalkowski
2022-04-05 11:06 ` [PATCH bpf-next 04/10] i40e: " Maciej Fijalkowski
2022-04-05 13:04   ` Jesper Dangaard Brouer
2022-04-06 16:04     ` Maciej Fijalkowski
2022-04-05 11:06 ` [PATCH bpf-next 05/10] ixgbe: " Maciej Fijalkowski
2022-04-05 12:36   ` Jesper Dangaard Brouer
2022-04-05 13:52     ` Maciej Fijalkowski [this message]
2022-04-05 11:06 ` [PATCH bpf-next 06/10] ice: xsk: diversify return values from xsk_wakeup call paths Maciej Fijalkowski
2022-04-05 11:06 ` [PATCH bpf-next 07/10] i40e: " Maciej Fijalkowski
2022-04-05 11:06 ` [PATCH bpf-next 08/10] ixgbe: " Maciej Fijalkowski
2022-04-05 11:06 ` [PATCH bpf-next 09/10] ice: xsk: avoid refilling single Rx descriptors Maciej Fijalkowski
2022-04-05 11:06 ` [PATCH bpf-next 10/10] xsk: drop ternary operator from xskq_cons_has_entries Maciej Fijalkowski
2022-04-07 10:49 ` [PATCH bpf-next 00/10] xsk: stop softirq processing on full XSK Rx queue Maxim Mikityanskiy
2022-04-08  9:08   ` Maciej Fijalkowski
2022-04-08 12:48     ` Maxim Mikityanskiy
2022-04-08 18:17       ` Jakub Kicinski
2022-04-11 15:46         ` Maciej Fijalkowski
2022-04-11 17:07           ` Jakub Kicinski
2022-04-11 15:35       ` Maciej Fijalkowski
2022-04-13 10:40         ` Maxim Mikityanskiy
2022-04-13 15:12           ` Magnus Karlsson
2022-04-13 15:26             ` 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=YkxJpLPMkUrl1hoZ@boxer \
    --to=maciej.fijalkowski@intel.com \
    --cc=alexandr.lobakin@intel.com \
    --cc=ast@kernel.org \
    --cc=bjorn@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=jbrouer@redhat.com \
    --cc=magnus.karlsson@intel.com \
    --cc=maximmi@nvidia.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 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.