On Fri, Dec 01, 2006 at 12:06:17AM +0100, Hubert Feyrer wrote:
> 
> [adding tech-net@ as I don't really know what to answer...
> 
>  Context: adding NetBSD in the benchmark at
>  http://www.tancsa.com/blast.html, with the wm(4) driver in
>  -current, as it's not available in 3.1]
> 
> 
> On Thu, 30 Nov 2006, Mike Tancsa wrote:
> >Gave it a try and I posted the results on the web page.  The Intel driver 
> >doesnt seem to work too well.  Is there debugging in this kernel ?
> 
> That sounds indeed not so bright. I do not know about the wm(4) driver, 
> but maybe someone on tech-net@ (CC:d) has an idea. IIRC that's with a 
> -current (HEAD) GENERIC kernel and the wm(4) driver, while bge(4) driver 
> works ok.

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:

   1) The efficiency of the switch itself will differ in these configurations
   2) The difference in frame size will actually measurably impact the PPS.
   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.

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

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
   between the wm and bge test cases with NetBSD kernels (and the hardware
   vlan support in the bge driver may be responsible for the rest).

4) You don't appear to be using hardware IP checksum offload.  You're going
   to have trouble turning this on with a mismatched kernel and ifconfig
   executable, however. :-/

With these fixed, we can probably help diagnose any remaining issues
pretty quickly.

Thor