Specifing rate control algorithm?

ieee80211_init_rate_ctrl_alg is the only function that can select the rate control algorithm by name, and that symbol is not set as EXPORT_SYMBOL.

Currently the stack picks the first one it finds and I can't find a way for the driver or the user to override this behavior (esp. if the rate control algorithm is compiled as a built-in)

Adding EXPORT_SYMBOL for ieee80211_init_rate_ctrl_alg would allow the driver to request the algorithm known to work best with that hardware.

-or-

we can change ieee80211_register_hw() to take a 'name' parameter specifying the rate control algorithm to use. Drivers that don't care can pass NULL and the stack will do what it does now (pick the first algorithm registered with the stack)

Preference?

James

That's true and it's not going to be exported.

It was possible to change the rate control algorithm through sysfs, unfortunately this ability was removed during the conversion to debugfs. It will be made possible again through nl80211.

A driver is not supposed to set rate control. Under no circumstances. If you know about a bug in default rate control algorithm, fix it and send a patch. Otherwise, fix your driver.

NACK.

Write a patch for nl80211/cfg80211.

Jiri

Jiri Benc
SUSE Labs

I don't think I would fully agree with this. Sure, the default rate control algorithm should work with all drivers, but it is quite possible that some rate control algorithms do not work with all drivers and some combinations are much better than the "default algorithm". In other words, I think there is benefit in drivers being able to "suggest" a rate control algorithm to be used and there is not much point having to force the user space to do this selection for the initial rate control algorithm. Sure, this should still be something that can be changed from user space, but the defaults selection could as well be the best available combination.

Some hardware designs provide extra functionality that can be used to improve rate control algorithm and as such, they may benefit greatly from a specific rate control implementation. Because of this, there was originally possibility for allowing the rate control algorithms to know the driver name and use this to select whether to allow the algorithm to be used with the driver. The request here was for a bit different way of doing this, but anyway, I see value in this whichever way it would be implemented.

Jouni Malinen                                            PGP id EFC895FA

Just was about to write the same.

In addition the interface that passes the rate scale information (struct ieee80211_tx_status) from driver to rate scale algorithm is not general enough to support hw specific data.

Tomas

Algorithms which can take advantage of features exposed by specific hardware will be able to perform better than pure software solutions when you account for system latency, throughput, power consumption, etc.

AFAIK, the default rate control algorithm is fine for software only solutions that don't take advantage of any driver specific capabilities.

The driver isn't broken.

We've written an open source rate control algorithm that can take advantage of features our hardware has, that our users, testing, research, and development has shown to be advantageous in terms of solid performance, system overhead, power consumption, etc.

We want to be able to use that rate control algorithm with our driver.

nl80211/cfg80211 isn't broken. mac80211's inability to let the driver specify the rate control algorithm is. I proposed two solutions, both of which are simple, clean, and add zero complexity to the stack.

Below is the patch for changing the API. I can submit as a two part series (one to change the API, and the second to update all in-tree drivers to use it) if you'd rather. Simply exporting ieee80211_init_rate_ctrl_alg requires no API changes, but anyway...

James

[PATCH] mac80211: Add rate algorithm selection to ieee80211_register_hw

There may be a hardware specific rate control algorithm a driver wishes
to use. Currently, however, the stack assigns the first loaded algorithm to all drivers calling ieee80211_register_hw.

This commit simply adds an optional rate control algorithm name parameter to ieeee80211_register_hw.

---

include/net/mac80211.h   |    8 ++++++--
net/mac80211/ieee80211.c |    9 +++++----
2 files changed, 11 insertions(+), 6 deletions(-)

index ef9b613..5e30890 100644
@@ -750,8 +750,12 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
 

/* Register hardware device to the IEEE 802.11 code and kernel. Low-level
* drivers must call this function before using any other IEEE 802.11
- * function except ieee80211_register_hwmode. */
-int ieee80211_register_hw(struct ieee80211_hw *hw);
+ * function except ieee80211_register_hwmode. + *
+ * rc_name specifies the rate control algorithm name. If NULL the stack + * will assign a rate control algorithm based on the order in which the
+ * algorithms were registered with the stack. */
+int ieee80211_register_hw(struct ieee80211_hw *hw, const char *rc_name);

/* driver can use this and ieee80211_get_rx_led_name to get the
* name of the registered LEDs after ieee80211_register_hw

index 823a7ba..988a266 100644
@@ -4828,7 +4828,7 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,

}
EXPORT_SYMBOL(ieee80211_alloc_hw);

-int ieee80211_register_hw(struct ieee80211_hw *hw)
+int ieee80211_register_hw(struct ieee80211_hw *hw, const char *rc_name)

{
	struct ieee80211_local *local = hw_to_local(hw);
	const char *name;

@@ -4876,10 +4876,11 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)

	ieee80211_debugfs_add_netdev(IEEE80211_DEV_TO_SUB_IF(local->mdev));

- result = ieee80211_init_rate_ctrl_alg(local, NULL);

+	result = ieee80211_init_rate_ctrl_alg(local, rc_name);
	if (result < 0) {
-		printk(KERN_DEBUG "%s: Failed to initialize rate control "
-		       "algorithm\n", local->mdev->name);
+		printk(KERN_DEBUG "%s: Failed to initialize %s rate control "
+		       "algorithm\n", local->mdev->name, +			rc_name ? rc_name : "default");
		goto fail_rate;
	}

1.5.1.3

Why don't we just add a char *preferred_rate_control; to the hw definition structure instead? That way, we can even show it in sys/debugfs later so the user will still know what the driver preferred after changing it.

johannes

This would be my preference, too.

Jouni Malinen                                            PGP id EFC895FA

Please send your rate control algorithm first so we can know why are you requesting this. Without that, well, it's hard to decide.

Thanks,

Jiri

Jiri Benc
SUSE Labs

How's this?

[PATCH] mac80211: Add preferred_rate_control to ieee80211_hw

There may be a hardware specific rate control algorithm a driver wishes to use. Currently, however, the stack assigns the first loaded algorithm to all drivers calling ieee80211_register_hw.

This commit simply adds an preferred_rate_control to ieee80211_hw and updates ieee80211_register_hw to use it.

---
include/net/mac80211.h | 4 ++++
net/mac80211/ieee80211.c | 10 +++++++---

2 files changed, 11 insertions(+), 3 deletions(-)

index ef9b613..f9ad839 100644
@@ -533,6 +533,10 @@ struct ieee80211_hw {

	/* Number of available hardware TX queues for data packets.
	 * WMM requires at least four queues. */
	int queues;

+
+ /* Preferred rate control algorithm. Leave as NULL for stack
+ * to select algorithm */
+ char *preferred_rate_control;
};

static inline void SET_IEEE80211_DEV(struct ieee80211_hw *hw, struct device *dev)

index 873ccb0..6dcc002 100644
@@ -4875,10 +4875,14 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 

	ieee80211_debugfs_add_netdev(IEEE80211_DEV_TO_SUB_IF(local->mdev));

- result = ieee80211_init_rate_ctrl_alg(local, NULL);
+ result = ieee80211_init_rate_ctrl_alg(local, + hw->preferred_rate_control);
+

	if (result < 0) {

- printk(KERN_DEBUG "%s: Failed to initialize rate control "
- "algorithm\n", local->mdev->name);
+ printk(KERN_DEBUG "%s: Failed to initialize %s rate control "
+ "algorithm\n", local->mdev->name,

+		       hw->preferred_rate_control ? +		       hw->preferred_rate_control : "default");
		goto fail_rate;
	}

1.5.1.3

I told you the reason why I am requesting this. Do you think I'm lying or trying to trick you?

Generic algorithms aren't as capable as hardware specific algorithms when you factor performance, latency, system utilization, power consumption, etc. Optimal algorithms are written to take advantage of the capabilities exposed by the hardware.

The 3945, as an example, let's you configure the hardware with a set of rates, retries per rate, and a fallback order. You submit one Tx request to the hardware and it then performs all the retries, fallbacks, etc without host interaction over overhead. The rate control algorithm needs to be aware of the attempts made by the hardware. The specific mechanism by which the 3945 sets up those rates is device specific. The mechanism by which the results are reported back are device specific. The functions related to selecting the Tx rate are called twice for *EVERY PACKET*. Anything you can do to make that code-path faster and leaner for the specific device it is using is a win. Hardware specific beats generic.

Might other hardware devices also support some type of rate fallback or automatic retries? Maybe. Do they all do it the same way? No. Is it worth slowing down hot code paths in the name of "generic software"? Absolutely not.

James

PS. You're free to download the 3945 specific rate control algorithm if you want. It has been part of the GPL ipw3945 driver for over a year at http://ipw3945.sf.net. You can also find it refactored in iwlwifi at http://intellinuxgraphics.org.

I'm not convinced your request is reasonable. But as Jouni pointed out, there _could be_ some specific circumstances under which it could make sense. I'm not aware of any such circumstance now.

You said you have a code. Show it. I can assure you that if it turns out from the code that your request is valid, you will have no problems with your patch.

We're opensource. Please keep that in mind. If you need to prove something, send a code.

You said the same about hardware scanning. Michael showed you that's not true.

I don't see anything fundamentally different from other hardware.

Okay, show the code. Maybe we will be able to find a better way to deal with that.

They do.

That's valid for almost everything in the stack. Yet we have (and want to have) one stack and don't want each driver to implement its parts on their own.

If the slowdown is not big, yes, it is. Unifying things almost always means you need to accept some trade-offs.

Could you send just the rate control algorithm (or an excerpt of it) to this list so more people will look at it?

Thanks.

Jiri

Jiri Benc
SUSE Labs

The code is available why should it be paste it to the email.

Michael has shortened the dwell time on the channel, while hw scanning has shorten switching time from the channel to channel and no the time you are listening on the channel
I wouldn't call it an optimization. Did he measured the power consumption ?

The God is in the details

Clean API gives you the ability to enjoy from the both worlds. WiFi is about mobility power saving and therefore hw offloading is essential. What worth the few more lines of the code that gives you this ability this is also a trade-off.

This was going to be my question, and I think it is a worthy point. :-)

John

Agreed. FWIW, power saving is worthwhile even for fixed stations as well.

John

John W. Linville
[email protected]

The scan "power savings" in question are so small as to not be measurable. The stack is only involved at the time it changes the channel... a few tens of us of CPU time over the multiple seconds of scan action... and the scan action itself only happens at long intervals.

Is this really about commercial product differentiation? "Our hardware does faster 'hardware' scan" is good for Intel, even though the truth would more properly be expressed as "we took scan away from the open stack and put it in the closed source firmware binary blob where our implementation is a special modal thing that sooner or later will cause side effects, and there are space constraints and less of an OS API structure to lean on and the code is not reviewed". (I assume everyone who has used ipw3945 and even iwlwifi is familiar with MICROCODE ERROR and bad things arising from that.) And in the end as was pointed out beforehand, the scan implementation in the firmware is not measurably faster or more saving of power anyway.

(While I was writing this the 3945 on this box lost association, and when I tried to reinsert the driver modprobe stalled and I see permanent 100% CPU usage on both cores. That's a genuine low hanging fruit for "powersaving" on iwl3945/iwlwifi ;-) )

Sexy-sounding "hw offloading" is a very different thing to migrating off open code and putting it in vendor-specific closed source firmware. The firmware is just code like any other, for an embedded ARM7 or similar, except that it is customized for a specific vendor hardware implementation and you will never see the sources. What I understand is being talked about (maybe unlike the scan stuff this actually is in hardware, but I doubt it) is ignoring code in the stack and instead implementing pretty much the same code privately, to compile to a binary blob you can't see source for or even reverse according to its license.
That is a lot less romantic than mysterious hardware just waiting to be
used.

If we are far from the AP and only say 5.5Mbps rate packets get through, then there is presumably adaptation to that in the stack, it is not like it will sequence through 54Mbps -> 48Mbps -> ... 5.5Mbps each time, instead any effective rate limiting action will react to the situation by issuing mainly 5.5Mbps packets that get through first time and probing with faster packets occasionally to see if the situation was better. *Therefore any effective rate adaptation acts to limit any benefit that can come from tagging packets with rate lists in firmware as is proposed*. Put another way the meaning of rate limiting is to attempt to minimize effective airtime including the wasted restransmits at rates that never get through. So if there are excessive retransmits going on due to poor selection of tx rate for the circumstances (rather than interference) then isn't it better to address that in the stack so all devices can benefit from a smarter algorithm? (not least in recouping the wasted airtime and power used for TX that did not get through)

Collecting numbers on the retransmit probability per packet for different environments would be interesting anyway aside from all this, allowing objective metrics on rate management performance, but you would think it would be an important element of making the decision to pursue doing all the work to tag packets with rate lists in the firmware.

Anyone can propose anything and just slip the word patriot- er - powersaving in a few times. The true issue here is how much stuff that can and should be done in the open, shared stack are you willing to see in a vendor-specific binary blob (with support for the vendor-specific blobby APIs added to the stack) to get claimed advantages (eg, powersaving, scan speed) that aren't shown to hold water. I can imagine sometimes the benefits can be genuine and strong and you have to work with it, but the other times...

-Andy

OTOH, this is all vague, paranoid hand-waving since I'm guessing you don't know the internals of the Intel hardware.

We'll see what happens when Intel posts code to specify a different rate control algorithm.

Jeff

It's nice that you took the time to read and respond to my points in a way that moved the debate on. What is vague? There definitely is closed-source firmware for this product, you can download it yourself

http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-ucode-2.14.1.tgz

and read the license: and the code for it is produced as I describe above. As for the specific case of the rate list, James knows if that is firmware and I am sure he will tell us if it is genuine hardware support.

What will you see? You won't be seeing the firmware side of it except in binary.

-Andy

Because the development happens on this list and in wireless-dev git tree and not somewhere on sourceforge?

Thinking about it, I'd say it's time for Intel to stop hiding in the corner and send iwlwifi driver for a review and inclusion in wireless-dev. I think something like this could work:

1. send the driver (without all things that would require changing of the mac80211 stack) and ask for a review

2. when all comments are addressed, ask for inclusion in wireless-dev

3. send a patch that modifies/add a feature to mac80211 _together_ with a second patch that makes use of such feature in iwlwifi

4. repeat 3 for each new/modified feature you want in mac80211

Thanks,

Jiri

Jiri Benc
SUSE Labs

Looks good to me, requires no driver changes and adds useful functionality.

(What prompted me to think of this was the LED subsystem that allows you to specify default triggers for some LEDs)

johannes

What are you talking about? The question is about being able to select between rate control algorithms that could be _included in the kernel tree_.. How did that end up in binary blobs that I would assume you are using to refer to firmware?

Some hardware designs _do_ have features that allow rate control algorithm to be improved, i.e., there are differences in hardware between wlan chipset (what a surprise). This is not something that is "hidden" in firmware and anyway, it does not really matter whether this is in hardware or firmware. We are talking about providing additional values in TX/RX status fields and being able to do some rate adaptation operations on hardware TX retransmits, etc.

I have to admit I have not looked into details of the Intel's rate control algorithm, but I would assume it would be this rate control algorithm that is tagging different rate lists for packets, not the firmware. Interesting optimizations can be used here if the hardware/firmware is capable of changing the TX rate for the same packet between retries. This is one example of functionality that not all wlan hardware designs support.

What's your definition of "stack"? Aren't we talking about the driver being able to propose which of the N rate control algorithms _from the stack_ should be used with it by default?

Jouni Malinen                                            PGP id EFC895FA

Could I possibly be talking about this?

''The 3945, as an example, let's you configure the hardware with a set of rates, retries per rate, and a fallback order. You submit one Tx request to the hardware and it then performs all the retries, fallbacks, etc without host interaction over overhead. The rate control algorithm needs to be aware of the attempts made by the hardware. The specific mechanism by which the 3945 sets up those rates is device specific. The mechanism by which the results are reported back are device specific. The functions related to selecting the Tx rate are called twice for *EVERY PACKET*. Anything you can do to make that code-path faster and leaner for the specific device it is using is a win. Hardware specific beats generic.''

http://marc.info/?l=linux-wireless&m=117882282325836&w=2

You understand re-reading this that when he talks about "You submit one Tx request to the [']hardware['] and it then performs all the retries, fallbacks, etc without host interaction over overhead." this is stuff in the closed-source firmware? Aka "binary blob" with restrictive license?

Is it really true this is a feature of hardware and not closed-source firmware? Because if I was designing such a thing - and I have designed similarly complex silicon - damnned if I would allocate pure hardware to it. Since the device already has a concept of firmware, as we can all see, I would instead implement these multistage actions with the firmware. Which happens to be closed source by Intel's choice.

AIUI the proposal is to tag packets with lists of rates to retry at. But if the aimed-for and typical case is that you get through on the first try, how interesting is it really to migrate the retry action to a closed-source and per-vendor (or per-device) implementation instead of coming through the rate selection action in the stack.

Stack == mac80211. No: what James is talking about, as I quoted above, is a firmware implementation of "per-packet rate-list automatic retry" that requires special support in mac80211.

Let me ask: is it really so impossible to create a generic "nearly optimal" algorithm for rate selection in the stack that you have to offload the task to $DRIVER? What is it about the awesome software running in $DRIVER or $DEVICE that can do a better job than mac80211 ever can?

-Andy

So? I don't see what this has to do with mac80211 rate control algorithm selection. This is about 802.11 functionality that has very strict timing requirements (SIFS between frame and ack and then re-try if no ack received). That is (I would say, has to, in most cases) be done somewhere else than on the host CPU. In other words, this is something that really needs to be in the wlan hardware or firmware.

I do not know ipw3945 design, but I do know other wlan chipsets that do indeed take care of TX rate control between retries of the _same frame_ in hardware. No firmware involved there. Then again, I really do not follow this logic of firmware being some horrible thing that simply cannot be allowed to do anything. In this particular case, this really has to be done at the wlan chip, not at the host CPU due to timing requirements.

Being able to vary the TX rate on the SIFS-retries can produce huge improvements to rate adaption. I see this a very much valid reason for providing an alternative rate control algorithm that can take advantage of the hardware/firmware features.

I can only say that we see this quite differently and all I've seen from James so far on this topic makes sense and should be supported in mac80211. Firmware implementation does _not_ replace the mac80211 rate control algorithm, but modified mac80211 rate control algorithm can be used to improve rate adaption in this case and such modifications would not benefit (or be possible) with some other wlan chipsets. Thus, need for multiple mac80211 rate control algorithms and benefit from drivers being able to propose which one to use by default.

Yes, in practice, it is more or loess impossible with the timing requirements on 802.11 retries. This is not about driver vs. mac80211, this is about the timing differences between wlan chip vs. host CPU. I don't want to implement all rate control stuff in hardware/firmware, but the part that involves first couple of retransmission of frames that are not acked within SIFS really falls for the wlan hardware (including firmware, if used in the design) category, not host CPU, if aiming for the best possible rate control.

Jouni Malinen                                            PGP id EFC895FA