A-MPDU transmission in net80211 on FreeBSD 8

[Sam Leffler]

Alexander Egorenkov wrote:
> Why doesn't 802.11 stack assign sequence numbers to A-MPDU frames ?

Because if net80211 does the assignment it may be wrong.  As the comment 
says, if tx aggregation causes frames to be q'd above the h/w then by 
the time they are sent OTA the pre-assigned seq# may be invalidated by 
other frames going out ahead of it.

> When sequence numbers are not assigned to A-MPDU frames, then BA doesn't 
> work with my AP.
> I tried to assign sequence numbers to A-MPDU frames in my device driver 
> and then BAs worked
> with my AP.

That is what the comment says to do.

> And what is meant by aggregation queue ? Where is that queue anf how do 
> i use it ?

The aggregation q is the mechanism used to hold frames waiting for 
additional frames to aggregated into an A-MSDU/A-MPDU.  The queue is 
typically wherever the aggregation work is done.  Some devices do this 
in h/w, others require the host handle this.  When done in the host it 
can be done in the driver or above.  The intent has always been to have 
net80211 implement tx aggregation that a driver can fallback on but I 
never did the work.  All the 11n drivers I've done have either handled 
tx aggregation in h/w or in the driver.

> 
> Thanks.
> 
> On Sun, Jan 31, 2010 at 4:43 AM, Sam Leffler <sam at errno.com 
> <mailto:sam at errno.com>> wrote:
> 
>     Alexander Egorenkov wrote:
> 
>         Sorry, i posted the wrong comment.
>         Here is the comment which i don't understand:
> 
>         /*
>                     * NB: don't assign a sequence # to potential
>                     * aggregates; we expect this happens at the
>                     * point the frame comes off any aggregation q
>                     * as otherwise we may introduce holes in the
>                     * BA sequence space and/or make window accouting
>                     * more difficult.
>                     *
>                     * XXX may want to control this with a driver
>                     * capability; this may also change when we pull
>                     * aggregation up into net80211
>          */
> 
>         Thanks.
> 
> 
>     What is unclear?
> 
>            Sam
> 
> 
> 
>         On Wed, Jan 27, 2010 at 8:04 PM, Alexander Egorenkov <
>         egorenar at googlemail.com <mailto:egorenar at googlemail.com>> wrote:
> 
>             Hi,
> 
>             i'm implementing a device driver for a 802.11n NIC under
>             FreeBSD 8
>             und experimented with A-MPDU transmission. I looked into
>             net80211 code
>             and there is some code which implements this feature but it
>             worked not very
>             well for me.
>             I noticed e.g. that sequence numbers are not assigned to
>             A-MPDU frames
>             and found this comment in file ieee80211_output.c :
> 
> 
>             /*
>                     * Check if A-MPDU tx aggregation is setup or if we
>                     * should try to enable it.  The sta must be associated
>                     * with HT and A-MPDU enabled for use.  When the policy
>                     * routine decides we should enable A-MPDU we issue an
>                     * ADDBA request and wait for a reply.  The frame being
>                     * encapsulated will go out w/o using A-MPDU, or possibly
>                     * it might be collected by the driver and
>             held/retransmit.
>                     * The default ic_ampdu_enable routine handles staggering
>                     * ADDBA requests in case the receiver NAK's us or we are
>                     * otherwise unable to establish a BA stream.
>              */
> 
>             Can somebody elaborate this description to me please.
> 
>             Thanks.
> 
>             ALex.
> 
> 
>         _______________________________________________
>         freebsd-net at freebsd.org <mailto:freebsd-net at freebsd.org> mailing
>         list
>         http://lists.freebsd.org/mailman/listinfo/freebsd-net
>         To unsubscribe, send any mail to
>         "freebsd-net-unsubscribe at freebsd.org
>         <mailto:freebsd-net-unsubscribe at freebsd.org>"
> 
> 
> 
>