Hi all,
Linux cfg80211 regulatory subsystem uses CRDA timeout to ensure completion
of regulatory updates, performed by user-space software. See call_crda
functon in net/wireless/reg.c:
static int call_crda(const char *alpha2)
{
...
queue_delayed_work(system_power_efficient_wq,
&crda_timeout, msecs_to_jiffies(3142));
return 0;
}
So regulatory update/reset operations shall be completed in 3142 msec.
And that includes processing of regulatory notifiers for all the
wireless cards in the system.
It is not quite clear where this specific timeout value came from.
Original commit (a90c7a313a1c5b) doesn't go into details about it.
Any ideas where it could come from ?
Regards,
Sergey
On Tue, 2019-03-26 at 12:42 +0000, Sergey Matyukevich wrote:
> Hi all,
>
> Linux cfg80211 regulatory subsystem uses CRDA timeout to ensure completion
> of regulatory updates, performed by user-space software. See call_crda
> functon in net/wireless/reg.c:
>
> static int call_crda(const char *alpha2)
> {
> ...
>
> queue_delayed_work(system_power_efficient_wq,
> &crda_timeout, msecs_to_jiffies(3142));
> return 0;
> }
>
> So regulatory update/reset operations shall be completed in 3142 msec.
> And that includes processing of regulatory notifiers for all the
> wireless cards in the system.
>
> It is not quite clear where this specific timeout value came from.
> Original commit (a90c7a313a1c5b) doesn't go into details about it.
>
> Any ideas where it could come from ?
No particular reason. It's just ~pi seconds, and IIRC Luis thought that
was funny :-)
Are you seeing any issues with that?
johannes
> > Linux cfg80211 regulatory subsystem uses CRDA timeout to ensure completion
> > of regulatory updates, performed by user-space software. See call_crda
> > functon in net/wireless/reg.c:
> >
> > static int call_crda(const char *alpha2)
> > {
> > ...
> >
> > queue_delayed_work(system_power_efficient_wq,
> > &crda_timeout, msecs_to_jiffies(3142));
> > return 0;
> > }
> >
> > So regulatory update/reset operations shall be completed in 3142 msec.
> > And that includes processing of regulatory notifiers for all the
> > wireless cards in the system.
> >
> > It is not quite clear where this specific timeout value came from.
> > Original commit (a90c7a313a1c5b) doesn't go into details about it.
> >
> > Any ideas where it could come from ?
>
> No particular reason. It's just ~pi seconds, and IIRC Luis thought that
> was funny :-)
Indeed, it is PI. I should have known. But instead I spent some time
digging through 802.11 specs :)
> Are you seeing any issues with that?
Well, as I mentioned in my question, regulatory update/reset operations
shall be completed in ~pi seconds for _all_ the wireless cards in the
system. In our case, regulatory reset operation may be fairly costly.
As a result, we end up with recurring reset timeout, when more than one
qtn card is installed in a single pcie host. One option for us is to
optimize regulatory reset operations in firmware.
But what do you think about converting crda_timeout into a per-wiphy
timeout in the case when all wiphy-s are being processed, e.g.
in update_all_wiphy_regulatory.
Regards,
Sergey
On Tue, 2019-04-09 at 08:35 +0000, Sergey Matyukevich wrote:
> Indeed, it is PI. I should have known. But instead I spent some time
> digging through 802.11 specs :)
Oops :)
> Well, as I mentioned in my question, regulatory update/reset operations
> shall be completed in ~pi seconds for _all_ the wireless cards in the
> system. In our case, regulatory reset operation may be fairly costly.
> As a result, we end up with recurring reset timeout, when more than one
> qtn card is installed in a single pcie host. One option for us is to
> optimize regulatory reset operations in firmware.
>
> But what do you think about converting crda_timeout into a per-wiphy
> timeout in the case when all wiphy-s are being processed, e.g.
> in update_all_wiphy_regulatory.
Maybe we should parallelize it? But I don't know how easy that would be.
I'm a little worried just making it longer will cause users to really be
wondering what's going on?
johannes
> > Indeed, it is PI. I should have known. But instead I spent some time
> > digging through 802.11 specs :)
>
> Oops :)
>
> > Well, as I mentioned in my question, regulatory update/reset operations
> > shall be completed in ~pi seconds for _all_ the wireless cards in the
> > system. In our case, regulatory reset operation may be fairly costly.
> > As a result, we end up with recurring reset timeout, when more than one
> > qtn card is installed in a single pcie host. One option for us is to
> > optimize regulatory reset operations in firmware.
> >
> > But what do you think about converting crda_timeout into a per-wiphy
> > timeout in the case when all wiphy-s are being processed, e.g.
> > in update_all_wiphy_regulatory.
>
> Maybe we should parallelize it? But I don't know how easy that would be.
>
> I'm a little worried just making it longer will cause users to really be
> wondering what's going on?
Hello Johannes,
Calling regulatory notifiers in parallel sounds like a good idea.
But I haven't yet looked into the details as well. Before fixing
the timeout issue, I was trying to figure out why that regulatory
reset was needed at all.
Here is a simple usecase: Linux distro sets regulatory region to US,
STA is connected to AP. Any STA disconnect (including an attempt to
reconnect to another AP) leads to regulatory reset cycle: US -> 00 -> US.
This reset cycle is not supposed to be done for the wireless cards that
specify REGULATORY_COUNTRY_IE_IGNORE flag. However regulatory reset will
be applied anyway if at least one card in the system does not specify
that flag.
Hence two questions:
Do we really need this kind of reset when we remain
in the same regulatory domain ?
Does it make sense to track when restore_regulatory_settings performs
reset, and to skip reset for the cards that specify
REGULATORY_COUNTRY_IE_IGNORE ?
Regards,
Sergey
Hi Sergey,
On Thu, 2019-04-11 at 12:40 +0000, Sergey Matyukevich wrote:
> Calling regulatory notifiers in parallel sounds like a good idea.
> But I haven't yet looked into the details as well. Before fixing
> the timeout issue, I was trying to figure out why that regulatory
> reset was needed at all.
:-)
> Here is a simple usecase: Linux distro sets regulatory region to US,
> STA is connected to AP. Any STA disconnect (including an attempt to
> reconnect to another AP) leads to regulatory reset cycle: US -> 00 -> US.
> This reset cycle is not supposed to be done for the wireless cards that
> specify REGULATORY_COUNTRY_IE_IGNORE flag. However regulatory reset will
> be applied anyway if at least one card in the system does not specify
> that flag.
>
> Hence two questions:
> Do we really need this kind of reset when we remain
> in the same regulatory domain ?
Probably doesn't make sense. If I were to guess I'd say that was a
simplification, since in many cases we'd actually be doing something
like (intersected) -> 00 -> US?
Actually, in your example, we're probably doing "US->00" and "00->US"
separately since we don't really know that we're going to connect again
to a similar AP, right?
Adding Luis, just in case he remembers anything about this ...
> Does it make sense to track when restore_regulatory_settings performs
> reset, and to skip reset for the cards that specify
> REGULATORY_COUNTRY_IE_IGNORE ?
I guess that'd make some sense anyway?
I do think ultimately we need some kind of reset every once a while when
we're disconnected, otherwise we'll just carry around intersections and
other baggage forever.
johannes