> > A mapping is being suggested. Qdiscs handle the queueing. Send it to
> > the driver/MAC layer with instructions of which queue it goes on.
>
> Problem is, I don't know how driver can dictate what qdiscs should be
> attached
> to it. AFAIK, it is under 'tc' control. What I suggest, is to provide some
> API for driver to configure its qdiscs.
I think driver doing this is the wrong abstraction layer..
How about this: Write a user space daemon that receives those
L2 policy frames from the driver. Daemon then uses netlink to configure
the qdiscs appropriately. This replaces the human opertaor who would do
this in the case of a static setup.
> And most complex item: I don't know how to support intserv type of streams,
> i.e. streams with admission control. let's say it is like RSVP with support
> on link layer.
OK, so it is RSVP being used for policy config then?
You seem to indicate it RSVP-like?
> Should I try to summarize QoS facilities defined in TGE (new standard for QoS
> in 802.11)? I tried to do it once, but I don't feel I expressed it clearly.
I think so.
> One more reason why I prefer to use skb->priority over TOS: driver should be
> protocol agnostic. It may be non-IP, and TOS may be missing.
The TOS was being used as an example. The VLAN code for example
sets skb->priority at L2 as well. So nothing protcol specific about
skb->priority.
cheers,
jamal
|