netdev - Re: A question about MTUs and TCP stack

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1313957105.2598.10.camel@edumazet-laptop>
Date:	Sun, 21 Aug 2011 22:05:05 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Pawan Singh <psingh@...ver-peak.com>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: A question about MTUs and TCP stack

Le mardi 16 août 2011 à 11:33 -0700, Pawan Singh a écrit :
> Hi
> 
> I am posting this question to "netdev" mailing list because I could no
> longer find "linux-net" mailing list.
> 
> I find that the Linux TCP stack consumes huge amount of CPU if the MTU
> of an interface is set to 2400 and it is receiving 1000 byte Ethernet
> packets. On the other hand, if the MTU is set to 1500, the CPU
> consumption is reduced drastically. Increased CPU usage causes network
> throughput to drop considerably (from 800-900 Mbps to 200 Mbps). My
> kernel version is fedora core 6 and we are using 1 Gig NICs (Intel
> 82546GB and Broadcom NetXtreme BCM5721):
> 
> Linux he7700-tg 2.6.22.14-72.fc6 #1 SMP Wed Nov 21 14:10:25 EST 2007
> x86_64 x86_64 x86_64 GNU/Linux
> 
> I do not know the TCP buffer management internals and how they are
> affected by MTU. Is there some FAQ/information online or do I have to
> open up the source code and try to identify the source of the problem.
> I guess I can also try newer versions of the kernel and see if the
> issue has been resolved.
> 

I suspect you have a CPU problem on the receiver side, not on transmit
one ?

MTU has a direct impact on skb 'truesize'. As the linux tcp stack takes
care of not using too much kernel ram for the sole use of one socket,
you might hit a per socket limit faster with big MTU (and not filled RX
buffers)

When this limit is hit, tcp stack tries to 'collapse' consecutive skbs
to remove the unused parts of skbs. This is a very expensive process.

With a recent kernel, you could use 'perf top' tool and easily spot the
hot paths in kernel.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html