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