Hello!
> > Excellent. If you agreed, remove useless and dangerous fiddling
> > with dev->tbusy, please.
>
> You need a way for the queues to know if the driver is busy. That means you
> still need tbusy.
No-no-no! I did not mean killing tbusy at all. It is critical flag yet.
The problem with current drivers is that they play with tbusy very
dirty games, setting it without any reasons and not marking BH when
resetting it back. This is not a bug in 2.0&2.2, because all the sender
side is locked by one veeery big lock, so that hard_start_xmit never runs
concurrently with checking tbusy. In 2.3 it will be problem, because
we have to enforce driver spinlock BEFORE even checking for tbusy.
It is just silly. Simple heuristic, that if tbusy!=0 then we can defer
any operation to later because driver will wake up us works only
if driver really wakes up. That's all. It means only that driver should
not test_and_set tbusy on entry to hard_start_xmit, and should not
ever reset it silently.
> > > "I suddenly decided I'm busy, try again later"
> > OK. Only one clarification is necessary, notion "later" does not exist
> > in kernel. There exist "now + a finite number of jiffies"
>
> Not true for networking. You forget that "I've finished sending" is a very
> normal interrupt from a network card, therefore you clearly can have
> now+otherthings.
It is the thing which drivers do not now. And they are right here
in some extent.
Absense of such notification really reduces the work, when external queues
are work-conserving i.e. produce any output always when queue is not empty,
so that internal driver queues are refilled by big batches and if driver
finished transmission in the conditions, when it was not throttled before,
it need not waste cycles to send wakeups.
Adding optional wakeup callback could be useful, but we cannot
get any immediate advantages from it.
> The problem there is timer management for timeouts and queueing got tangled
> up and they need splitting. Donald has done this for a pile of drivers
> ready.
No problems. We add new function to struct device, not disabling
old method and the transition starts.
> > The second, you added tp->interrupt lock recently, though
> > you were said unambiguosly that it is useless, does not solve
> > any real problem and you have no valid reasons to add it.
>
> It deals with specific problems in some 2.0.x series kernels when running
> SMP.
Even more, the last known hole has been patched in 2.2 by Andrea Arcangeli
very recently. But every such bug does not require to be fixed in each driver.
And dev->interrupt was more than enough for 2.0, by the way.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
