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: <CAL+tcoC-e5Oj1mPyZiS6Q8BuZcuU2XH2Vu7VChC_fxp5JqW9wA@mail.gmail.com>
Date: Wed, 31 Jul 2024 19:53:17 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Breno Leitao <leitao@...ian.org>
Cc: Paolo Abeni <pabeni@...hat.com>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, leit@...a.com, 
	Chris Mason <clm@...com>, "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>, 
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next] net: skbuff: Skip early return in skb_unref when debugging

On Wed, Jul 31, 2024 at 7:25 PM Breno Leitao <leitao@...ian.org> wrote:
>
> Hello Paolo,
>
> On Tue, Jul 30, 2024 at 11:38:38AM +0200, Paolo Abeni wrote:
> > Could you please benchmark such scenario before and after this patch?
>
> I've tested it on a 18-core Xeon D-2191A host, and I haven't found any
> different in either TX/RX in TCP or UDP. At the same time, I must admit
> that I have very low confidence in my tests.
>
> I run the following tests for 10x on the same machine, just changing my
> patch, and I getting the simple average of these 10 iterations. This is
> what I am doing for TCP and UDP:
>
> TCP:
>         # iperf -s &
>         # iperf -u -c localhost
>
>         Output: 16.5 Gbits/sec
>
> UDP:
>         # iperf -s -u &
>         # iperf -u -c localhost
>
>         Output: 1.05 Mbits/sec
>
> I don't know how to explain why UDP numbers are so low. I am happy to
> run different tests, if you have any other recommendation.

I think the iperf tool uses '-b 1' as default, which is explained in
the man page:
CLIENT SPECIFIC OPTIONS
       -b, --bandwidth n[kmgKMG][,n[kmgKMG]] | n[kmgKMG]pps
              set  target  bandwidth  to  n  bits/sec  (default  1
Mbit/sec)  or  n  packets per sec. This may be used with TCP or UDP.
Optionally, for variable loads, use format of
              mean,standard deviation

So, if you try the parameter like '-b 40MB', it will reach around
40MB/sec speed.

If I were you, I could try the following way:
1) iperf3 -s
2) iperf3 -u -c 127.0.0.1 -b 0 -l 64

Hope it can help you:)

Thanks,
Jason

>
> --breno
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ