d80211 and sta_aid for AP functionality

[Johannes Berg <johannes@sipsolutions.net>]

Hey,

I was looking through the d80211 code and noticed this comment and code:

        /* TODO: sta_aid could be replaced by 2008-bit large bitfield of
         * that could be used in TIM element generation. This would also
         * make TIM element generation a bit faster. */
        /* AID mapping to station data. NULL, if AID is free. AID is in the
         * range 1..2007 and sta_aid[i] corresponds to AID i+1. */
        struct sta_info *sta_aid[MAX_AID_TABLE_SIZE];

Note that this is part of struct ieee80211_if_ap which is in a union for 
each virtual device.

About 15 seconds later it almost blew me off my chair ;) I had realized 
that this is 8k kernel memory for each virtual device with absolutely no 
function in the common case! AX_AID_TABLE_SIZE is set to 2007 (the 
802.11 spec maximum)...

In fact, with this, the struct ieee80211_sub_if_data is 8560 bytes, 
without it it's a meager 588 bytes. Hence, when the interface is 
anything but an AP interface, we waste almost 8K. And even if it's an AP 
interface, who ever has 2007 stations associated?

Since the stations are saved in a hash-table (the hashing by the last 
byte of the mac address doesn't seem too efficient though...) all the 
sta_aids array needs to do is answer the following questions quickly:
 (a) is the AID N used?
 (b) what is the sta_info pointer for AID N?

Since userspace manages AIDs, we don't even need to be able to answer 
things like "what is the lowest unused AID?". I don't quite understand 
why we don't stop userspace from using the same AID for different 
stations, which will give surely result in trouble, but hey.

Looking through the code, I notice that above (a) and (b) can be 
collapsed into just keeping track of the TIM throughout the code. I 
suppose that's meant by the comment above? Then we can't add the check 
for saying 'hey you stupid userspace that AID is already used' but 
that's ok I guess.

If you can confirm that my analysis is correct I'd be willing to try 
making this change. This would at least go down to 251 bytes for the 
bitmap and thus reduce sub_if_data to about 760 bytes. The only 
complication I see with this right now is that of locking, but I haven't 
looked closely yet.

johannes