Search Linux Wireless

Re: [RFC][PATCH] TX status reporting with help of an ack queue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2008-09-15 at 21:00 +0200, Mattias Nissler wrote:
> On Mon, 2008-09-15 at 20:03 +0200, Johannes Berg wrote:
> > > 2. Make the ACK queue approach generic and wrap it in some library
> > > functions that become part of mac80211 and are called from the driver's
> > > tx and rx handlers, respectively. This has the advantage that it is less
> > > invasive than 1. It is essentially what Ivo has described above. Driver
> > > writers would be free to use this framework, but are not required to do
> > > so.
> > 
> > I think this is what we want.
I also like this approach. It gives us the flexibility to add driver
specific code to the driver while keeping the mac80211 part clean even
if some driver needs additional packet handling hacks.

> Ok. If we take this path I think we do not need to add more flags to
> mac80211 and the drivers that enable special processing w.r.t. the
> device packet filters (as suggested by Ivo previously). Instead, the
> driver itself should take whatever action is necessary to tell the
> hardware to deliver ACK frames. Johannes, could you recap for me
> whether the driver should report these additional ACKs to mac80211 or
> keep quiet if they weren't requested?
> 
> > > > > This doesn't use timers so a message might in theory be
> > > > > stuck in the queue indefinitely.
> > > > 
> > > > Well you wouldn't need timers actually, if you have a list of packets
> > > > waiting to be acked you can expect the frames to be acked in the order
> > > > of which they were send (when using the same queue).
> > 
> > Yes, hence you have to keep track of things per queue.
> 
> Good point :-) So I suggest we have one function that adds new packets
> to the ACK queue (which is represented by a struct an instance of which
> a driver can keep in its queue information) and another one that matches
> a received ACK with the queue, reports the status to mac80211 and purges
> the queue entries up to the match (reporting them as failed).
> 
> Mikko: I could hack this up, but since your initial patch is not far
> from what's been discussed, I rather wait for a comment on whether you
> want to do it.
> 
> Mattias
> 

Feel free to hack up a patch. The functions 
rt2x00lib_get_match_from_ack_queue and rt2x00lib_push_to_ack_queue are
already generic handlers for the queue. 

>From the messages on this list it seems people want to also add the part
of sending the packet to the mac80211 layer to these two functions. This
is certainly possible but it needs to be done in such a way that the
driver can keep its internal statistics up to date. Since I'm not at all
familiar with what information a driver might want to extract, I opted
to leave the packet forwarding out of the generic functions.

Mikko
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux