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]
Date: Wed, 7 Feb 2024 14:37:14 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, 
	dsahern@...nel.org, netdev@...r.kernel.org, 
	Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next 0/2] add more drop reasons in tcp receive path

On Wed, Feb 7, 2024 at 2:25 PM Jason Xing <kerneljasonxing@...il.com> wrote:
>

> Indeed.
>
> It took me some while to consider whether I should add more reasons
> into the fast path.
>
> But for now the NOT_SPECIFIED fake reason does not work if we really
> want to know some useful hints.
> What do you think? Should I give up this patch series or come up with
> other better ideas?

Perhaps find a way to reuse return values from functions to carry a drop_reason.

>
> >
> > Please make sure not to slow down the TCP fast path, while we work
> > hard in the opposite direction.
>
> I tested some times by using netperf, it's not that easy to observe
> the obvious differences before/after this patch applied.

Sure, the difference is only noticeable on moderate load, when a cpu
receives one packet in a while.

icache pressure, something hard to measure with synthetic benchmarks,
but visible in real workloads in the long term.

At Google, we definitely see an increase of network cpu costs releases
after releases.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ