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.

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit 
http://communities.intel.com/community/wired

Reply via email to