Thread (60 messages) 60 messages, 11 authors, 2008-08-01

Re: Kernel WARNING: at net/core/dev.c:1330 __netif_schedule+0x2c/0x98()

From: David Miller <davem@davemloft.net>
Date: 2008-07-24 09:20:52
Also in: lkml, netdev

Possibly related (same subject, not in this thread)

From: Peter Zijlstra <peterz@infradead.org>
Date: Thu, 24 Jul 2008 11:10:48 +0200
Ok, then how about something like this, the idea is to wrap the per tx
lock with a read lock of the device and let the netif_tx_lock() be the
write side, therefore excluding all device locks, but not incure the
cacheline bouncing on the read side by using per-cpu counters like rcu
does.

This of course requires that netif_tx_lock() is rare, otherwise stuff
will go bounce anyway...

Probably missed a few details,.. but I think the below ought to show the
idea...
Thanks for the effort, but I don't think we can seriously consider
this.

This lock is taken for every packet transmitted by the system, adding
another memory reference (the RCU deref) and a counter bump is just
not something we can just add to placate lockdep.  We going through
all of this effort to seperate the TX locking into individual
queues, it would be silly to go back and make it more expensive.

I have other ideas which I've expanded upon in other emails.  They
involve creating a netif_tx_freeze() interface and getting the drivers
to start using it.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help