On Sat, 26 Jun 1999 [EMAIL PROTECTED] wrote:
> > I'm uncertain what you mean by "bug".
> By word "bug" I mean bug. 8)
>
> Do not bother too much, it was not kick to your side this time.
The messages was mostly for the list, not you personally. (But sometime you
don't seem to understand the rationale behind the code.)
> It is bug in design and it did not bother anyone too much,
> because it is never triggered in normal curcumstances.
...
> > Normally a driver sets dev->tbusy while it's queuing a packet for
> > transmission, and clears dev->tbusy just before the function returns.
>
> BTW I try to deliver the thought to you from time to time, that driver
> should not set tbusy on entry to transmission routine. Nobody ever need it.
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.
The queue layer has changed behavior several times over the years.
Yes, ideally the driver should never need to deal with *any* locking. It
should return either
"happy,happy",
"that packet filled me up, don't send me more", or
"I suddenly decided I'm busy, try again later"
Another place current drivers have a superfically pointless lock is the
interrupt handler. This one is due to a bug in the SMP interrupt dispatch
which would simultaneously enter the handler code.
Remember that both changing driver interfaces and introducing bugs like this
one is *very* expensive. It's not just making the change in a few drivers.
It results in eventually modifying about 50 drivers, and then testing
potentially hundreds of boards. The driver interface should only be changed
for very good reason.
> > The kernel is notified by mark_bh(NET_BH) only when the driver's Tx queue
> > was previously full but once again has room.
>
> Exactly. It means that correct kernel would never stop feeding packets
> until driver is not tbusy or queue is not empty. In some curcumstances
> it does stop and it is bug, which I talk about. In 2.0 and 2.2 without
> shaping packet cannot fall to software queue, if driver is not throttled.
> But in 2.3 it becomes more serious problem.
I'm not certain what you are saying here.
Donald Becker [EMAIL PROTECTED]
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
