> > That isn't/wasn't true: the protocol levels would attempt to send a timer
> > based retransmission while the driver was queuing a packet. Without the
> > tbusy lock the transmit routine would be simultaneously entered.
>
> Protocol layer never tried/tries/will try to reenter to hard_start_xmit.
> Listen, NEVER!
Correct. Its protected by the atomicity check since about 1.2 - maybe 1.0
in fact.
> > "happy,happy",
> > "that packet filled me up, don't send me more", or
>
> 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.
> > "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.
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.
> 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.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
