On 21.11.2012 08:55, Adrian Chadd wrote:
Something that has popped up a few times, even recently, is breaking out of an RX loop after you service a number of frames.
That is what I basically described.
During stupidly high levels of RX, you may find the NIC happily receiving frames faster than you can service the RX queue. If this occurs, you could end up just plain being stuck there.
That's the live-lock.
So what I've done in the past is to loop over a certain number of frames, then schedule a taskqueue to service whatever's left over.
Taskqueue's shouldn't be used anymore. We've got ithreads now. Contrary to popular belief (and due to poor documentation) an ithread does not run at interrupt level. Only the fast interrupt handler does that. The ithread is a normal kernel thread tied to an fast interrupt handler and trailing it whenever it said INTR_SCHEDULE_ITHREAD.
I've also had to do some proactive frame dropping at the driver layer when under ridiculous levels of RX load, but that's a different story.
That's the CoDel stuff I mentioned where it tries to drop frames in a fair manner.
I wonder how many drivers break out of an RX loop after a fixed amount of time..
Most. The problem seems to be that the taskqueue runs at high priority effectively starving out other threads/processes again. -- Andre _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
