netdev - Re: does intel X520-SR(ixgbe) support RSS on single VLAN?

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: <4D3DC0A3.8080503@hp.com>
Date:	Mon, 24 Jan 2011 10:10:43 -0800
From:	Rick Jones <rick.jones2@...com>
To:	Alexander Duyck <alexander.h.duyck@...el.com>
CC:	Rui <wirelesser@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>
Subject: Re: does intel X520-SR(ixgbe) support RSS on single VLAN?

Alexander Duyck wrote:
> I would recommend testing with something like the "netperf -t TCP_CRR" 
> test which should open a number of ports and spread traffic out between 
> multiple queues.

TCP_CRR - Connect Request Response - it will cycle through almost the entire 
port space as it goes, one at a time.  Any one four-tuple will be unlikely to 
have all that many packets - just the SYN exchange, the request/response 
exchange and then the FIN exchange, so unless there is a tool looking at the 
queues with microsecond granularity, it will appear like it is all happening at 
once :)

If you want to see one queue used for "a while" and then another, I would 
suggest a TCP_RR test with the confidence intervals set to say 30 iterations. 
That will exchange packets for the test duration (global -l option) and then the 
next iteration will have a four-tuple that differs in the client port number 
from the previous (the "server" port number remains fixed through the iterations 
of the TCP_RR test.

One can also run TCP_RR tests in turn, one after the other, but that consumes 
port numbers in twos on both sides.  I suppose that these days with port number 
randomization that's OK, but in "the old days" it tended to mean that the 
control and data ports marched in lock-step and one would always be even the 
other odd, which didn't always work that well with hashes...  The use of the 
confidence intervals with the TCP_RR test deals with that by having only the one 
netperf control connection and then successive data connections.

happy benchmarking,

rick jones

There is also always the full specification of the port numbers and IP's for the 
data connection, though it is a bit more cumbersome.
--
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