Re: [PATCH][RFC] softmac: suggest TX rate

2006-04-17 Thread Daniel Drake

Johannes Berg wrote:

Couldn't we just initialise the softmac txrates substructure to
something useful when associating, and have drivers look into that
instead?


How about this?
It also addresses the fact that multicast data must be transmitted at a 
basic rate.


--- linux/include/net/ieee80211softmac.h.orig   2006-04-16 23:37:32.0 
+0100
+++ linux/include/net/ieee80211softmac.h2006-04-17 18:40:04.0 
+0100
@@ -86,6 +86,9 @@ struct ieee80211softmac_assoc_info {

/* BSSID we're trying to associate to */
char bssid[ETH_ALEN];
+
+   /* Rates supported by the network */
+   struct ieee80211softmac_ratesinfo supported_rates;

/* some flags.
 * static_essid is valid if the essid is constant,
@@ -133,12 +136,23 @@ struct ieee80211softmac_txrates {
 * (If the device supports fallback and hardware-retry)
 */
u8 mcast_fallback;
+
+   /* The Bit-Rate to be used for multicast management frames. */
+   u8 mgt_mcast_rate;
+   /* The Bit-Rate to be used for multicast management fallback
+* (If the device supports fallback and hardware-retry)
+*/
+   u8 mgt_mcast_fallback;
+
/* The Bit-Rate to be used for any other (normal) data packet. */
u8 default_rate;
/* The Bit-Rate to be used for default fallback
 * (If the device supports fallback and hardware-retry)
 */
u8 default_fallback;
+
+   /* This is the rate that the user asked for */
+   u8 user_rate;
 };
 
 /* Bits for txrates_change callback. */
@@ -146,6 +160,8 @@ struct ieee80211softmac_txrates {
 #define IEEE80211SOFTMAC_TXRATECHG_DEFAULT_FBACK   (1 << 1) /* 
default_fallback */
 #define IEEE80211SOFTMAC_TXRATECHG_MCAST   (1 << 2) /* mcast_rate 
*/
 #define IEEE80211SOFTMAC_TXRATECHG_MCAST_FBACK (1 << 3) /* 
mcast_fallback */
+#define IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST   (1 << 4) /* 
mgt_mcast_rate */
+#define IEEE80211SOFTMAC_TXRATECHG_MGT_MCAST_FBACK (1 << 5) /* 
mgt_mcast_fallback */
 
 struct ieee80211softmac_device {
/* 802.11 structure for data stuff */
@@ -246,6 +262,28 @@ extern void ieee80211softmac_fragment_lo
  * Note that the rates need to be sorted. */
 extern void ieee80211softmac_set_rates(struct net_device *dev, u8 count, u8 
*rates);
 
+/* Helper function which advises you the rate at which a frame should be
+ * transmitted at. */
+static inline u8 ieee80211softmac_suggest_txrate(struct 
ieee80211softmac_device *mac,
+int is_multicast,
+int is_mgt)
+{
+   struct ieee80211softmac_txrates *txrates = &mac->txrates;
+
+   if (!mac->associated)
+   return txrates->mgt_mcast_rate;
+
+   /* We are associated, sending unicast frame */
+   if (!is_multicast)
+   return txrates->default_rate;
+
+   /* We are associated, sending multicast frame */
+   if (is_mgt)
+   return txrates->mgt_mcast_rate;
+   else
+   return txrates->mcast_rate;
+}
+
 /* Start the SoftMAC. Call this after you initialized the device
  * and it is ready to run.
  */
--- linux/net/ieee80211/softmac/ieee80211softmac_module.c.orig  2006-04-17 
01:04:42.0 +0100
+++ linux/net/ieee80211/softmac/ieee80211softmac_module.c   2006-04-17 
18:30:04.0 +0100
@@ -26,6 +26,7 @@
 
 #include "ieee80211softmac_priv.h"
 #include 
+#include 
 
 struct net_device *alloc_ieee80211softmac(int sizeof_priv)
 {
@@ -166,15 +167,85 @@ static void ieee80211softmac_start_check
}
 }
 
-void ieee80211softmac_start(struct net_device *dev)
+int ieee80211softmac_ratesinfo_rate_supported(struct 
ieee80211softmac_ratesinfo *ri, u8 rate)
+{
+   int search;
+   u8 search_rate;
+
+   for (search = 0; search < ri->count; search++) {
+   search_rate = ri->rates[search];
+   search_rate &= ~IEEE80211_BASIC_RATE_MASK;
+   if (rate == search_rate)
+   return 1;
+   }
+
+   return 0;
+}
+
+/* Finds the highest rate which is:
+ *  1. Present in ri (optionally a basic rate)
+ *  2. Supported by the device
+ *  3. Less than or equal to the user-defined rate
+ */
+static u8 highest_supported_rate(struct ieee80211softmac_device *mac,
+   struct ieee80211softmac_ratesinfo *ri, int basic_only)
+{
+   u8 user_rate = mac->txrates.user_rate;
+   int i;
+   
+   if (ri->count == 0) {
+   dprintk(KERN_ERROR PFX "empty ratesinfo?\n");
+   return IEEE80211_CCK_RATE_1MB;
+   }
+
+   for (i = ri->count - 1; i >= 0; i--) {
+   u8 rate = ri->rates[i];
+   if (basic_only && !(rate & IEEE80211_BASIC_RATE_MASK))
+   continue;
+   rate &= ~IEEE80211_BASIC_RATE_MASK;
+   if (rate > user_rate)
+   continue;
+  

Re: [PATCH][RFC] softmac: suggest TX rate

2006-04-17 Thread Johannes Berg
On Mon, 2006-04-17 at 01:28 +0100, Daniel Drake wrote:

> Rather than having to explicitly call ieee80211softmac_suggest_tx_rate() 
> from the driver's hard_start_xmit function, it would be nicer if the 
> suggested rate was passed as a parameter. But not all drivers would need 
> it, so maybe the extra calculations should be controlled by a new flag.

Couldn't we just initialise the softmac txrates substructure to
something useful when associating, and have drivers look into that
instead?

> + case IEEE80211_FTYPE_DATA:
> + if (unlikely(!mac->associated)) {
> + dprintkl(KERN_ERROR PFX "suggest_tx_rate: Not 
> associated\n");
> + return IEEE80211_CCK_RATE_1MB;
> + }
> + return suggest_rate_from_associnfo(mac);

This isn't correct. Here, you have to take into account multicast frames
because those require clamping the rate to the highest rate from the
basic rateset.

I'll try to come up with an alternative.

johannes


signature.asc
Description: This is a digitally signed message part


Re: [PATCH][RFC] softmac: suggest TX rate

2006-04-16 Thread Daniel Drake

Ulrich Kunitz wrote:

I just wanted to say, I agree with the approach, but wonder how
transmission timeouts come into play here, which should lead to a
decrease of the tranmission rate. 


That's a separate issue, to do with rate management, which I'm not 
tackling yet. Note that the functions in my patch can easily be extended 
to bring rate management into the equation.


Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH][RFC] softmac: suggest TX rate

2006-04-16 Thread Ulrich Kunitz
On Mon, 17 Apr 2006, Ulrich Kunitz wrote:

Oops! Sorry, but sometime ^X and ^C are to near to each other.

I just wanted to say, I agree with the approach, but wonder how
transmission timeouts come into play here, which should lead to a
decrease of the tranmission rate. 

Daniel the patches on branch softmac-suggest-txrate look good!

Regards,

Uli

-- 
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH][RFC] softmac: suggest TX rate

2006-04-16 Thread Ulrich Kunitz
On Mon, 17 Apr 2006, Daniel Drake wrote:

> While developing the ZD1211 driver we realised how much we'd like to be
> advised from the upper layers which rate to transmit a packet at.
> 
> An example: We have a frame to transmit. What rate should we transmit it at?
> While taking any user-specified rate into account too, we want to transmit it
> at a rate supported by the access point, but that information is not available
> to us (softmac handled all scanning and association, so we don't know anything
> about the AP capabilities).
> 
> Here is a patch I cooked up, which implements some basic logic for suggesting
> TX rates based on the packet type, whether it is multicast/unicast, whether we
> are associated, and the current user-specified default_rate.
> 
> I'm still uncertain where this functionality should fit into the stack.
> 
> Rather than having to explicitly call ieee80211softmac_suggest_tx_rate() from
> the driver's hard_start_xmit function, it would be nicer if the suggested rate
> was passed as a parameter. But not all drivers would need it, so maybe the
> extra calculations should be controlled by a new flag.
> 
> Passing an extra parameter to hard_start_xmit would involve modifying
> ieee80211, and ieee80211 doesn't seem to have any concept of whether it is
> associated or not (plus softmac only does that loosely). So that might lead us
> on to do something silly like wrapping hard_start_xmit inside softmac, etc
> etc...
> 
> Note that even in it's current form, this patch eliminates an annoying (and
> inaccurate) chunk of code from our driver.
> 
> Ideas/comments?
> 

-- 
Ulrich Kunitz - [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html