All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: <yang.yang29@zte.com.cn>
Cc: <davem@davemloft.net>, <edumazet@google.com>, <pabeni@redhat.com>,
	<bigeasy@linutronix.de>, <imagedong@tencent.com>,
	<kuniyu@amazon.com>, <petrm@nvidia.com>, <liu3101@purdue.edu>,
	<wujianguo@chinatelecom.cn>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <tedheadster@gmail.com>
Subject: Re: [PATCH linux-next] net: record times of netdev_budget exhausted
Date: Mon, 5 Dec 2022 18:47:42 -0800	[thread overview]
Message-ID: <20221205184742.0952fc75@kernel.org> (raw)
In-Reply-To: <202212061035074041030@zte.com.cn>

On Tue, 6 Dec 2022 10:35:07 +0800 (CST) yang.yang29@zte.com.cn wrote:
> The author of "Replace 2 jiffies with sysctl netdev_budget_usecs
> to enable softirq tuning" is Matthew Whitehead, he said this in
> git log: Constants used for tuning are generally a bad idea, especially
> as hardware changes over time...For example, a very fast machine
> might tune this to 1000 microseconds, while my regression testing
> 486DX-25 needs it to be 4000 microseconds on a nearly idle network
> to prevent time_squeeze from being incremented.

Let's just ignore that on the basis that it mentions prehistoric HW ;)

> And on my systems there are huge packets on the intranet, and we
> came accross with lots of time_squeeze. The idea is that, netdev_budget*
> are selections between throughput and real-time. If we care throughput
> and not care real-time so much, we may want bigger netdev_budget*.

But are you seeing actual performance wins in terms of throughput 
or latency? 

As I said time_squeeze is very noisy. In my experience it's very
sensitive to issues with jiffies, like someone masking interrupts on
the timekeeper CPU for a long time (which if you use cgroups happens
_a lot_ :/).

Have you tried threaded NAPI? (find files called 'threaded' in sysfs)
It will let you do any such tuning much more flexibly.

> In this scenario, we want to tune netdev_budget* and see their effect
> separately.
>
> By the way, if netdev_budget* are useless, should they be deleted?

Well, we can't be sure if there's really nobody that uses them :(
It's very risky to remove stuff that's exposed to user space.

  reply	other threads:[~2022-12-06  2:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-03  8:12 [PATCH linux-next] net: record times of netdev_budget exhausted yang.yang29
2022-12-03 10:06 ` kernel test robot
2022-12-03 16:50 ` kernel test robot
2022-12-03 16:50 ` kernel test robot
2022-12-06  1:53 ` Jakub Kicinski
2022-12-06  2:35   ` yang.yang29
2022-12-06  2:47     ` Jakub Kicinski [this message]
2022-12-07  7:27       ` yang.yang29
2022-12-07  7:58         ` Eric Dumazet
2022-12-07  8:17           ` yang.yang29
2022-12-07 23:28             ` Jakub Kicinski
2022-12-07 12:30           ` yang.yang29
2022-12-07 23:32             ` Jakub Kicinski
2022-12-08  1:12               ` yang.yang29
2022-12-08  1:23                 ` Jakub Kicinski
2022-12-08  1:42                   ` yang.yang29

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=20221205184742.0952fc75@kernel.org \
    --to=kuba@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=imagedong@tencent.com \
    --cc=kuniyu@amazon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liu3101@purdue.edu \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.com \
    --cc=tedheadster@gmail.com \
    --cc=wujianguo@chinatelecom.cn \
    --cc=yang.yang29@zte.com.cn \
    /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.