Re: in-driver QoS

[Vladimir Kondratiev <vkondra@mail.ru>]

Jamal,
let's list the features need to be provided for 802.11 QoS, and problems.

It is worth to provide standard interface with wireless stack; otherwise each 
driver will invent its own solution.

1. NIC have number of Tx DMA channels, with different channels used for 
different priorities. It is dictated by standard (TGe).

Most likely, it should be 4 queues for EDCA traffic (4 priorities), 1 for HCCA 
(polled, pre-agreed streams) and optionally 1 for multicast traffic (AP need 
it).

Each queue need to start/stop separately. For flexibility, it should be some 
way for driver to request queues and specify mapping to these queues.

Ideas for how to implement it in stack?

Meanwhile, ideas how to get separate per-priority control with existing 
infrastructure?

2. There is traffic that require admission control. Unless driver performs 
allocation with AP, this traffic is not allowed. TGe standard dictates it.

Driver should participate in bandwidth allocation (via RSVP?). It should get 
some form of request (IOCTL?) which it will serve by performing allocation on 
link layer. It is easy to do proprietary IOCTL and white custom RSVP daemon, 
but it is much better to do something generic for all drivers to use.

Vladimir.