On Tue, 19 Sep 2000, jamal wrote:
> On Tue, 19 Sep 2000, Donald Becker wrote:
>
> > This is one of the reasons for drivers to keep their Tx queues to a
> > reasonable length. Two years ago an almost-always-sufficient Tx queue
..
> The Tulip, for example, can have its DMA buffers stashed in a linked list
> instead of a ring structure.
Not if you want to work with different Tulip chip types!
The driver sets up the descriptors as both a ring and a linked list. That
way it works both with chips that only implement chained mode, and chips
that only work properly in ring mode.
This is documented in a driver note. *Believe* that note.
That detail was learned from time consuming experience.
> Maybe not the most efficient scheme but could you could play with
> priority queueing structures/algorithms for the DMA buffers in this
> case and for example stick a higher priority packet to the head of the
> queue? I have not implemented any such thing, just thinking out
> loudly.
This isn't a good idea.
There is no safe way to reorder the list after the descriptors have been
passed to the driver (e.g. ownership flag is set). The 3Com chips are
unique -- they do provide safe semantics to do this with the real-time
schedule. But it's ugly and inefficient, and certainly doesn't apply to
other chip types.
Keep in mind that reordering the Tx descriptor queue is only getting to part
of the Tx queue. You might have a bunch of packets hanging out in the
hardware Tx FIFO (2KB to 8KB long), and there is no way that you can get to
the front of *that* queue on most chips.
There are a few recent chips that implement an explicit high priority queue.
The Starfire has a nice implementation, and has a i82559 adds a second, limited
functionality, high priority command queue. (The commands for this are
revealed in the overview datasheet that is available from Intel's public web
site.)
(Hmmm, this triggers a memory: I propagated the priority in the old 100VG
driver that I wrote. Now *that* is a driver that had a big world impact ;-)
Anyway, the big picture is that you are likely thinking about a non-problem.
Getting to the front of the 100 packet long software queue is important.
You should be *really* certain, by simulation and modeling not just
intuition, that your application needs to bypass the driver/hardware queue.
Donald Becker becker@xxxxxxxxx
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Beowulf-II Cluster Distribution
Annapolis MD 21403
|