Freebsd IP Forwarding performance (question,
and some info) [7-stable, current, em, smp]
Paul
paul at gtcomm.net
Tue Jul 1 03:10:25 UTC 2008
I have been unable to even come close to livelocking the machine with
the em driver interrupt moderation.
So that to me throws polling out the window. I tried 8000hz with
polling modified to allow 10000 burst and it makes no difference
in the amount of pps I can jam through.. It' seems to be limited by the
routing path in the kernel more than anything else.
If a driver/hardware didn't support interrupt mitigation then it would
definitely lock the machine.
Sepherosa Ziehau wrote:
> On 7/1/08, Paul <paul at gtcomm.net> wrote:
>
>> All the NIC drivers in 7 pretty much use interrupt moderation so it can
>>
>
> I am not quite sure whether em(4)'s RX interrupt moderation works as
> expected or not. But, AFAIK, nfe(4) and re(4) does not have RX
> interrupt moderation. Their TX interrupt moderation could be mimiced
> by using their hardware timer and disabling their TX interrupt.
>
> The lacking of RX im is difficult to handle, I could imagine following way:
> - During init, enable RX intr
> - When RX intr comes, disable RX intr and set up hardware timer intr
> - When timer intr comes and no RX happens, disable timer intr and enable RX intr
>
> Properly configured #RX desc and timer intr interval will be required
> to make sure that the RX desc collection could keep up with the
> hardware speed. I used pure timer intr (8000Hz) on nfe(4) in dfly w/
> good result, i.e. TX/RX @linespeed without livelocking the system.
> The drawback of pure timer intr is that you waste extra cpu power,
> when there is nothing to process.
>
>
>> never lock the machine anyway.. This effectively kills polling and it really
>> no longer has any use except to be able to have a fraction of the cpu set
>>
>
> Oh? Really? :]
>
> Best Regards,
> sephe
>
>
More information about the freebsd-net
mailing list