linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH] rtl8187: do not report ACKs if USB Tx status is non-zero
@ 2008-10-07 19:18 John W. Linville
  2008-10-08 18:42 ` John W. Linville
  0 siblings, 1 reply; 5+ messages in thread
From: John W. Linville @ 2008-10-07 19:18 UTC (permalink / raw)
  To: linux-wireless; +Cc: John W. Linville

The vendor-supplied driver treats a USB Tx failure as an un-ACKed frame.
I don't see why we shouldn't do the same thing -- hopefully this makes
rate-scaling algorithms behave sanely with the rtl8187 driver.

Thanks to Felix Fietkau <nbd@openwrt.org> for suggesting this as an
option.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
This is currently untested -- anyone with rtl8187 bored enough to try
it? :-)

 drivers/net/wireless/rtl8187_dev.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/rtl8187_dev.c b/drivers/net/wireless/rtl8187_dev.c
index ca5deb6..ae21191 100644
--- a/drivers/net/wireless/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl8187_dev.c
@@ -164,7 +164,12 @@ static void rtl8187_tx_cb(struct urb *urb)
 	skb_pull(skb, priv->is_rtl8187b ? sizeof(struct rtl8187b_tx_hdr) :
 					  sizeof(struct rtl8187_tx_hdr));
 	memset(&info->status, 0, sizeof(info->status));
-	info->flags |= IEEE80211_TX_STAT_ACK;
+	if (!(info->flags & IEEE80211_TX_CTL_NO_ACK)) {
+		if (!urb->status)
+			info->flags |= IEEE80211_TX_STAT_ACK;
+		else /* assume ACK not received */
+			info->status.excessive_retries = 1;
+	}
 	ieee80211_tx_status_irqsafe(hw, skb);
 }
 
-- 
1.5.4.3


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [RFC PATCH] rtl8187: do not report ACKs if USB Tx status is non-zero
  2008-10-07 19:18 [RFC PATCH] rtl8187: do not report ACKs if USB Tx status is non-zero John W. Linville
@ 2008-10-08 18:42 ` John W. Linville
  2008-10-08 19:38   ` Stefanik Gábor
  2008-10-08 22:48   ` Herton Ronaldo Krzesinski
  0 siblings, 2 replies; 5+ messages in thread
From: John W. Linville @ 2008-10-08 18:42 UTC (permalink / raw)
  To: linux-wireless

On Tue, Oct 07, 2008 at 03:18:18PM -0400, John W. Linville wrote:
> The vendor-supplied driver treats a USB Tx failure as an un-ACKed frame.
> I don't see why we shouldn't do the same thing -- hopefully this makes
> rate-scaling algorithms behave sanely with the rtl8187 driver.
> 
> Thanks to Felix Fietkau <nbd@openwrt.org> for suggesting this as an
> option.
> 
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> This is currently untested -- anyone with rtl8187 bored enough to try
> it? :-)
 
AFAICT, this doesn't actually trigger -- at least, the device can
go into its typical failure mode (no frames ACKed until you force a
lower rate) without ever hitting the "assume ACK not received" clause.

I'll keep looking at it -- there are a couple of 'secrets' still
buried in the vendor driver (if I can stomach to keep looking at it)...

John
-- 
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC PATCH] rtl8187: do not report ACKs if USB Tx status is non-zero
  2008-10-08 18:42 ` John W. Linville
@ 2008-10-08 19:38   ` Stefanik Gábor
  2008-10-08 20:02     ` John W. Linville
  2008-10-08 22:48   ` Herton Ronaldo Krzesinski
  1 sibling, 1 reply; 5+ messages in thread
From: Stefanik Gábor @ 2008-10-08 19:38 UTC (permalink / raw)
  To: John W. Linville; +Cc: linux-wireless

On Wed, Oct 8, 2008 at 8:42 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, Oct 07, 2008 at 03:18:18PM -0400, John W. Linville wrote:
>> The vendor-supplied driver treats a USB Tx failure as an un-ACKed frame.
>> I don't see why we shouldn't do the same thing -- hopefully this makes
>> rate-scaling algorithms behave sanely with the rtl8187 driver.
>>
>> Thanks to Felix Fietkau <nbd@openwrt.org> for suggesting this as an
>> option.
>>
>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>> ---
>> This is currently untested -- anyone with rtl8187 bored enough to try
>> it? :-)
>
> AFAICT, this doesn't actually trigger -- at least, the device can
> go into its typical failure mode (no frames ACKed until you force a
> lower rate) without ever hitting the "assume ACK not received" clause.
>
> I'll keep looking at it -- there are a couple of 'secrets' still
> buried in the vendor driver (if I can stomach to keep looking at it)...
>
> John
> --
> John W. Linville                Linux should be at the core
> linville@tuxdriver.com                  of your literate lifestyle.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Another weird thing: the code above essentially attempts to do this:
Wait for an ACK
If not TX_CTL_NO_ACK:
   If acked:
      Report the packet as acked.
   Endif
   If no ACK until timeout:
      Report packet as unacked
   Endif
Endif

This would be better, as it doesn't waste time waiting for an ACK for
unacked frames:

If not TX_CTL_NO_ACK:
Wait for an ACK
   If acked:
      Report the packet as acked.
   Endif
   If no ACK until timeout:
      Report packet as unacked
   Endif
Endif

Of course, this only works if "Wait for an ACK" actually works.

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC PATCH] rtl8187: do not report ACKs if USB Tx status is non-zero
  2008-10-08 19:38   ` Stefanik Gábor
@ 2008-10-08 20:02     ` John W. Linville
  0 siblings, 0 replies; 5+ messages in thread
From: John W. Linville @ 2008-10-08 20:02 UTC (permalink / raw)
  To: Stefanik Gábor; +Cc: linux-wireless

On Wed, Oct 08, 2008 at 09:38:49PM +0200, Stefanik G=E1bor wrote:

> Another weird thing: the code above essentially attempts to do this:
> Wait for an ACK
> If not TX_CTL_NO_ACK:
>    If acked:
>       Report the packet as acked.
>    Endif
>    If no ACK until timeout:
>       Report packet as unacked
>    Endif
> Endif
>=20
> This would be better, as it doesn't waste time waiting for an ACK for
> unacked frames:
>=20
> If not TX_CTL_NO_ACK:
> Wait for an ACK
>    If acked:
>       Report the packet as acked.
>    Endif
>    If no ACK until timeout:
>       Report packet as unacked
>    Endif
> Endif
>=20
> Of course, this only works if "Wait for an ACK" actually works.

Well as I understand it, the only waiting is related to the URB
submission (which is asynchronous anyway).  I don't really see how
we could avoid it.

John
--=20
John W. Linville		Linux should be at the core
linville@tuxdriver.com			of your literate lifestyle.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC PATCH] rtl8187: do not report ACKs if USB Tx status is non-zero
  2008-10-08 18:42 ` John W. Linville
  2008-10-08 19:38   ` Stefanik Gábor
@ 2008-10-08 22:48   ` Herton Ronaldo Krzesinski
  1 sibling, 0 replies; 5+ messages in thread
From: Herton Ronaldo Krzesinski @ 2008-10-08 22:48 UTC (permalink / raw)
  To: John W. Linville; +Cc: linux-wireless

On Wednesday 08 October 2008 15:42:05 John W. Linville wrote:
> On Tue, Oct 07, 2008 at 03:18:18PM -0400, John W. Linville wrote:
> > The vendor-supplied driver treats a USB Tx failure as an un-ACKed frame.
> > I don't see why we shouldn't do the same thing -- hopefully this makes
> > rate-scaling algorithms behave sanely with the rtl8187 driver.
> >
> > Thanks to Felix Fietkau <nbd@openwrt.org> for suggesting this as an
> > option.
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > This is currently untested -- anyone with rtl8187 bored enough to try
> > it? :-)
>
> AFAICT, this doesn't actually trigger -- at least, the device can
> go into its typical failure mode (no frames ACKed until you force a
> lower rate) without ever hitting the "assume ACK not received" clause.

I tested here and it didn't trigger indeed, here at least urb->status == 0 
always no matter what I tried, which seems normal, only would trigger at some 
not typical usb failure? But there is one thing that I like about the patch, 
seems correct that we shouldn't set IEEE80211_TX_STAT_ACK if 
IEEE80211_TX_CTL_NO_ACK, that is, looks like a bug always setting ack in the 
flags when no_ack is present, not sure if it has some effect in practice 
though (have to look more at the code that cares about info->flags). I would 
say that the patch 'as is' is correct and will not hurt.

>
> I'll keep looking at it -- there are a couple of 'secrets' still
> buried in the vendor driver (if I can stomach to keep looking at it)...

yeah, not very straightforward to grasp the vendor driver unfortunately... 
good would be to have some times docs/explanation about some of the values 
used, when you're luck there is some comments and references at some places.

>
> John

--
[]'s
Herton

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-10-08 22:48 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-07 19:18 [RFC PATCH] rtl8187: do not report ACKs if USB Tx status is non-zero John W. Linville
2008-10-08 18:42 ` John W. Linville
2008-10-08 19:38   ` Stefanik Gábor
2008-10-08 20:02     ` John W. Linville
2008-10-08 22:48   ` Herton Ronaldo Krzesinski

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).