All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Niigee Mashook <mashookniigee@gmail.com>
Cc: Potnuri Bharat Teja <bharat@chelsio.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org
Subject: Re: Questions about the chelsio/cxgb3 Driver - TX Stall
Date: Sun, 14 Jul 2024 08:22:56 -0700	[thread overview]
Message-ID: <20240714082256.53fa86b8@kernel.org> (raw)
In-Reply-To: <CAN9Uquc9Ji2o4WA-Bo6JCY-4X4G54KaLPS1c5VOcCbhWMkR0KQ@mail.gmail.com>

On Wed, 10 Jul 2024 21:19:57 +0800 Niigee Mashook wrote:
> 1. Why is not using Tx completion interrupts considered better?
> One reason I can think of is that reducing interrupts to the CPU can
> improve overall performance by allowing the CPU to handle packets more
> efficiently. However, I am concerned that using skb_orphan might cause
> issues like invalidating autocork and leading to bufferbloat(TSQ's
> functionality), which could negatively impact performance. Would this
> not cause a performance regression?

Indeed, this method will have negative effects on any backpressure
mechanism. It's an old driver 🤷️ The perf benefit comes as you say
from fewer IRQs and very good batching.

> 2. The comment specifically mentions skb_orphan, and not using it
> would cause a Tx stall. Why is that?
> My understanding is that when sk->sk_sndbuf is small, it might allow
> only the first packet to be sent. Without skb_orphan, after sending
> the first packet, sk->sk_sndbuf becomes equal to sk_wmem_alloc, which
> would prevent subsequent packets from being sent. As a result,
> sk_wmem_alloc would never decrease, leading to a Tx stall. Is this
> correct?

Yes, pretty much.

      reply	other threads:[~2024-07-14 15:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-10 13:19 Questions about the chelsio/cxgb3 Driver - TX Stall Niigee Mashook
2024-07-14 15:22 ` Jakub Kicinski [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=20240714082256.53fa86b8@kernel.org \
    --to=kuba@kernel.org \
    --cc=bharat@chelsio.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=mashookniigee@gmail.com \
    --cc=netdev@vger.kernel.org \
    --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 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.