em driver regression

Jack Vogel jfvogel at gmail.com
Fri Apr 9 16:45:06 UTC 2010


On Fri, Apr 9, 2010 at 9:41 AM, Pyun YongHyeon <pyunyh at gmail.com> wrote:

> On Fri, Apr 09, 2010 at 09:17:07AM -0400, Mike Tancsa wrote:
> > At 07:07 PM 4/8/2010, Pyun YongHyeon wrote:
> > >On Thu, Apr 08, 2010 at 02:06:09PM -0700, Jack Vogel wrote:
> > >> Only one device support by em does multiqueue right now, and that is
> > >> Hartwell, 82574.
> > >>
> > >
> > >Thanks for the info.
> > >
> > >Mike, here is updated patch. Now UDP bulk TX transfer performance
> > >recovered a lot(about 890Mbps) but it still shows bad numbers
> > >compared to other controllers. For example, bce(4) shows about
> > >958Mbps for the same load.
> > >During the testing I found a strong indication of packet reordering
> > >issue of drbr interface. If I forcibly change to use single TX
> > >queue, em(4) got 950Mbps as it used to be.
> > >
> > >Jack, as we talked about possible drbr issue with igb(4), UDP
> > >transfer seems to suffer from packet reordering issue here. Can we
> > >make em(4)/igb(4) use single TX queue until we solve drbr interface
> > >issue? Given that only one em(4) controller supports multiqueue,
> > >dropping multiqueue support for em(4) does not look bad to me.
> >
> > No watchdog errors over night. I wonder if the issue was due to
> > 100Mb, or the patch from current fixed it.  I will try today with the
> > new patch below! I am guessing the rejection was due to the RX/TX fix ?
> >
>
> The patch was generated against latest HEAD. This includes Jack's
> latest fix too so it may not be applied cleanly on stable/8.
> I think you can use em(4) in HEAD.
>

Yes, you can.  And I think its the code change not the
speed Mike.

Jack


More information about the freebsd-stable mailing list