* Jamal Hadi Salim <[EMAIL PROTECTED]> 2005-07-23 10:14
> Most of these pieces of h/ware have different approaches to how those
> underlying rings are used sending out to the wire. As an example, it is
> clear the wireless folks have time slots + prios as the desired qos
> scheme. This will map nicely to a top qdisc that is based on deficit
> roundrobin or even simple weighted roundrobin
> i.e you map the time slots to weights and priorities on the rings to the
> s/ware queue priorities. Hopefully Thomas can get that qdisc done.
This might work for simple ring setups but I'm not sure if we can
guarantee to keep the rings filled in order to avoid gaps on the
wire.
As I take it, your approach would try to avoid having a feedback
system for the drivers to report to the qdisc which band -> ring
are to be disabled for the moment.
What I'd propose is to have something like netif_queue_stop() but
taking a prio argument so the qdisc knows about the status of
the rings. The drawback of this idea is that if the band -> ring
mapping is not 1:1 it gets a little more complex and all the
qdiscs which don't do drr or simliar yet need to be changed. The
advantage clearly is the added flexibility because we can make it
work with htb and other sharing concepts.
> Some of the other NICs have different schemes than the wireless people
> need.
> Example the freescale people have a strict priority as well as a
> weighted round robin scheme. Depending on how the administrator
> configures such a NIC (maybe via ethttool), they have also to attach to
> it a specific root qdisc that maps correctly to the underlying rings.
> And yet another example is the newer upcoming e1000 which is based on
> just strict prio.
The simplest case is if the hardware does strict prio and does
the queueing itself based on skb->priority or similiar. We don't
need to change anything in this case except for adding the
interface to transfer the classification result to the driver.
WRR shouldn't be a problem, although the concept is more vulnerable
to reodering if the classification doesn't work properly.
Now on to the 802.11e case:
a) We need to move the queues to the hardware in order to allow
the driver to report the queue lengths to the HC.
b) The queue lengths are also required to calculate the per TC
class contention window and I think asking the qdisc for this
information is not the way to go.
c) The TC classes of the hardware can been seen as independant
stations, so they have own backoff counters. The only
speciality is that collision detection can be done before the
"wire".
-> This stuff is really dependant on the driver and probably
requires some changes.
Do we have any hardware which expects filling the rings in a
RR fashion?
> Setting the skb->prio to be used by the driver sounds reasonable.
> Another alternative would be what was already mentioned to change the
> call to hardware_start_transmit() to take a prio option.
> The driver should take care of what that all means given that we have
> views that differ depending on the h/ware.
I agree.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
