OpenBSD Journal

Heads up! vr(4) gets a major overhaul

Contributed by johan on from the vr-vrrr-vroooom dept.

Thordur I. Björnsson has committed a major update to the vr(4) driver. This triggered Reyk Floeter (reyk@) to emphasize on the importance of this update.

Please read on for Reyk's comment...

Subject:    Re: CVS: cvs.openbsd.org: src
From:       Reyk Floeter 
Date:       2008-07-19 12:36:16

On Fri, Jul 18, 2008 at 07:38:40AM -0600, Thordur I. Bjornsson wrote:
> CVSROOT:	/cvs
> Module name:	src
> Changes by:	thib@cvs.openbsd.org	2008/07/18 07:38:40
> 
> Modified files:
> 	sys/dev/pci    : if_vr.c if_vrreg.h 
> 
> Log message:
> o Use mbufs, for the RX ring, instead of malloc()'ing an MCLBYTES sized buffer.
> o On non-strict alignment archs, dont copy the mbuf, every time, unload it, and
 send
> it up the stack and just get a new one for the rx ring. We still do the copy on
> strict alignment archs though...
> o create a function to handle mbuf allocation for the rx ring, vr_mbuf_alloc(),
> use it to allocate the mbufs and shuffle the bus dma setup around.
> 
> ideas/code from vic(4) and sis(4);
> 
> ok reyk@, brad@, dlg@
> tested by many, been in snapshots for a while.
> 

Yay!

Heads up, this is an important diff for people using vr(4) and systems
like the new-age Soekrises (eg. net5501).  The driver was not working
under high load without this diff because it was, erm, totally wrong.
Testing the updated driver shows that it is much better now, even
under load with many small packets.

Thanks thib!

(Comments are closed)


Comments
  1. By Kevin (207.229.181.246) on

    We have many Net5501's going into production this month, running 4.3

    I'm tempted to give them a new kernel incorporating these changes before I start shipping them out to the ends of the earth...

    Comments
    1. By Henrik Kramshoej (80.160.242.134) hlk@kramse.dk on www.kramse.dk

      > We have many Net5501's going into production this month, running 4.3
      >
      > I'm tempted to give them a new kernel incorporating these changes before I start shipping them out to the ends of the earth...

      Hmmm, using this kernel:
      OpenBSD 4.4-beta (GENERIC) #979: Wed Jul 16 09:40:32 MDT 2008
      todd@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
      cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 500 MHz
      cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX
      real mem = 536440832 (511MB)
      avail mem = 510500864 (486MB)

      and a Thinkpad X31 with em0 driver and straight cable to Soekris 5501
      shows:

      hlk@bianca:hlk$ iperf -s
      ------------------------------------------------------------
      Server listening on TCP port 5001
      TCP window size: 128 KByte (default)
      ------------------------------------------------------------
      [ 6] local 10.0.47.1 port 5001 connected with 10.0.47.33 port 13101
      [ 6] 0.0-10.0 sec 57.8 MBytes 48.4 Mbits/sec

      way lower than I have previusly had with OpenBSD - seem to remember some ~90Mbits/sec - which was confirmed using a CF card from a friend with FreeBSD giving 94Mbits/sec on the same rig.

      Comments
      1. By Henrik Kramshoej (80.160.242.134) on

        grmpf, getting strangeness with this.

        The same Soekris that couldn't "handle" more than 50 Mbits/sec with "iperf -s" can act as a router to the next hop, which is another 5501.

        Using that I get about 85Mbits/sec throughput from the 5501 acting as router

        [ 4] local 10.0.46.1 port 5001 connected with 10.0.47.33 port 27167
        [ 4] 0.0-10.0 sec 101 MBytes 84.8 Mbits/sec

        from
        thinkpad running iperf -c --- 1st 5501 -- 2nd 5501 runing iperf -s

        ohh well, I will try some other tools tomorrow instead.

  2. By Anonymous Coward (81.83.46.216) on

    I also have a Soekris 5501. Time to move it to -current ... Thanks a lot guys, I'm curious to experience the changes.

  3. By Anonymous Coward (82.161.172.147) on

    Very cool! I have a couple of vr equipped machines at home running obsd, whoo! Any other neat things on the todo for this driver?

  4. By Venture37 (venture37) venture37<A>hotmail.com on www.geeklan.co.uk

    sweet, my alix2c3 has these aswell

  5. By corey (208.191.177.19) on

    Does this diff also fix the issue where the interface would stop communicating under some circumstances?

    http://marc.info/?t=120397961200001&r=1&w=2

    It was pointed out that this was possibly a PHY problem, so maybe not.

    Comments
    1. By Brad (2001:470:8802:3:216:41ff:fe17:6933) brad at comstyle dot com on

      > Does this diff also fix the issue where the interface would stop communicating under some circumstances?

      No.

      > It was pointed out that this was possibly a PHY problem, so maybe not.

      It is not a PHY issue.

      Comments
      1. By Anonymous Coward (96.21.15.58) on

        > > Does this diff also fix the issue where the interface would stop communicating under some circumstances?
        >
        > No.
        >
        > > It was pointed out that this was possibly a PHY problem, so maybe not.
        >
        > It is not a PHY issue.

        Is there a work around this known problem?

        Comments
        1. By sthen (2a01:348:108:100:20a:5eff:fe1a:a300) on

          > > > Does this diff also fix the issue where the interface would stop communicating under some circumstances?
          > >
          > > No.
          > >
          > > > It was pointed out that this was possibly a PHY problem, so maybe not.
          > >
          > > It is not a PHY issue.
          >
          > Is there a work around this known problem?

          It never seems to happen if the first thing it's plugged into is an X40/X32, and probably some others using em(4). It's reasonably unlikely to happen if it's plugged into a switch and left there. It's very likely to happen if it's plugged into some random PC which gets rebooted a lot so you probably want to try and avoid doing that for now.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]