Per radio configuration

Per radio configuration

[Ben Greear]

Hello!

I'm considering a case where I have multiple ath10k NICs in
a system, possibly not all the same chipset.

I may want to have one optimized for smaller number of vdevs and more
peers, and another many vdevs, fewer peers, etc.  Some chipsets

Module options are not optimal for this since there is no easy way to
have different options for different NICs.

I'm thinking about making a loadable 'firmware' file that has
text-based config, something like:

# First radio
Device=05:00.0
	vdev_count=8
	peer_count=128
         firmware_name=firmware-5-b.bin
	firmware_ver=5

# Second radio
Device=06:00.0
	vdev_count=4
	peer_count=200
         firmware_name=firmware-2.bin
	firmware_ver=2

# End of file


When parsing, Lines starting with # would be ignored.
Any un-known tokens would be ignored, for backwards/forwards compatibility.

This file would be loaded and parsed before loading other firmware images
so that we can use particular firmware images per radio.  This further lets one
optimize one radio for one thing, one for another.  For instance, if someone
requires IBSS and wants to use stock QCA firmware, they can use the 'main' firmware
for that radio, and the most recent one for another radio that needs to be a stable AP.

In addition to this, we would need to store the vdev combinations
in RAM in the 'ar' struct, so we could get rid of all of the static,
hard-coded members and set the capabilities to match the requested
values.

Any opinions on this?  Something that might be worthwhile for upstream?

Thanks,
Ben

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


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Per radio configuration

[Valo, Kalle]

Ben Greear <greearb@candelatech.com> writes:

> Hello!
>
> I'm considering a case where I have multiple ath10k NICs in
> a system, possibly not all the same chipset.
>
> I may want to have one optimized for smaller number of vdevs and more
> peers, and another many vdevs, fewer peers, etc.  Some chipsets
>
> Module options are not optimal for this since there is no easy way to
> have different options for different NICs.
>
> I'm thinking about making a loadable 'firmware' file that has
> text-based config, something like:
>
> # First radio
> Device=05:00.0
> 	vdev_count=8
> 	peer_count=128
>         firmware_name=firmware-5-b.bin
> 	firmware_ver=5
>
> # Second radio
> Device=06:00.0
> 	vdev_count=4
> 	peer_count=200
>         firmware_name=firmware-2.bin
> 	firmware_ver=2
>
> # End of file

Ok, so basically an .ini file for the driver.

> When parsing, Lines starting with # would be ignored.
> Any un-known tokens would be ignored, for backwards/forwards compatibility.
>
> This file would be loaded and parsed before loading other firmware
> images so that we can use particular firmware images per radio. This
> further lets one optimize one radio for one thing, one for another.
> For instance, if someone requires IBSS and wants to use stock QCA
> firmware, they can use the 'main' firmware for that radio, and the
> most recent one for another radio that needs to be a stable AP.
>
> In addition to this, we would need to store the vdev combinations
> in RAM in the 'ar' struct, so we could get rid of all of the static,
> hard-coded members and set the capabilities to match the requested
> values.
>
> Any opinions on this?  Something that might be worthwhile for upstream?

I have seen lots of out-of-tree drivers having something like this but I
doubt that something like this would be acceptable in upstream. Anyway
this is something which should be discussed in linux-wireless with a
wider audience, maybe even in lkml.

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Per radio configuration

[Ben Greear]

On 03/03/2016 07:35 AM, Valo, Kalle wrote:
> Ben Greear <greearb@candelatech.com> writes:
>
>> Hello!
>>
>> I'm considering a case where I have multiple ath10k NICs in
>> a system, possibly not all the same chipset.
>>
>> I may want to have one optimized for smaller number of vdevs and more
>> peers, and another many vdevs, fewer peers, etc.  Some chipsets
>>
>> Module options are not optimal for this since there is no easy way to
>> have different options for different NICs.
>>
>> I'm thinking about making a loadable 'firmware' file that has
>> text-based config, something like:
>>
>> # First radio
>> Device=05:00.0
>> 	vdev_count=8
>> 	peer_count=128
>>          firmware_name=firmware-5-b.bin
>> 	firmware_ver=5
>>
>> # Second radio
>> Device=06:00.0
>> 	vdev_count=4
>> 	peer_count=200
>>          firmware_name=firmware-2.bin
>> 	firmware_ver=2
>>
>> # End of file
>
> Ok, so basically an .ini file for the driver.
>
>> When parsing, Lines starting with # would be ignored.
>> Any un-known tokens would be ignored, for backwards/forwards compatibility.
>>
>> This file would be loaded and parsed before loading other firmware
>> images so that we can use particular firmware images per radio. This
>> further lets one optimize one radio for one thing, one for another.
>> For instance, if someone requires IBSS and wants to use stock QCA
>> firmware, they can use the 'main' firmware for that radio, and the
>> most recent one for another radio that needs to be a stable AP.
>>
>> In addition to this, we would need to store the vdev combinations
>> in RAM in the 'ar' struct, so we could get rid of all of the static,
>> hard-coded members and set the capabilities to match the requested
>> values.
>>
>> Any opinions on this?  Something that might be worthwhile for upstream?
>
> I have seen lots of out-of-tree drivers having something like this but I
> doubt that something like this would be acceptable in upstream. Anyway
> this is something which should be discussed in linux-wireless with a
> wider audience, maybe even in lkml.

You are the maintainer, so, do *you* like the idea?  If you don't, then
there is no use in me putting more effort into it for upstream use.

If you do, then I will work on cleaning up a patch for upstream and post
it to a wider audience.

Thanks,
Ben


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


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Per radio configuration

[Valo, Kalle]

Ben Greear <greearb@candelatech.com> writes:

>> Ok, so basically an .ini file for the driver.
>>
>>> When parsing, Lines starting with # would be ignored.
>>> Any un-known tokens would be ignored, for backwards/forwards compatibility.
>>>
>>> This file would be loaded and parsed before loading other firmware
>>> images so that we can use particular firmware images per radio. This
>>> further lets one optimize one radio for one thing, one for another.
>>> For instance, if someone requires IBSS and wants to use stock QCA
>>> firmware, they can use the 'main' firmware for that radio, and the
>>> most recent one for another radio that needs to be a stable AP.
>>>
>>> In addition to this, we would need to store the vdev combinations
>>> in RAM in the 'ar' struct, so we could get rid of all of the static,
>>> hard-coded members and set the capabilities to match the requested
>>> values.
>>>
>>> Any opinions on this?  Something that might be worthwhile for upstream?
>>
>> I have seen lots of out-of-tree drivers having something like this but I
>> doubt that something like this would be acceptable in upstream. Anyway
>> this is something which should be discussed in linux-wireless with a
>> wider audience, maybe even in lkml.
>
> You are the maintainer, so, do *you* like the idea?  

I'm _one_ of the maintainers, a big difference :) This is not just about
ath10k but all wireless drivers (or maybe even about all network
drivers).

I think that there's more and more need for something like this[1] in
wireless drivers. I read your mail about this only today (yeah, I'm
backlogged quite a lot) but I actually talked about this very problem at
the Wireless Summit in Sevilla. It didn't get very far and no real
solution was found except doing the configuration via debugfs and
restarting the firmware. Not really an ideal solution.

But I don't think the .ini approach is really doable either, having an
ini parser in kernel sounds scary. Hopefully there is a better way to do
it.

> If you don't, then there is no use in me putting more effort into it
> for upstream use.
>
> If you do, then I will work on cleaning up a patch for upstream and post
> it to a wider audience.

I think this needs a lot more discussion before using time for the
actual implementation.

[1] I mean something like device specific module parameters (instead of
    driver global parameters we have now) where you can set parameters
    per PCI/USB/SDIO device.

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: Per radio configuration

[Valo, Kalle]

Jasmine Strong <jas@eero.com> writes:

> This seems like the sort of thing the flattened device tree was
> intended to do.

I'm no DT expert but isn't device tree supposed to only describe
hardware properties? This is more like a software property, for example
how to allocate memory on the firmware etc.

-- 
Kalle Valo
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k