[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200612122135.13466.flamingice@sourmilk.net>
Date: Tue, 12 Dec 2006 21:35:08 -0500
From: Michael Wu <flamingice@...rmilk.net>
To: Ulrich Kunitz <kune@...ne-taler.de>
Cc: Daniel Drake <dsd@...too.org>,
John Linville <linville@...driver.com>, netdev@...r.kernel.org
Subject: Re: d80211-drivers pull request (week-48)
On Tuesday 12 December 2006 18:39, Ulrich Kunitz wrote:
> Just two observations:
>
> 1) The retry-failed-interrupt message contains the destination
> MAC address of the transmitted message.
Hm, that might be useful to check in master or adhoc mode to make sure the tx
queue isn't messed up.
> 2) We could get easily two acks for the same transmission.
How would this occur?
> 3) We could get ACKs or retry-failed-interrupts for packets, for
> which no status has been requested by the upper layers.
>
We report status for every frame which will get an ACK, which is every unicast
frame. Coincidentally, d80211 uses the same logic to determine when it wants
the status to be reported (IIRC).
> I suggest that the skbs as buffer for the URB transmissions.
Yes, copying the entire frame to another buffer isn't very performance
friendly. This was one of the things that bothered me when I ported zd1211rw.
> We could add a timeout value to each
> packet to make sure, that we don't ACK or NAK packets, which have
> been overdue.
Some sort of watchdog to kick things when things stall could be useful, though
I'm not sure how to go about it.
-Michael Wu
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists