mac80211-hwsim and tx-rates.

mac80211-hwsim and tx-rates.

[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?

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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: mac80211-hwsim and tx-rates.

[Arend van Spriel]

On 03/11/15 22:07, Ben Greear wrote:
> 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

> 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
>

Re: mac80211-hwsim and tx-rates.

[Ben Greear]

On 03/11/2015 02:31 PM, Arend van Spriel wrote:
> On 03/11/15 22:07, Ben Greear wrote:
>> 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.

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


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: mac80211-hwsim and tx-rates.

[Bob Copeland]

On Wed, Mar 11, 2015 at 03:06:18PM -0700, Ben Greear wrote:
> 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?

-- 
Bob Copeland %% http://bobcopeland.com/

Re: mac80211-hwsim and tx-rates.

[Ben Greear]

On 03/14/2015 03:47 AM, Bob Copeland wrote:
> On Wed, Mar 11, 2015 at 03:06:18PM -0700, Ben Greear wrote:
>> 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.

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?

>
> 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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: mac80211-hwsim and tx-rates.

[Bob Copeland]

On Sat, Mar 14, 2015 at 09:14:14AM -0700, Ben Greear wrote:
> 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.

> 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.

-- 
Bob Copeland %% http://bobcopeland.com/

Re: mac80211-hwsim and tx-rates.

[Ben Greear]

On 03/14/2015 10:48 AM, Bob Copeland wrote:
> On Sat, Mar 14, 2015 at 09:14:14AM -0700, Ben Greear wrote:
>> 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.


>> 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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com