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 19:05:44 +0200	[thread overview]
Message-ID: <200905041905.44646.IvDoorn@gmail.com> (raw)
In-Reply-To: <1241456546.8683.67.camel@johannes.local>

On Monday 04 May 2009, Johannes Berg wrote:
> On Mon, 2009-05-04 at 18:55 +0200, Ivo van Doorn wrote:
> > On Monday 04 May 2009, Johannes Berg wrote:
> > > On Mon, 2009-05-04 at 18:35 +0200, Ivo van Doorn wrote:
> > > 
> > > > 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 
> > >       ^^^^^^^^^^^^^^^^^^^
> > > 
> > > Here's the problem. What I'm saying is that there's no way to knowing
> > > what the "corresponding frame" is.
> > 
> > Hmm, so would there be any alternatives of fixing this problem?
> 
> The proper way of fixing this would be a firmware upgrade ;)
> 
> Working around it would be possible if the driver queued only a single
> frame to the hardware, when it knew the frame needed ACK status, and
> flushed all queues before that frame, so it knows exactly about the
> frame... This has HUGE overhead and performance impact though, and
> requires lots of work in mac80211 to not request status for every frame
> to start with.
> 
> Since this breaks hostapd operation quite significantly, and I don't see
> hostapd changing to accommodate this since that essentially breaks the
> ability to be spec compliant (I'm fairly certain some places require
> checking for ACK).
> 
> An easier way would be to fake a ACK reception in the driver for every
> frame...

Ok, well I'll go with this route then. Since firmware upgrades for
older hardware like rt73usb sounds very unlikely. And for rt2500usb
it is plain impossible (no firmware ;))

Alexandre: Well that seems to make your project a lot easier...

Ivo

  reply	other threads:[~2009-05-04 17:05 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
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 [this message]
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=200905041905.44646.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.