Received: by oss.sgi.com id ; Tue, 19 Sep 2000 20:26:46 -0700 Received: from battlejitney.wdhq.scyld.com ([216.254.93.178]:24570 "EHLO vaio.greennet") by oss.sgi.com with ESMTP id ; Tue, 19 Sep 2000 20:26:30 -0700 Received: from localhost (becker@localhost) by vaio.greennet (8.9.3/8.8.7) with ESMTP id XAA13445; Tue, 19 Sep 2000 23:27:45 -0400 Date: Tue, 19 Sep 2000 23:27:45 -0400 (EDT) From: Donald Becker X-Sender: becker@vaio.greennet To: jamal cc: Andi Kleen , =?iso-8859-1?Q?Ram=F3n_Ag=FCero?= , netdev@oss.sgi.com Subject: Re: Giving priority to messages In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netdev@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;netdev-outgoing 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@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Beowulf-II Cluster Distribution Annapolis MD 21403