ethernet QoS support?

ethernet QoS support?

[Kumar Gala]

Jeff,

I was wondering if there was any support for handling ethernet devices 
that support multiple RX/TX queues to provide QoS.  If so any pointers 
would be great.

thanks

- kumar

Re: ethernet QoS support?

[Jeff Garzik]

Kumar Gala wrote:
> Jeff,
> 
> I was wondering if there was any support for handling ethernet devices 
> that support multiple RX/TX queues to provide QoS.  If so any pointers 
> would be great.

IIRC skb->priority provides priority bands for TX.  Not sure about RX... 
jamal?

	Jeff

Re: ethernet QoS support?

[jamal]

On Thu, 2004-07-08 at 15:01, Jeff Garzik wrote:
> Kumar Gala wrote:
> > Jeff,
> > 
> > I was wondering if there was any support for handling ethernet devices 
> > that support multiple RX/TX queues to provide QoS.  If so any pointers 
> > would be great.
> 
> IIRC skb->priority provides priority bands for TX.  Not sure about RX... 
> jamal?

The question was very ambigous. 
What is it that Kumar is looking for? Is it 802.1p, IP level etc?

cheers,
jamal

Re: ethernet QoS support?

[Vladimir Kondratiev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I guess, Kumar is asking for support for several Tx queues with different 
priorities. One need to start/stop these queues separately. This is dictated 
by presense of different priorities on physical layer.

Kumar, is it 802.11? WME or TGE?

Vladimir.

On Thursday 08 July 2004 23:00, jamal wrote:
> On Thu, 2004-07-08 at 15:01, Jeff Garzik wrote:
> > Kumar Gala wrote:
> > > Jeff,
> > >
> > > I was wondering if there was any support for handling ethernet devices
> > > that support multiple RX/TX queues to provide QoS.  If so any pointers
> > > would be great.
> >
> > IIRC skb->priority provides priority bands for TX.  Not sure about RX...
> > jamal?
>
> The question was very ambigous.
> What is it that Kumar is looking for? Is it 802.1p, IP level etc?
>
> cheers,
> jamal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA7kMCqxdj7mhC6o0RAkeKAJ96kf49fbVy4qOjqqBBuNzmCteTrQCfU55Q
ke3RQ2prgMLEssvjeQIgegs=
=/KHu
-----END PGP SIGNATURE-----

Re: ethernet QoS support?

[jamal]

On Fri, 2004-07-09 at 03:02, Vladimir Kondratiev wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I guess, Kumar is asking for support for several Tx queues with different 
> priorities. One need to start/stop these queues separately. This is dictated 
> by presense of different priorities on physical layer.

Exactly. I referenced him to you. Have you started any work yet?

cheers,
jamal

Re: ethernet QoS support?

[Vladimir Kondratiev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 09 July 2004 16:18, jamal wrote:
> On Fri, 2004-07-09 at 03:02, Vladimir Kondratiev wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I guess, Kumar is asking for support for several Tx queues with different
> > priorities. One need to start/stop these queues separately. This is
> > dictated by presense of different priorities on physical layer.
>
> Exactly. I referenced him to you. Have you started any work yet?
>
> cheers,
> jamal
Yes, I do.
So far, I have hardware related parts working. I rely on skb->priority to 
determine traffic class and select proper queue.

All this worth nothing if one can't do separate queues. qdisc assignment for 
driver is not in driver's hands, so it can't do any assumptions. Generic 
in-kernel support needed here. Stack should allow driver to request 
additional Tx queues, providing some classifiers for each one. I tried to 
imagine how to work it around, but there is no good solution without those 
several queues.

This mean, I will be able to deliver QoS support when network stack will make 
it possible.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA7qCPqxdj7mhC6o0RAoFEAJ4j3a7ekravvh9vQC229M5a8PXcHACfY5Rp
PuvymlVUopAiUyNGqbSMl/c=
=gvWz
-----END PGP SIGNATURE-----

Re: ethernet QoS support?

[jamal]

On Fri, 2004-07-09 at 09:41, Vladimir Kondratiev wrote:

> So far, I have hardware related parts working. I rely on skb->priority to 
> determine traffic class and select proper queue.

Who marks the skb->priority? Is that the default mark as per TOS?
I think the VLAN code marks it as well.

> All this worth nothing if one can't do separate queues. qdisc assignment for 
> driver is not in driver's hands, so it can't do any assumptions.
>  Generic 
> in-kernel support needed here. Stack should allow driver to request 
> additional Tx queues, providing some classifiers for each one. I tried to 
> imagine how to work it around, but there is no good solution without those 
> several queues.

I dont think we should put intelligence at the driver level.
We can have drivers configured via parameter to look at the priority
field. Only then do they look at it; else use only single ring.
When multi-ring is on, you intepret the priority. 
priority field is set above driver based on which priority queue the
packet was grabbed from (before sending to driver).

> This mean, I will be able to deliver QoS support when network stack will make 
> it possible.

So what do you do now?

cheers,
jamal

Re: ethernet QoS support?

[Vladimir Kondratiev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 09 July 2004 17:33, jamal wrote:
> On Fri, 2004-07-09 at 09:41, Vladimir Kondratiev wrote:
> > So far, I have hardware related parts working. I rely on skb->priority to
> > determine traffic class and select proper queue.
>
> Who marks the skb->priority? Is that the default mark as per TOS?
> I think the VLAN code marks it as well.
I don't care. It should not be driver's business. Actually, it is TOS. AFAIK, 
application supposed to do setsockoption(SO_PRIORITY) on its socket so set 
priority.
>
> > All this worth nothing if one can't do separate queues. qdisc assignment
> > for driver is not in driver's hands, so it can't do any assumptions.
> > Generic
> > in-kernel support needed here. Stack should allow driver to request
> > additional Tx queues, providing some classifiers for each one. I tried to
> > imagine how to work it around, but there is no good solution without
> > those several queues.
>
> I dont think we should put intelligence at the driver level.
> We can have drivers configured via parameter to look at the priority
> field. Only then do they look at it; else use only single ring.
> When multi-ring is on, you intepret the priority.
> priority field is set above driver based on which priority queue the
> packet was grabbed from (before sending to driver).
Agree about intelligence. Driver should serve link and MAC layer. But exactly 
because link layer have different priorities, driver need several Tx queues. 
It is stack's business to route packet to the proper queue. Driver should 
deliver it using appropriate MAC layer priority.
>
> > This mean, I will be able to deliver QoS support when network stack will
> > make it possible.
>
> So what do you do now?
Waiting. If no support will exist, it simply means we will be unable to use 
QoS provided by modern 802.11. Depending on market development, impact may 
range from being slightly slower relating to Windows clients, to being almost 
completely unable to communicate for traffic like VOIP. Later will be the 
case if most access points will implement QoS as in TGE.

I can now deliver packets accordingly to skb->priority, but if stack have 
different idea for what is proper proportion between different sorts of 
traffic, driver's Tx path will be flooded with low priority frames.

Situation is much worser for streams with admission control. I have no 
mechanism to communicate with stack for such traffic establishment and tear 
down.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA7uNiqxdj7mhC6o0RAoDyAJ9dx9ibVRee1tV5RRZXyK5X+4QjswCeJ5Vj
4nZ3BKNlzLPnoga6oblpGNw=
=n/gU
-----END PGP SIGNATURE-----

Re: ethernet QoS support?

[Sam Leffler]

On Friday 09 July 2004 11:26 am, Vladimir Kondratiev wrote:

> > So what do you do now?
>
> Waiting. If no support will exist, it simply means we will be unable to use
> QoS provided by modern 802.11. Depending on market development, impact may
> range from being slightly slower relating to Windows clients, to being
> almost completely unable to communicate for traffic like VOIP. Later will
> be the case if most access points will implement QoS as in TGE.
>
> I can now deliver packets accordingly to skb->priority, but if stack have
> different idea for what is proper proportion between different sorts of
> traffic, driver's Tx path will be flooded with low priority frames.
>
> Situation is much worser for streams with admission control. I have no
> mechanism to communicate with stack for such traffic establishment and tear
> down.

FWIW the madwifi net80211 layer parses TOS to calculate priority and sticks it 
in the skb.  It also calculates the WME AC to form the QoS frame matter.  
This is then handed to drivers below.  The Atheros driver supports multiple 
tx queues in h/w with appropriate scheduling (for 5212 MACs); it uses the AC 
to set packets on the appropriate queue.

Clearly it'd be better if upper layers did the TOS stuff.  Whatever is done 
however should consider the case where the driver (nee h/w) has it's own 
queueing/scheduling facilities.

	Sam

Re: ethernet QoS support?

[Vladimir Kondratiev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 10 July 2004 01:34, Sam Leffler wrote:
> On Friday 09 July 2004 11:26 am, Vladimir Kondratiev wrote:
> > > So what do you do now?
> >
> > Waiting. If no support will exist, it simply means we will be unable to
> > use QoS provided by modern 802.11. Depending on market development,
> > impact may range from being slightly slower relating to Windows clients,
> > to being almost completely unable to communicate for traffic like VOIP.
> > Later will be the case if most access points will implement QoS as in
> > TGE.
> >
> > I can now deliver packets accordingly to skb->priority, but if stack have
> > different idea for what is proper proportion between different sorts of
> > traffic, driver's Tx path will be flooded with low priority frames.
> >
> > Situation is much worser for streams with admission control. I have no
> > mechanism to communicate with stack for such traffic establishment and
> > tear down.
>
> FWIW the madwifi net80211 layer parses TOS to calculate priority and sticks
> it in the skb.  It also calculates the WME AC to form the QoS frame matter.
Sam,
I think, to use skb->priority is more proper then parse TOS. Several points 
for this:
1. by default, IP code do it for you - it sets skb->priority equal to TOS;
2. stack may have better idea of what priority should be assigned. For this, 
it have all queuing/classifiers stuff with qdiscs.
3. it is layer violation to use information above MAC. It may be non-IP stack 
above you.
> This is then handed to drivers below.  The Atheros driver supports multiple
> tx queues in h/w with appropriate scheduling (for 5212 MACs); it uses the
> AC to set packets on the appropriate queue.
>
> Clearly it'd be better if upper layers did the TOS stuff.  Whatever is done
> however should consider the case where the driver (nee h/w) has it's own
> queueing/scheduling facilities.
>
I also do something similar. But, to be honest, this is not working. If stack 
feeds you with different mixture of high and low priority streams, you can do 
nothing. All you can do by doing additional in-driver queuing is to smooth 
short spikes.

What will you do for TGE? HCCA TSPECS and EDCA categories with admission 
control?

I continue to insist that for true MAC layer QoS, we need several Tx queues.

Anyway, I see we are on the same page with you, as we are facing same 
problems.

Vladimir
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA76/Rqxdj7mhC6o0RAvyMAJ0UafCsb2P94oo5FVbNoIZ3+qVXEACfTI3D
l9a0YAXR9xPvlpz0wZMlWdQ=
=BrFw
-----END PGP SIGNATURE-----

Re: ethernet QoS support?

[Glen Turner]

On Sat, 2004-07-10 at 18:28, Vladimir Kondratiev wrote:

> I continue to insist that for true MAC layer QoS, we need several Tx queues.

If you have several MAC-layer queues, then do you have
another set of MAC-layer scheduling?  If so, how do you
select the algorithm?

I suggest this can of worms requires further thought
before we end up with two layers of QoS queuing and
scheduling.

Cheers,
Glen

PS: Can we *please* deprecate use of the ToS bits. We had
    almost killed them and Linux is again encouraging their
    use, much to the despair of network operators (who want
    DiffServ, or at least DiffServ-compatible use of IP
    Precedence)

-- 
Glen Turner                           Tel: +61 8 8303 3936
Australian Academic & Research Network   www.aarnet.edu.au

Re: ethernet QoS support?

[jamal]

On Mon, 2004-07-12 at 04:38, Glen Turner wrote:
> On Sat, 2004-07-10 at 18:28, Vladimir Kondratiev wrote:
> 
> > I continue to insist that for true MAC layer QoS, we need several Tx queues.
> 
> If you have several MAC-layer queues, then do you have
> another set of MAC-layer scheduling?  If so, how do you
> select the algorithm?

A mapping is being suggested. Qdiscs handle the queueing. Send it to
the driver/MAC layer with instructions of which queue it goes on.

> I suggest this can of worms requires further thought
> before we end up with two layers of QoS queuing and
> scheduling.

Refer to the thread earlier; i think the mapping is pretty much
sufficient.

> PS: Can we *please* deprecate use of the ToS bits. We had
>     almost killed them and Linux is again encouraging their
>     use, much to the despair of network operators (who want
>     DiffServ, or at least DiffServ-compatible use of IP
>     Precedence)

I know you are refering to the default linux behavior, but
do you use any of the diffserv enablers like dsmark to set DSCPs?
I think 2.6.7+ we should change that default behavior. What exactly
are the network operators complaining about?

cheers,
jamal

Re: ethernet QoS support?

[Vladimir Kondratiev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 12 July 2004 15:26, jamal wrote:
> On Mon, 2004-07-12 at 04:38, Glen Turner wrote:
> > On Sat, 2004-07-10 at 18:28, Vladimir Kondratiev wrote:
> > > I continue to insist that for true MAC layer QoS, we need several Tx
> > > queues.
> >
> > If you have several MAC-layer queues, then do you have
> > another set of MAC-layer scheduling?  If so, how do you
> > select the algorithm?
>
> 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 suggest this can of worms requires further thought
> > before we end up with two layers of QoS queuing and
> > scheduling.
>
> Refer to the thread earlier; i think the mapping is pretty much
> sufficient.
There is a bit more complex then just diffserv.
Glen touched very good point: it should be no 2 QoS policies. Since in case of 
802.11, policy dictated from link layer, driver should be able to configure 
upper layers accordingly.

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.

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.
>
> > PS: Can we *please* deprecate use of the ToS bits. We had
> >     almost killed them and Linux is again encouraging their
> >     use, much to the despair of network operators (who want
> >     DiffServ, or at least DiffServ-compatible use of IP
> >     Precedence)
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.
>
> I know you are refering to the default linux behavior, but
> do you use any of the diffserv enablers like dsmark to set DSCPs?
> I think 2.6.7+ we should change that default behavior. What exactly
> are the network operators complaining about?
>
> cheers,
> jamal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA8tXIqxdj7mhC6o0RAsICAKCBBsGH5fXO3z/muggJ0K/z7o5cMwCcDaFm
qNV8hhHZRpoPHbcSSv1QHac=
=AVLn
-----END PGP SIGNATURE-----

Re: ethernet QoS support?

[jamal]

> > 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

Re: ethernet QoS support?

[jamal]

On Fri, 2004-07-09 at 14:26, Vladimir Kondratiev wrote:

> > Who marks the skb->priority? Is that the default mark as per TOS?
> > I think the VLAN code marks it as well.
> I don't care. It should not be driver's business. Actually, it is TOS. AFAIK, 
> application supposed to do setsockoption(SO_PRIORITY) on its socket so set 
> priority.

That or if routed from another host, then TOS does get extracted and set
to skb->priority


> Agree about intelligence. Driver should serve link and MAC layer. But exactly 
> because link layer have different priorities, driver need several Tx queues. 
> It is stack's business to route packet to the proper queue. Driver should 
> deliver it using appropriate MAC layer priority.

So far you have said there are two schedulers h/ware understands: strict
priority(3 band strict priority is the deafult in Linux) and WRR. 
The qdisc level is already taken care of today.


> Waiting. If no support will exist, it simply means we will be unable to use 
> QoS provided by modern 802.11. 

I think someone with motivation and hardware (such as you 
Vladimir ;->)should take the lead. I have offered to consult and review
code.

> Depending on market development, impact may 
> range from being slightly slower relating to Windows clients, to being almost 
> completely unable to communicate for traffic like VOIP. Later will be the 
> case if most access points will implement QoS as in TGE.
> 
> I can now deliver packets accordingly to skb->priority, but if stack have 
> different idea for what is proper proportion between different sorts of 
> traffic, driver's Tx path will be flooded with low priority frames.

I dont think so - as long as you map to a specific qdisc things should
work fine. i.e the scheduling semantics will be taken good care of by
the qdisc level.
So lets separate the two levels, driver and qdisc level.
I dont think they should be synchronized. In my opinion, the
synchronization point is the configurator/operator/management s/ware of
the box.

> Situation is much worser for streams with admission control. I have no 
> mechanism to communicate with stack for such traffic establishment and tear 
> down.

Let me make an interim suggestion:
To illustrate i will assume 3 priorities with priority 1 higher than
priority 3. Substitute with whatever driver does. Assuming the
priorities will be reflected in the skb->priority.

- Shut down device only when highest(1) priority ring is full.
- if packets received for priority 2 and 3 and their respective rings
are full, drop the packet in the driver and return a 0 i.e dont shut
device.

You can also do the following in the case of strict priority(caveat is
reordering may happen):
for each prio X try to stash on DMA ring of prio X. If full, try X+1, if
full try X+2 etc.

Thoughts?

cheers,
jamal

Re: ethernet QoS support?

[Vladimir Kondratiev]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 12 July 2004 15:18, jamal wrote:
> On Fri, 2004-07-09 at 14:26, Vladimir Kondratiev wrote:
> > > Who marks the skb->priority? Is that the default mark as per TOS?
> > > I think the VLAN code marks it as well.
> >
> > I don't care. It should not be driver's business. Actually, it is TOS.
> > AFAIK, application supposed to do setsockoption(SO_PRIORITY) on its
> > socket so set priority.
>
> That or if routed from another host, then TOS does get extracted and set
> to skb->priority
this is not very important. From one side, it seems like bug in routing code. 
- From another side, 802.11 was supposed for link ends only. It is not supposed 
to appear in the middle of routers chain.
>
> > Agree about intelligence. Driver should serve link and MAC layer. But
> > exactly because link layer have different priorities, driver need several
> > Tx queues. It is stack's business to route packet to the proper queue.
> > Driver should deliver it using appropriate MAC layer priority.
>
> So far you have said there are two schedulers h/ware understands: strict
> priority(3 band strict priority is the deafult in Linux) and WRR.
> The qdisc level is already taken care of today.
>
> > Waiting. If no support will exist, it simply means we will be unable to
> > use QoS provided by modern 802.11.
>
> I think someone with motivation and hardware (such as you
> Vladimir ;->)should take the lead. I have offered to consult and review
> code.
You know: schedule, plan, other job to do, limited time... And, I don't feel 
myself enough educated in network stack internals. Now I think I can speak 
for the driver. This is what I am trying to do. But I started looking for 
qdiscs and other stuff, so may be eventually I will get there.
>
> > Depending on market development, impact may
> > range from being slightly slower relating to Windows clients, to being
> > almost completely unable to communicate for traffic like VOIP. Later will
> > be the case if most access points will implement QoS as in TGE.
> >
> > I can now deliver packets accordingly to skb->priority, but if stack have
> > different idea for what is proper proportion between different sorts of
> > traffic, driver's Tx path will be flooded with low priority frames.
>
> I dont think so - as long as you map to a specific qdisc things should
> work fine. i.e the scheduling semantics will be taken good care of by
> the qdisc level.
> So lets separate the two levels, driver and qdisc level.
> I dont think they should be synchronized. In my opinion, the
> synchronization point is the configurator/operator/management s/ware of
> the box.
QoS policies are dictated by access point, they are coming to the driver from 
the link side. And I see no way to let upper layers to know these policies.
>
> > Situation is much worser for streams with admission control. I have no
> > mechanism to communicate with stack for such traffic establishment and
> > tear down.
>
> Let me make an interim suggestion:
> To illustrate i will assume 3 priorities with priority 1 higher than
> priority 3. Substitute with whatever driver does. Assuming the
> priorities will be reflected in the skb->priority.
>
> - Shut down device only when highest(1) priority ring is full.
> - if packets received for priority 2 and 3 and their respective rings
> are full, drop the packet in the driver and return a 0 i.e dont shut
> device.
Real situation:
- - highest priority is VOIP (200 bytes each 20ms). With decent link, it will 
always pass.
- - low priority is ftp bulk transfer. stack pushes more then driver can tx. I 
will silently drop 9 out of 10 packets. Not a good behavior.
>
> You can also do the following in the case of strict priority(caveat is
> reordering may happen):
> for each prio X try to stash on DMA ring of prio X. If full, try X+1, if
> full try X+2 etc.
forbidden by spec. I will be disconnected immediately.
>
> Thoughts?
>
> cheers,
> jamal
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD4DBQFA8tNhqxdj7mhC6o0RAsKoAJdfe1cMHghBSDI8Jel9zYsdmP6kAJ0fshJw
M3b1lsvT4zq3oRR5fveylg==
=6FLN
-----END PGP SIGNATURE-----

Re: ethernet QoS support?

[jamal]

On Mon, 2004-07-12 at 14:07, Vladimir Kondratiev wrote:

> > That or if routed from another host, then TOS does get extracted and set
> > to skb->priority
> this is not very important. From one side, it seems like bug in routing code. 
> - From another side, 802.11 was supposed for link ends only. It is not supposed 
> to appear in the middle of routers chain.

I dont see the bug - this is pretty standard.
Actually there is one issue, now that i think of it. The way IEEE
maps priority is the opposite of the way IETF does it ;->
If you have 8 priorities then priority 7 would be the highest in 
IEEE speak (i.e most important) but priority 0 would be the one
considered most important for IEEE. so a strict TOS -> skb->priority
wont work ;->


> > I dont think so - as long as you map to a specific qdisc things should
> > work fine. i.e the scheduling semantics will be taken good care of by
> > the qdisc level.
> > So lets separate the two levels, driver and qdisc level.
> > I dont think they should be synchronized. In my opinion, the
> > synchronization point is the configurator/operator/management s/ware of
> > the box.
> QoS policies are dictated by access point, they are coming to the driver from 
> the link side. And I see no way to let upper layers to know these policies.

Huh? Are these speacial L2 level frames which carry the policy?
Sounds like the people doing this were on some cheap crack.
Can you describe these frames a little more?

> > - Shut down device only when highest(1) priority ring is full.
> > - if packets received for priority 2 and 3 and their respective rings
> > are full, drop the packet in the driver and return a 0 i.e dont shut
> > device.
> Real situation:
> - - highest priority is VOIP (200 bytes each 20ms). With decent link, it will 
> always pass.
> - - low priority is ftp bulk transfer. stack pushes more then driver can tx. I 
> will silently drop 9 out of 10 packets. Not a good behavior.

Thats the definition of strict priority.
In other words if theres VOIP packet you always send VOIP untuil theres
no more VOIP. Only then you send ftp packets.
On the case of WRR, you do give some break to ftp at some point. But
this is not something you have to worry about once the qdiscs are
configured properly.

> >
> > You can also do the following in the case of strict priority(caveat is
> > reordering may happen):
> > for each prio X try to stash on DMA ring of prio X. If full, try X+1, if
> > full try X+2 etc.
> forbidden by spec. I will be disconnected immediately.

Ok.

cheers,
jamal

Re: ethernet QoS support?

[jamal]

On Mon, 2004-07-12 at 22:26, jamal wrote:

> If you have 8 priorities then priority 7 would be the highest in 
> IEEE speak (i.e most important) but priority 0 would be the one
> considered most important for IEEE. 
                         that   ^^^^ should be IETF.

cheers,
jamal

Re: ethernet QoS support?

[Kumar Gala]

On Jul 9, 2004, at 2:02 AM, Vladimir Kondratiev wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I guess, Kumar is asking for support for several Tx queues with 
> different
> priorities. One need to start/stop these queues separately. This is 
> dictated
> by presense of different priorities on physical layer.
>
> Kumar, is it 802.11? WME or TGE?

I'm not sure what WME or TGE stand for, we are looking at a gig-e 
controller.

>
> Vladimir.
>
> On Thursday 08 July 2004 23:00, jamal wrote:
>> On Thu, 2004-07-08 at 15:01, Jeff Garzik wrote:
>>> Kumar Gala wrote:
>>>> Jeff,
>>>>
>>>> I was wondering if there was any support for handling ethernet 
>>>> devices
>>>> that support multiple RX/TX queues to provide QoS.  If so any 
>>>> pointers
>>>> would be great.
>>>
>>> IIRC skb->priority provides priority bands for TX.  Not sure about 
>>> RX...
>>> jamal?
>>
>> The question was very ambigous.
>> What is it that Kumar is looking for? Is it 802.1p, IP level etc?
>>
>> cheers,
>> jamal
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFA7kMCqxdj7mhC6o0RAkeKAJ96kf49fbVy4qOjqqBBuNzmCteTrQCfU55Q
> ke3RQ2prgMLEssvjeQIgegs=
> =/KHu
> -----END PGP SIGNATURE-----