ipprecedence

[Luigi Rizzo]

sorry for the late reply...

[thread about prioritizing packet at the bottleneck interface]

On Thu, Jul 03, 2003 at 09:27:22AM +0800, Eugene Grosbein wrote:
...
> In addition to dummynet WFQ queue there is interface FIFO queue.

unfortunately, there are actually two queues -- one is
struct ifnet:struct ifqueue if_snd, which is always present;
the other one is the 'transmit ring' (or various other names)
which is sometimes just one or two slots, and sometimes a
long list of buffers that the hardware drains as conditions
permit. Certain hardware even has multiple, prioritized
transmit rings, but there is no support for them in our
drivers (basically we don't have an API for that).

Typically (but this is device dependent) the output routines
punch through if_snd and enqueue directly into the transmit
ring, and when that fills up the driver switches mode of
operation and queues into if_snd, until the hardware signals
that the transmit ring has room available, drains if_snd and
the driver returns to the previous mode.

Now, the 'transmit ring not full' condition is
very driver-dependent, some only assert it when
the ring is completely empty, others when there is
one slot available, others when there are some empty slot.

Bottom line -- the whole architecture has been designed with
FIFO in mind, and implementing any different queueing policy
will involve some significant rewriting of the device drivers,
plus, potentially, some significant performance loss.

[BTW speaking of this, just have a look at how convoluted
is the function red_drops() in dummynet, and that is for
a "simple" marking algorithm. Prioritizing packets
involves a lot more synchronization with the device
because you might need to change the next packet to
transmit even if there are some already queued].

	cheers
	luigi

> Always, even in the absence of dummynet :-)
> It keeps packets that cannot be transmitted immediately
> because device is busy. And FIFO, by definition,
> will not allow prioritized packets to go out before others.
> 
> Eugene
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"