NETIF_F_LLTX

One of the key network driver methods is called hard_start_xmit(); its job is to put a network packet onto the wire (or, at least, queue it for transmission). The networking subsystem protects calls to this method with a lock (xmit_lock) in the net_device structure so that only one call will be happening at any given time. This lock also protects a few configuration operations.

As it turns out, quite a few network drivers implement their own locking internally as well. There are contexts (such as in interrupt handlers) where the xmit_lock will not be held, so some other provision must be made for mutual exclusion. So the hard_start_xmit() method, in those drivers, is called with a redundant lock held. It all works, but it adds overhead to a performance-critical path.

Andi Kleen has put together a patch which addresses this duplicate locking. With this patch (which appears likely to be merged), drivers which do their own transmit locking can set the NETIF_F_LLTX "feature" flag. When a packet is to be handed to an interface with that flag set, no additional locking is performed by the networking code. As an added feature, the driver can attempt to take its internal lock with spin_trylock(), and immediately return -1 if that attempt fails; the networking subsystem will then retry the transmission later. In this way, the driver can avoid stalling the CPU while waiting for the lock; there should be, after all, no slowdown if the packet is added to the transmission ring a little bit later.

Index entries for this article
Kernel	NETIF_F_LLTX
Kernel	Networking/hard_start_xmit() locking

---

to post comments

NETIF_F_LLTX

Posted Sep 9, 2004 20:14 UTC (Thu) by giraffedata (guest, #1954) [Link]

That sounds exactly like what Linus and others in charge have resoundingly rejected over the years - interfaces where the callee indicates whether he needs the caller to guarantee serialization or not. Many such changes were proposed in the early days of the Big Kernel Lock as a way to let some modules escape the performance tyranny of the BKL while letting others escape the programming hassle of designing for parallel operation. None were ever accepted.

It seems to me that, consistent with that philosophy, instead of adding NETIF_F_LLTX, all the drivers would be changed simultaneously to do their own transmit locking (and, as usual, to hell with the drivers that aren't available for modification to the person making that change).

Or is this something different?