> Mhh, I thought also some atheros drivers implement hardware multirate > retry changes, which maps to this struct. Only one rate per frame > would introduce a extreme additional communication overhead, which > will make testing with standard wmediumd impractical. I think we need > to keep such a structure, but we should align that with other > mac80211 depended drivers. Yeah, I was being imprecise. The driver interface is usually similar to the mac80211 struct in one way or another (though it might also be a more global table, like other drivers implement). I was more thinking of the actual air interface. I'm not too worried about the efficiency of this (we can push quite a few gbps over hwsim today iirc), but it actually doesn't make sense because an accurate simulation would require NAV/TXOP simulation, and that wouldn't be possible with "software retry". So I think our best bet remains to map this to new attributes - better with properly formatted ones etc. than with the struct (keeping that only for compatibility) If you're worried about the overhead, we could consider converting hwsim to use the rate_table API - see struct ieee80211_sta -> rates, and maybe adding a signal to update that in the driver, send that to userspace directly and work with that, rather than "serializing" the table for every frame? johannes
