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 <[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
