Subject: Re: NetBSD in BSD Router / Firewall Testing
To: firstname.lastname@example.org, Hubert Feyrer <email@example.com>
From: Mike Tancsa <firstname.lastname@example.org>
Date: 11/30/2006 19:41:45
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:
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.