A-MPDU transmission in net80211 on FreeBSD 8

[Alexander Egorenkov]

Hi,

thanks for your help, I implemented A-MPDU Tx in my Ralink driver now and it
works very good.
I have average Tx rate about 4.5~5 MBytes/s now :-) The Ralink chip that i
have implements the frame queue in hardware so i had only to assign sequence
numbers, set BA window size and MPDU density and it worked, lucky me :-)

Alex.

On Sun, Jan 31, 2010 at 8:20 PM, Sam Leffler <sam at errno.com> wrote:

> 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>"
>>
>>
>>
>>
>>
>