netdev - Re: tcp bw in 2.6

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:	Tue, 2 Oct 2007 09:34:01 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Larry McVoy <lm@...mover.com>
cc:	Herbert Xu <herbert@...dor.apana.org.au>, davem@...emloft.net,
	wscott@...mover.com, netdev@...r.kernel.org
Subject: Re: tcp bw in 2.6

On Tue, 2 Oct 2007, Larry McVoy wrote:

> Interesting data point.  My test case is like this:
> 
> server
> 	bind
> 	listen
> 	while (newsock = accept...)
> 		transfer()
> 
> client
> 	connect
> 	transfer
> 
> If the server side is the source of the data, i.e, it's transfer is a 
> write loop, then I get the bad behaviour.  If I switch them so the data
> flows in the other direction, then it works, I go from about 14K pkt/sec
> to 43K pkt/sec.

Sounds like accept() possibly initializes slightly different socket 
parameters than connect() does. 

On the other hand, different network cards will simply have different 
behaviour (some due to hardware, some due to driver differences), so I 
hope you also switched the processes around and/or used identically 
configured machines (and the port configuration on switches could matter, 
of course, so it's really best to switch the processes around, to make 
sure that the *only* difference is whether the socket was set up by 
accept() vs connect()).

> So is this a bug or intentional?

Sounds like a bug to me, modulo the above caveat of making sure that it's 
not some hw/driver/switch kind of difference.

			Linus
-
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