[PATCH] remove IEEE80211_HW_FRAGLIST flag

[PATCH] remove IEEE80211_HW_FRAGLIST flag

[Johannes Berg]

This patch removes the IEEE80211_HW_FRAGLIST flag as it is neither used
nor makes sense (since we never submit fragmented frames to the master
device.)

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
Looking through the hw flags I found this one. I can't see how it makes
sense at all, I don't see how a frame can end up being submitted in
fragments to the master device. So how about this patch?

Besides, should we ever want to submit fragmented frames we'll need to
test and verify that anyway so it makes more sense to add the flag back
when we do.

Please apply or otherwise tell me how the flag makes sense.

--- wireless-dev.orig/include/net/d80211.h	2007-02-15 20:49:00.554294167
+0100
+++ wireless-dev/include/net/d80211.h	2007-02-15 20:49:24.884294167 +0100
@@ -522,9 +522,7 @@ struct ieee80211_hw {
 	 * normal operation. */
 #define IEEE80211_HW_MONITOR_DURING_OPER (1<<9)
 
-	/* Set if the low-level driver supports skb fraglist (NETIF_F_FRAGLIST),
-	 * i.e. more than one skb per frame */
-#define IEEE80211_HW_FRAGLIST (1<<10)
+	/* please fill this gap when adding new flags */
 
 	/* calculate Michael MIC for an MSDU when doing hwcrypto */
 #define IEEE80211_HW_TKIP_INCLUDE_MMIC (1<<12)
--- wireless-dev.orig/net/d80211/ieee80211.c	2007-02-15 20:49:35.134294167 +0100
+++ wireless-dev/net/d80211/ieee80211.c	2007-02-15 20:49:40.414294167 +0100
@@ -4640,8 +4640,6 @@ int ieee80211_register_hw(struct ieee802
 	if (result < 0)
 		goto fail_sta_info;
 
-	if (hw->flags & IEEE80211_HW_FRAGLIST)
-		local->mdev->features |= NETIF_F_FRAGLIST;
 	rtnl_lock();
 	result = dev_alloc_name(local->mdev, local->mdev->name);
 	if (result < 0) {

Re: [PATCH] remove IEEE80211_HW_FRAGLIST flag

[Jouni Malinen]

On Thu, Feb 15, 2007 at 08:53:01PM +0100, Johannes Berg wrote:
> This patch removes the IEEE80211_HW_FRAGLIST flag as it is neither used
> nor makes sense (since we never submit fragmented frames to the master
> device.)

The reason for this flag was to reduce host CPU load for frame
aggregation (merging multiple frames (skb's) into one frame. It was used
to implement one part of Atheros Super A/G enhancements, but I don't see
those proprietary changes being generic enough to be worth adding into
net/d80211. However, IEEE 802.11n has similar features that may indeed
benefit from this flag. As such, I would not remove it.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH] remove IEEE80211_HW_FRAGLIST flag

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

On Fri, 2007-02-16 at 08:04 -0800, Jouni Malinen wrote:

> The reason for this flag was to reduce host CPU load for frame
> aggregation (merging multiple frames (skb's) into one frame. It was used
> to implement one part of Atheros Super A/G enhancements, but I don't see
> those proprietary changes being generic enough to be worth adding into
> net/d80211. However, IEEE 802.11n has similar features that may indeed
> benefit from this flag. As such, I would not remove it.

But we can never submit fragmented SKBs currently anyway, so whenever we
do any 802.11n changes that benefit from it we can add the flag back.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [PATCH] remove IEEE80211_HW_FRAGLIST flag

[Jiri Benc]

On Fri, 16 Feb 2007 17:07:49 +0100, Johannes Berg wrote:
> On Fri, 2007-02-16 at 08:04 -0800, Jouni Malinen wrote:
> 
> > The reason for this flag was to reduce host CPU load for frame
> > aggregation (merging multiple frames (skb's) into one frame. It was used
> > to implement one part of Atheros Super A/G enhancements, but I don't see
> > those proprietary changes being generic enough to be worth adding into
> > net/d80211. However, IEEE 802.11n has similar features that may indeed
> > benefit from this flag. As such, I would not remove it.
> 
> But we can never submit fragmented SKBs currently anyway, so whenever we
> do any 802.11n changes that benefit from it we can add the flag back.

I agree. Let's add the flag later when this is actually needed.

Applied, thanks for patch!

 Jiri

-- 
Jiri Benc
SUSE Labs