* [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).