At 06:49 PM 11/30/2006, Thor Lancelot Simon wrote:

>There are some severe problems with the test configuration.
>
>1) The published test results freely mix configurations where the switch
>    applies and removes the vlan tags with configurations where the host
>    does so.  This is not a good idea:

Hi,
The switch is always involved.  The ports are only in trunk mode for 
the trunking tests. Otherwise, its switchport access.  The same 
"limitations" apply to all tested configurations.  When I swapped in 
a faster CPU briefly, I was seeing rates of +1Mpps on RELENG_4 with 
no dropped packets with no firewall in the kernel.  Thats the same 
hardware, so I am not sure how its inadequate hardware on NetBSD 
tests all of a sudden.


>    1) The efficiency of the switch itself will differ in these configurations

Why ?  The only thing being changed from test to test is the OS.


>    2) The difference in frame size will actually measurably impact the PPS.

Framesize is always the same.  UDP packet with a 10byte payload. The 
generators are the same devices all the time. I am not using 
different frame sizes for different setups to try and make something 
look good and other things bad.



>    3) One of the device drivers you're testing doesn't do hardware VLAN
>       tag insertion/removal in NetBSD due to a bug (wm).  Obviously, this
>       one is our fault, not yours.

When I did the wm tests, this was just plugged into the switch with a 
port based VLAN (the cisco equiv of switchport access).  There was no 
trunking going on.


>2) The NetBSD kernels you're testing don't have options GATEWAY, so they
>    don't have the fastroute code.

Like I said to Hubert, I am not a NetBSD person and just did the 
default install. I am happy to re-test with a more appropriate kernel 
config.  FreeBSD and dfly both have fastforward (I am guessing like 
your fastroute) as a sysctl tuneable so I could add that to the kernel...



>3) There is a problem with autonegotiation either on your switch, on the
>    particular wm adapter you're using, or in NetBSD -- there's not quite
>    enough data to tell which.  But look at the number of input errors on
>    the wm adapter in your test with NetBSD-current: it's 3 million.  This
>    alone is probably responsible for most of the performance difference

.... Or the kernel just was not able forward fast enough.  FYI, The 
switch proper negotiated with all the other OSes tested nor were 
there errors on the switchport.

         ---Mike