Advice on a multithreaded netisr patch?

Sepherosa Ziehau sepherosa at gmail.com
Tue Apr 7 06:57:48 PDT 2009


On Tue, Apr 7, 2009 at 8:54 PM, Robert Watson <rwatson at freebsd.org> wrote:
>
> On Tue, 7 Apr 2009, Sepherosa Ziehau wrote:
>
>> On Sun, Apr 5, 2009 at 9:34 PM, Ivan Voras <ivoras at freebsd.org> wrote:
>>>
>>> Robert Watson wrote:
>>>>
>>>> On Sun, 5 Apr 2009, Ivan Voras wrote:
>>>>
>>>>> I thought this has something to deal with NIC moderation (em) but
>>>>> can't really explain it. The bad performance part (not the jump) is
>>>>> also visible over the loopback interface.
>>>>
>>>> FYI, if you want high performance, you really want a card supporting
>>>> multiple input queues -- igb, cxgb, mxge, etc.  if_em-only cards are
>>
>> PCI-E em(4) supports 2 RX queues.  82571/82572 support 2 TX queues. I have
>> not tested multi-TX queues, but em(4) multi-RX queues work well in dfly
>> (tested with 82573 and 82571)
>
> You may not have seen, but in FreeBSD 7.x and higher, we have a new if_igb
> driver to support more recent Intel gigabit devices, which now probes a few
> of the devices historically associated with if_em.  For example, on one of
> the boxes I use:

If I understand the code correctly, it only takes 82575 and 82576; I
don't have the hardware, else I would have already added dfly support
(with multi rx queues at least, it seems 82576 supports 16 RX queues
:)

8257{1/2/3} are still taken by em(4) in FreeBSD.  In dfly, I simply
forked em(4) (named emx) to create a special version for pci-e
devices, for which Intel published developers' manual.  I added
multi-rxqueue support to it (multi-txqueue support is planned) and
cleaned up the TX/RX path.  IMHO, 82571 is too widely used to be
ignored.

Best Regards,
sephe

-- 
Live Free or Die


More information about the freebsd-net mailing list