mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolai Buchwitz <nb@tipi-net.de>
To: Florian Fainelli <florian.fainelli@broadcom.com>
Cc: Doug Berger <opendmb@gmail.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Justin Chen <justin.chen@broadcom.com>,
	Broadcom internal kernel review list
	<bcm-kernel-feedback-list@broadcom.com>,
	Nikolay Aleksandrov <razor@blackwall.org>,
	Jason Xing <kerneljasonxing@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net: bcmgenet: cap the Tx queue threshold at the ring size
Date: Sat, 07 Nov 2026 12:53:04 +0100	[thread overview]
Message-ID: <6c0446dbe8e63a7c6a6120d4a1d6ad0a@tipi-net.de> (raw)
In-Reply-To: <1b33c10e-fa25-427a-92a6-d26669712f09@broadcom.com>

Hi Florian

On 7.11.2026 01:14, Florian Fainelli wrote:

> [...]

> Eventually we will have to decide what to do with those other queues :D

Probably sooner than later. Sashiko claims that this patch does not 
fully
fix hte CONFIG_MAX_SKB_FRAGS=31 case. The check in bcmgenet_xmit()

         if (ring->free_bds <= (nr_frags + 1))

wants 33 free descriptors for a 31 frag skb and those rings hold 32. 
Arguably
the bug is way older than this patch and you need a non-default config 
to hit.

So IMHO the options are:
Either linearize in bcmgenet_xmit() when the frame does not fit, or we 
drop
the queues as I proposed in June [1]?

With XDP in mind the second one seems more attractive, as it needs its 
own 64
descriptor ring. With the current split the main queue would end up with 
64
descriptors, against 192 if the queues are collapsed.

[1] 
https://lore.kernel.org/netdev/20260612205915.3156127-1-nb@tipi-net.de/

Regards
Nicolai

      reply	other threads:[~2026-11-07 11:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06 14:10 Nicolai Buchwitz
2026-11-07  0:14 ` Florian Fainelli
2026-11-07 11:53   ` Nicolai Buchwitz [this message]

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=6c0446dbe8e63a7c6a6120d4a1d6ad0a@tipi-net.de \
    --to=nb@tipi-net.de \
    --cc=andrew+netdev@lunn.ch \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=florian.fainelli@broadcom.com \
    --cc=justin.chen@broadcom.com \
    --cc=kerneljasonxing@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=opendmb@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=razor@blackwall.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
all inboxes | Powered by JetHome®