netdev - Re: [net-next v5 4/9] netdev-genl: Dump gro_flush

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZwdZQa3nujo7TZ1c@LQ3V64L9R2>
Date: Wed, 9 Oct 2024 21:34:09 -0700
From: Joe Damato <jdamato@...tly.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, mkarsten@...terloo.ca, skhawaja@...gle.com,
	sdf@...ichev.me, bjorn@...osinc.com, amritha.nambiar@...el.com,
	sridhar.samudrala@...el.com, willemdebruijn.kernel@...il.com,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Donald Hunter <donald.hunter@...il.com>,
	Jesper Dangaard Brouer <hawk@...nel.org>,
	Mina Almasry <almasrymina@...gle.com>,
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [net-next v5 4/9] netdev-genl: Dump gro_flush_timeout

On Wed, Oct 09, 2024 at 08:14:40PM -0700, Jakub Kicinski wrote:
> On Wed,  9 Oct 2024 00:54:58 +0000 Joe Damato wrote:
> > +        name: gro-flush-timeout
> > +        doc: The timeout, in nanoseconds, of when to trigger the NAPI
> > +             watchdog timer and schedule NAPI processing.
> 
> You gotta respin because we reformatted the cacheline info.

Yea, I figured I'd be racing with that change and would need a
respin.

I'm not sure how the queue works exactly, but it looks like I might
also be racing with another change [1], I think.

I think I'm just over 24hr and could respin and resend now, but
should I wait longer in case [1] is merged before you see my
respin?

Just trying to figure out how to get the fewest number of respins
possible ;)

> So while at it perhaps throw in a sentence here about the GRO effects?
> The initial use of GRO flush timeout was to hold incomplete GRO
> super-frames in the GRO engine across NAPI cycles.

>From my reading of the code, if the timeout is non-zero, then
napi_gro_flush will flush only "old" super-frames in
napi_complete_done.

If that's accurate (and maybe I missed something?), then how about:

doc: The timeout, in nanoseconds, of when to trigger the NAPI
     watchdog timer which schedules NAPI processing. Additionally, a
     non-zero value will also prevent GRO from flushing recent
     super-frames at the end of a NAPI cycle. This may add receive
     latency in exchange for reducing the number of frames processed
     by the network stack.

LMK if that's accurate and sounds OK or if it's wrong / too verbose?

[1]: https://lore.kernel.org/netdev/20241009232728.107604-1-edumazet@google.com/T/#m3f11aae53b3244037ac641ef36985c5e85e2ed5e