All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivo van Doorn <ivdoorn@gmail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Alexandre Becholey <alexandre@shockfish.com>,
	linux-wireless@vger.kernel.org
Subject: Re: IEEE80211 Acknowledgement
Date: Mon, 4 May 2009 18:35:34 +0200	[thread overview]
Message-ID: <200905041835.35104.IvDoorn@gmail.com> (raw)
In-Reply-To: <1241451174.8683.48.camel@johannes.local>

On Monday 04 May 2009, Johannes Berg wrote:
> On Mon, 2009-05-04 at 17:29 +0200, Ivo van Doorn wrote:
> > Hi,
> > 
> > Just as side information for other readers:
> > 
> > Alexandre is looking into the problem of rt2500usb/rt73usb and
> > possibly other USB drivers, that they cannot report the ACK status
> > of frames to mac80211 which is problematic for hostapd.
> 
> I realise that this probably doesn't help and is tangential to the
> question being asked, but I do not think processing ACK frames in
> software is possible for this, since the software does not know which
> frame was transmitted, due to four queues being used, and retries etc.

Well I believe the idea would be that (I'll see if I can dig up a reference
to the initial discussion about this feature on this list) the driver sets a flag
that mac80211 needs to keep a list of all frames send out to the driver and
listens for ACK's.

As soon as a ACK was passed from driver to mac80211 it could check if
the corresponding frame was in the list and remove the frame from the list
and generate a tx_status response indicating success.
Off course all frames must be checked for the timeout value as well to see
if the frame wasn't send (in which case the tx_status event is send as well).

There shouldn't be a problem with multi-queue with this if the list of frames
is put onto a single list instead of one list per queue.
As for the retries and other statistics, do we honestly care?
At the moment rt2500usb/rt73usb indicate the frame has not been acked
and set the retry value to 1. If we somehow can tell if the frame was send out
or not, isn't that a step forward already? The retry value is needed for the
rate algorithm, but it is receiving the same incorrect value now as well, so it wouldn't
be a step backward in that perspective. ;)

Ivo

  reply	other threads:[~2009-05-04 16:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-04 15:16 IEEE80211 Acknowledgement Alexandre Becholey
2009-05-04 15:29 ` Ivo van Doorn
2009-05-04 15:32   ` Johannes Berg
2009-05-04 16:35     ` Ivo van Doorn [this message]
2009-05-04 16:39       ` Johannes Berg
2009-05-04 16:55         ` Ivo van Doorn
2009-05-04 17:02           ` Johannes Berg
2009-05-04 17:05             ` Ivo van Doorn
2009-05-05  7:44               ` Alexandre Becholey
2009-05-05  8:34                 ` Ivo van Doorn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200905041835.35104.IvDoorn@gmail.com \
    --to=ivdoorn@gmail.com \
    --cc=alexandre@shockfish.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.