mac80211-hwsim and tx-rates.
When using the user-space transport, the netlink frame sent to user-space has a rate index and retry count, and nothing else. Is there a reliable way to know in user-space what index maps to what actual rate?
If not, any suggestions for how to improve this? Maybe add a new object that passes up a bunch more info about the actual rates instead of just the rate idx?
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 3 lines · Ben Greear
When using the user-space transport, the netlink frame sent to user-space has a rate index and retry count, and nothing else. Is there a reliable way to know in user-space what index maps to what actual rate?
Not sure what you are exactly looking for, but maybe the function cfg80211_calculate_bitrate() in net/wireless/util.c may provide you some answers.
Regards,
Arend
Quoted 7 lines
If not, any suggestions for how to improve this? Maybe add a new object that passes up a bunch more info about the actual rates instead of just the rate idx?
Thanks,
Ben
Quoted 6 lines · Arend van Spriel
Quoted 3 lines · Ben Greear
When using the user-space transport, the netlink frame sent to user-space has a rate index and retry count, and nothing else. Is there a reliable way to know in user-space what index maps to what actual rate?
Not sure what you are exactly looking for, but maybe the function
cfg80211_calculate_bitrate()innet/wireless/util.cmay provide you some answers.
Well, that would be useful in the kernel, but in user-space w/hardware sim, as far as I can tell we only have this rate info:
/**
* struct hwsim_tx_rate - rate selection/status
*
* @idx: rate index to attempt to send with
* @count: number of tries in this rate before going to the next rate *
* A value of -1 for @idx indicates an invalid rate and, if used
* in an array of retry rates, that no more rates should be tried. *
* When used for transmit status reporting, the driver should
* always report the rate and number of retries used.
*
*/
struct hwsim_tx_rate {
s8 idx;
u8 count;
} __packed;I don't see a good way to tie that idx to an actual rate (which involves flags, nss, mcs values, etc).
Maybe I should also just send the info I care about, which is a 'bps' rate, channel-width indication, SGI, etc as separate netlink attributes....
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 5 lines · Ben Greear
I don't see a good way to tie that idx to an actual rate (which involves flags, nss, mcs values, etc).
Maybe I should also just send the info I care about, which is a 'bps' rate, channel-width indication, SGI, etc as separate netlink attributes....
My wmediumd fork (https://github.com/bcopeland/wmediumd) could benefit from this as well -- right now it assumes you use OFDM rates only.
It probably makes sense to send the driver rate array as a separate netlink message though instead of in-band with CMD_FRAME, since it doesn't change per frame and amount of data sent over netlink in the datapath already imposes a performance limit.
Is your simulator available somewhere?
Signature · 1 line
Bob Copeland %% http://bobcopeland.com/
Quoted 7 lines · Bob Copeland
Quoted 5 lines · Ben Greear
I don't see a good way to tie that idx to an actual rate (which involves flags, nss, mcs values, etc).
Maybe I should also just send the info I care about, which is a 'bps' rate, channel-width indication, SGI, etc as separate netlink attributes....
Quoted 7 lines
My wmediumd fork (https://github.com/bcopeland/wmediumd) could benefit from this as well -- right now it assumes you use OFDM rates only.
It probably makes sense to send the driver rate array as a separate netlink message though instead of in-band with
CMD_FRAME, since it doesn't change per frame and amount of data sent over netlink in the datapath already imposes a performance limit.
It can change with every packet based on rate-control logic, right?
Possibly the power is mostly constant, but I thought I saw email about someone working on rate-ctrl logic that adjusted power on a per-packet basis, so thought it best to put in there now.
And, it seems unlikely to me that an extra 16 bytes or so would make a great deal of difference. Using hash tables instead of linear walks and other things would likely improve performance more?
Quoted 2 lines
Is your simulator available somewhere?
No, sorry..it is a closed source thing that I am working on with another company...even I do not have any real rights to the code. After a period of time I may be able to start work on a similar simulator project, but for now all I can contribute publicly is the kernel parts that must necessarily be open-source.
For what it's worth, the patch I posted seems to work with the user-space app I've been working on.
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 1 line · Ben Greear
It can change with every packet based on rate-control logic, right?
You said you wanted to go from index to bitrate -- the index changes, but not the rate<->index mapping.
Quoted 3 lines
And, it seems unlikely to me that an extra 16 bytes or so would make a great deal of difference. Using hash tables instead of linear walks and other things would likely improve performance more?
Last time I tested with perf, memcpy dominated everything -- I've been thinking about having a mode where just headers are sent to userspace to avoid some of that.
Signature · 1 line
Bob Copeland %% http://bobcopeland.com/
Quoted 5 lines · Bob Copeland
Quoted 1 line · Ben Greear
It can change with every packet based on rate-control logic, right?
You said you wanted to go from index to bitrate -- the index changes, but not the rate<->index mapping.
The index means different things based on legacy, HT, VHT. You need index
+ flags to determine the actual rate for each packet.
I am fine with hard-coding in user-space the correlation of legacy index to rates.
The array that is currently sent to user-space is the rates that rate-ctrl determines should be used for transmit (and re-transmit), as far as I can tell.
Quoted 7 lines
Quoted 3 lines
And, it seems unlikely to me that an extra 16 bytes or so would make a great deal of difference. Using hash tables instead of linear walks and other things would likely improve performance more?
Last time I tested with perf, memcpy dominated everything -- I've been thinking about having a mode where just headers are sent to userspace to avoid some of that.
I need full pkt in user-space, but at least for some use-cases your idea may be a nice improvement.
With hundreds of virtual radios and network devices, hashing the lookup of radios should be a big win. I'll work on that someday soon most likely.
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com