I'd like to evaluate possibility to use your stack for real driver. 80211 have
some specifics thus we need to answer following questions:
- some devices handles almost all MAC in firmware; some - handle control frame
exchange in firmware, rest - on host; some use other separation of work
between host and firmware. So, quite flexible mechanism to specify offloading
of parts of .11 stack to firmware required. What is best way?
- there are cases when PHY information needed, to make decisions (like select
AP from list), or for information purposes (sniffer). What is your vision how
to do this? I.e. provide some standard PHY header before MAC header, out of
band (use cb?)
I see the following info that may be interesting:
rate;modulation;preamble;TSF timer;RSSI;antenna;signal;noise;AGC. This list
may vary from NIC to NIC.
- there is PHY level information that may be needed for Tx:
modulation;rate;retry policy and rates;Tx power;protection(RTS/CTS, CTS to
self). Same question as above: how to provide it?
- there is some interesting information that may come from Tx status, like
success indication, last rate, retry count, energy in channel after packet,
actual backoff time.
- is it feasible to do rate scaling in generic way in stack? Or should it be
done always in the driver?
- Since WME and TGe introduction, NICs will likely to have multiple Tx queues.
It would be wise for driver to use multiple Tx queues and start/stop them
separately, like have all functions netif_start_queue() etc. have additional
parameter - queue number. Will it fit into your stack?
Description: PGP signature