On Sat, 26 Jun 1999 [EMAIL PROTECTED] wrote:
> To: Zonghua Gu <[EMAIL PROTECTED]>
> >
> > 2. When an incoming packet generates an interrupt and qdisc_run_queues is
> > called from net_bh, therefore emptying the outgoing queue.
>
> Yes. Plus grep for mark_bh(NET_BH) in device drivers, it will reduce
> your doubts.
>
> However, you are right partially. It is known "feature" that
> the most of drivers do not tell anyone when completing sending a frame.
> It is bug, however the experience of with the past linux kernels showed
> that it does not affect real behaviour, but its naive fixing in core results
> in lots of additional work, not required in real life cases.
I'm uncertain what you mean by "bug".
The kernel isn't notified of each completed transmission, unless the card
only buffers a single packet.
Normally a driver sets dev->tbusy while it's queuing a packet for
transmission, and clears dev->tbusy just before the function returns.
Thus the driver is often ready to just accept another packet.
If the driver's internal Tx queue (distinct from the software queue layer)
is full it sets an internal flag, typically named lp->tx_full, and leaves
dev->tbusy set.
The kernel is notified by mark_bh(NET_BH) only when the driver's Tx queue
was previously full but once again has room.
Tidbits:
They typical size of a descriptor-based driver's internal queue is 16
packets. It's usually easy to make it larger, but that would defeat packet
prioritization that occurs at the software queue layer.
The old 8390 design has an internal queue of two packets, ping-pong style.
The 3c509 driver uses the hardware FIFO as the only internal queue,
typically 2KB to 5KB of packet data.
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]