What bothers me is more the complexity this has introduced more than the workload. OTOH, 1-2% improvement posted by Roland is good justification. cheers, jamal
thing like this might look like. In summary: 1) dev->xmit_lock is now IRQ disabling instead of BH disabling 2) Drivers can use dev->xmit_lock in place of their private driver_pri
by copying them before writing and dequeue unwriteable skbs unchanged. Assumes that IP/IPv6 header is always linear so no pulling required. Signed-off-by: Tho
just documenting that Roland> device drivers can use the xmit_lock member of struct Roland> net_device to synchronize other parts of the driver Roland> against
What bothers me is more the complexity this has introduced more than the workload. OTOH, 1-2% improvement posted by Roland is good justification. cheers, jamal
I think I'm going to put in something like Eric's patch and fix up the other LLTX drivers as per his sungem patch. There is a part of me that does want to yank LLTX for non-loopback out of the tree.
Wondering, why not just have the drivers have a way to lock dev->queue_lock in the interrupt handler, and change the xmit to do spin_lock_irqsave? Any driver that assumes it is being called with irq'
Yes, that's an idea. Effectively, LLTX is working around the fact that dev->xmit_lock is BH disabling instead of IRQ disabling. And there is no fundamental reason for that. Usually we strive for BH d
David S. Miller wrote: Usually we strive for BH disabling locks in order to decrease the amount of hard IRQ disabling time in the kernel. But here, as soon as we call into ->hard_start_xmit(), the dr
But in the end it would be safer than the current LLTX usage in drivers which seems like it opening up problems. -- Stephen Hemminger <shemminger@xxxxxxxx>