em driver regression

[Jack Vogel]

Ah, ok, let me play around with it a bit, perhaps I'll make it definable,
of course if there is no positive benefit from using it it would seem silly
to leave it around :)

Will look at your patch changes and that issue tomorrow. Thanks
for your efforts!

Jack


On Thu, Apr 8, 2010 at 4:07 PM, Pyun YongHyeon <pyunyh at gmail.com> 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.
>
> > Jack
> >
> >
> > On Thu, Apr 8, 2010 at 2:05 PM, Mike Tancsa <mike at sentex.net> wrote:
> >
> > > At 04:56 PM 4/8/2010, Pyun YongHyeon wrote:
> > >
> > >> On Thu, Apr 08, 2010 at 02:31:18PM -0400, Mike Tancsa wrote:
> > >> > At 02:17 PM 4/8/2010, Pyun YongHyeon wrote:
> > >> >
> > >> > >Try this patch. It should fix the issue. It seems Jack forgot to
> > >> > >strip CRC bytes as old em(4) didn't strip it, probably to
> > >> > >workaround silicon bug of old em(4) controllers.
> > >> >
> > >> > Thanks! The attached patch does indeed fix the dhclient issue.
> > >> >
> > >> >
> > >> > >It seems there are also TX issues here. The system load is too high
> > >> > >and sometimes system is not responsive while TX is in progress.
> > >> > >Because I initiated TCP bulk transfers, TSO should reduce CPU load
> > >> > >a lot but it didn't so I guess it could also be related watchdog
> > >> > >timeouts you've seen. I'll see what can be done.
> > >> >
> > >> > Thanks for looking into that as well!!
> > >> >
> > >> >         ---Mike
> > >> >
> > >>
> > >> Mike,
> > >>
> > >> Here is patch I'm working on. This patch fixes high system load and
> > >> system is very responsive as before. But it seems there is still
> > >> some TX issue here. Bulk UDP performance is very poor(< 700Mbps)
> > >> and I have no idea what caused this at this moment.
> > >>
> > >> BTW, I have trouble to reproduce watchdog timeouts. I'm not sure
> > >> whether latest fix from Jack cured it. By chance does your
> > >> controller support multi TX/RX queues? You can check whether em(4)
> > >> uses multi-queues with "vmstat -i". If em(4) use multi-queue you
> > >> may have multiple irq output for em0.
> > >>
> > >
> > > Hi,
> > >        I will give it a try later tonight!  This one does not seem to.
> > >
> > > 0(ich10)# vmstat -i
> > > interrupt                          total       rate
> > > irq16: uhci0+                         30          0
> > > irq18: ehci0 uhci5                158419         17
> > > irq19: fwohci0++                      86          0
> > > irq21: uhci1                          17          0
> > > irq23: uhci3 ehci1                     2          0
> > > cpu0: timer                     18570305       1994
> > > irq256: igb0                          80          0
> > > irq257: igb0                         255          0
> > > irq258: igb0                          66          0
> > > irq259: igb0                          32          0
> > > irq260: igb0                           2          0
> > > irq261: igb1                        2679          0
> > > irq262: igb1                         998          0
> > > irq263: igb1                        2468          0
> > > irq264: igb1                        6361          0
> > > irq265: igb1                           2          0
> > > irq266: em0                        33910          3
> > > irq267: ahci1                      15317          1
> > > cpu1: timer                     18557074       1993
> > > cpu3: timer                     18557168       1993
> > > cpu2: timer                     18557108       1993
> > > Total                           74462379       7998
> > > 0(ich10)#
> > >
>