From: Justin Chen <justin.chen@broadcom.com>
To: Nicolai Buchwitz <nb@tipi-net.de>
Cc: netdev@vger.kernel.org, pabeni@redhat.com, kuba@kernel.org,
edumazet@google.com, davem@davemloft.net, andrew+netdev@lunn.ch,
bcm-kernel-feedback-list@broadcom.com,
florian.fainelli@broadcom.com, opendmb@gmail.com
Subject: Re: [PATCH net v2 4/4] net: bcmgenet: relax the xmit ring full case
Date: Wed, 1 Apr 2026 11:48:03 -0700 [thread overview]
Message-ID: <342750cc-d5b1-4446-a974-9feea4969f17@broadcom.com> (raw)
In-Reply-To: <71b87f5416d6d6d41396b5008702ccac@tipi-net.de>
On 4/1/26 12:47 AM, Nicolai Buchwitz wrote:
> On 1.4.2026 02:38, Justin Chen wrote:
>> We have a queue size of 32. If a packet is multiple fragments we can
>> run through this queue really quickly. Currently we stop the xmit
>> queue at SKB_FRAG_SIZE which by default can take up half the queue.
>> Instead lets just look at the incoming packet and freeze the queue
>> if the incoming packet has more fragments than free_bds. This will
>> relieve some of the queue timeouts we have been seeing.
>>
>> Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
>> Signed-off-by: Justin Chen <justin.chen@broadcom.com>
>> ---
>> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 9 +++------
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/
>> net/ethernet/broadcom/genet/bcmgenet.c
>> index 54f71b1e85fc..a1aa1278842e 100644
>> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> @@ -2018,10 +2018,10 @@ static int bcmgenet_tx_poll(struct napi_struct
>> *napi, int budget)
>>
>> spin_lock(&ring->lock);
>> work_done = __bcmgenet_tx_reclaim(ring->priv->dev, ring);
>> - if (ring->free_bds > (MAX_SKB_FRAGS + 1)) {
>> - txq = netdev_get_tx_queue(ring->priv->dev, ring->index);
>> + txq = netdev_get_tx_queue(ring->priv->dev, ring->index);
>> + if (netif_tx_queue_stopped(txq))
>> netif_tx_wake_queue(txq);
>> - }
>> +
>> spin_unlock(&ring->lock);
>>
>> if (work_done == 0) {
>> @@ -2224,9 +2224,6 @@ static netdev_tx_t bcmgenet_xmit(struct sk_buff
>> *skb, struct net_device *dev)
>>
>> netdev_tx_sent_queue(txq, GENET_CB(skb)->bytes_sent);
>>
>> - if (ring->free_bds <= (MAX_SKB_FRAGS + 1))
>> - netif_tx_stop_queue(txq);
>> -
>
> With this removed, the only queue stop is the NETDEV_TX_BUSY path at
> entry. That means every ring-full hits BUSY and requeues rather than
> stopping proactively on the previous transmit.
>
> Would it work to keep the proactive stop but base it on the actual
> packet size instead of MAX_SKB_FRAGS?
>
> if (ring->free_bds <= (nr_frags + 1))
> netif_tx_stop_queue(txq);
>
> That avoids reserving half the ring for the worst case while still
> preventing BUSY from becoming the normal path.
>
>> if (!netdev_xmit_more() || netif_xmit_stopped(txq))
>> /* Packets are ready, update producer index */
>> bcmgenet_tdma_ring_writel(priv, ring->index,
>
> This wakes unconditionally even if only 1 BD was reclaimed. Combined
> with the above, it can create a tight stop/wake/BUSY thrash when the
> ring is near-full.
>
That is fair. Let me drop this patch entirely. Seems like we are trading
one problem for another problem. Maybe removing the priority queues
entirely is the way to go. I will wait for the XDP patches to be applied
first to avoid conflicts.
Thanks,
Justin
> Thanks
>
> Nicolai
prev parent reply other threads:[~2026-04-01 18:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-01 0:38 [PATCH net v2 0/4] fix queue lock up and reduce timeouts Justin Chen
2026-04-01 0:38 ` [PATCH net v2 1/4] net: bcmgenet: fix off-by-one in bcmgenet_put_txcb Justin Chen
2026-04-01 7:41 ` Nicolai Buchwitz
2026-04-01 0:38 ` [PATCH net v2 2/4] net: bcmgenet: fix leaking free_bds Justin Chen
2026-04-01 0:38 ` [PATCH net v2 3/4] net: bcmgenet: fix racing timeout handler Justin Chen
2026-04-01 0:38 ` [PATCH net v2 4/4] net: bcmgenet: relax the xmit ring full case Justin Chen
2026-04-01 7:47 ` Nicolai Buchwitz
2026-04-01 18:48 ` Justin Chen [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=342750cc-d5b1-4446-a974-9feea4969f17@broadcom.com \
--to=justin.chen@broadcom.com \
--cc=andrew+netdev@lunn.ch \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=kuba@kernel.org \
--cc=nb@tipi-net.de \
--cc=netdev@vger.kernel.org \
--cc=opendmb@gmail.com \
--cc=pabeni@redhat.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