All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Joe Damato <joe@dama.to>
Cc: netdev@vger.kernel.org, Michael Chan <michael.chan@broadcom.com>,
	Pavan Chebbi <pavan.chebbi@broadcom.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	horms@kernel.org, linux-kernel@vger.kernel.org, leon@kernel.org
Subject: Re: [net-next v9 07/10] net: bnxt: Implement software USO
Date: Wed, 8 Apr 2026 11:06:52 -0700	[thread overview]
Message-ID: <20260408110652.652e4732@kernel.org> (raw)
In-Reply-To: <adaKt/VwrajKraR8@devvm20253.cco0.facebook.com>

On Wed, 8 Apr 2026 10:04:55 -0700 Joe Damato wrote:
> > This is the check I added. AI says this is wrong and netdev_queues.h says:
> > 
> >   * @get_desc must be a formula or a function call, it must always
> >   * return up-to-date information when evaluated!
> > 
> > which I obviously failed to do, so I'm pretty sure I got this wrong.  
> 
> So, there's two options to fix this that I can think of. I am leaning torward
> option 2, but if there are any strong opinions (or other options that I am
> missing) please let me know:
> 
>   1. Allocate the maximum number of slots per ring and eliminate this check
>      entirely. I figured this would be disliked because it potentially wastes
>      memory. The driver would need ring_size / 3 slots, and if we assume the
>      maximum is 2048 and the slot size is 256b, that works out to 175kb per
>      ring. Of course, this only affects NICs with SW USO and the buffer isn't
>      allocated for NICS with HW USO.
> 
>      This is probably simpler, but costs more memory than the existing design.
> 
>    2. Or, keep the smaller buffer that we have now (BNXT_SW_USO_MAX_SEGS (64)
>       * 256b = 16kb per ring) and fix the try_stop like this:
> 
> +static inline u16 bnxt_inline_avail(struct bnxt_tx_ring_info *txr)
> +{
> +       return BNXT_SW_USO_MAX_SEGS -
> +              (u16)(txr->tx_inline_prod - READ_ONCE(txr->tx_inline_cons));
> +}
> +
> 
> -       slots = txr->tx_inline_prod - txr->tx_inline_cons;
> -       slots = BNXT_SW_USO_MAX_SEGS - slots;
> -
> -       if (unlikely(slots < num_segs)) {
> -               netif_txq_try_stop(txq, slots, num_segs);
> +       if (unlikely(bnxt_inline_avail(txr) < num_segs)) {
> +               netif_txq_try_stop(txq, bnxt_inline_avail(txr), num_segs);

I think option 2 makes sense. The point (which I think you got) is that
the condition must be evaluated after the memory barrier.

Since the condition is repeated in your latest snippet - you can
probably use netif_txq_maybe_stop() ?

  reply	other threads:[~2026-04-08 18:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-07 22:02 [net-next v9 00/10] Add TSO map-once DMA helpers and bnxt SW USO support Joe Damato
2026-04-07 22:02 ` [net-next v9 01/10] net: tso: Introduce tso_dma_map and helpers Joe Damato
2026-04-07 22:02 ` [net-next v9 02/10] net: bnxt: Export bnxt_xmit_get_cfa_action Joe Damato
2026-04-07 22:02 ` [net-next v9 03/10] net: bnxt: Add a helper for tx_bd_ext Joe Damato
2026-04-07 22:03 ` [net-next v9 04/10] net: bnxt: Use dma_unmap_len for TX completion unmapping Joe Damato
2026-04-07 22:03 ` [net-next v9 05/10] net: bnxt: Add TX inline buffer infrastructure Joe Damato
2026-04-07 22:03 ` [net-next v9 06/10] net: bnxt: Add boilerplate GSO code Joe Damato
2026-04-07 22:03 ` [net-next v9 07/10] net: bnxt: Implement software USO Joe Damato
2026-04-07 23:23   ` Joe Damato
2026-04-08 17:04     ` Joe Damato
2026-04-08 18:06       ` Jakub Kicinski [this message]
2026-04-08 18:49         ` Joe Damato
2026-04-07 22:03 ` [net-next v9 08/10] net: bnxt: Add SW GSO completion and teardown support Joe Damato
2026-04-07 22:03 ` [net-next v9 09/10] net: bnxt: Dispatch to SW USO Joe Damato
2026-04-07 22:03 ` [net-next v9 10/10] selftests: drv-net: Add USO test Joe Damato
2026-04-08  3:14   ` Jakub Kicinski

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=20260408110652.652e4732@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=joe@dama.to \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavan.chebbi@broadcom.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 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.