Date: Mon, 25 Mar 2013 23:01:28 -0700 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Subject: Re: [wip] ar9300 hostap support Message-ID: <CAJ-VmomtQFjiGZRR0ME3HvGaJjHfXq%2BRT6a699UUDqGnJM1zjw@mail.gmail.com> In-Reply-To: <CAJ-Vmo=4QRuYeG8LmEfntTB2W5OyfsnVDCz5cJ__zWYbXkme3w@mail.gmail.com> References: <CAJ-Vmo=4QRuYeG8LmEfntTB2W5OyfsnVDCz5cJ__zWYbXkme3w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Here's an update against the most recent -HEAD: http://people.freebsd.org/~adrian/ath/20130326-cabq-edma-tx-rework-5.diff I've done some more basic interoperability with the station devices I have hiding around here. There's been no real issues thus far. I've committed some of the shared work (mostly to do with cabq/multicast queue) code to -HEAD already. It may affect both the pre-AR9380 and AR9380 series NICs. I'd appreciate it if people updated to -HEAD anyway and tested it out. Thanks! Adrian On 25 March 2013 16:13, Adrian Chadd <adrian@freebsd.org> wrote: > Hi, > > I've been working on AR9380 HAL hostap support in my spare time. > > Here's where I'm at so far: > > http://people.freebsd.org/~adrian/ath/20130325-cabq-edma-txq-rework-3.diff > > Now, this is not likely what I'm going to push into -HEAD. But it's > being stable for me for now, save some odd crashes that have been > reported with TX completion on the AR9380 chips. > > Now, what's going on and what I have to stage into -HEAD: > > * The whole descriptor linking thing is just plain wrong for the > AR9380 chips. I have to nuke axq_link from orbit and use > ath_hal_settxdesclink(). This requires some manual fiddling of things > in a variety of places in both the pre-AR9380 chips and the AR9380 > chips - it's used for CABQ assembly, for beacon programming, for > general unicast traffic programming ... eek. > > * The CABQ assembly code needed to be tweaked for EDMA. Now I have to > populate the whole list of CABQ frames (with the correct link pointers > as listed above) before I can push that list into the hardware FIFO. > > * I need to separate out the FIFO contents from the pending TX queue > in each hardware TXQ. Right now my EDMA TX code just pushes individual > MPDU or AMPDU frames into the FIFO and then waits until the FIFO > empties before pushing more frames in. I'm now changing it so there's > a separate "what's in the FIFO" queue, so.. > > * .. I can properly support the whole CABQ method of "these frames are > in the FIFO", because the CABQ support requires pushing multiple > frames (linked with the link pointer) into a single FIFO entry, .. and > > * .. if I want to support restarting that queue during a stuck beacon > or other recoverable reset, I need to know where my FIFO frame > boundaries are. > > Now, ath9k does it a bit differently - it has a split queue setup, but > the FIFO queue is a list of queues. I don't yet want to refactor > everything that way, so I'm just marking the start/end of each frame > list with ath_buf flags (ATH_BUF_FIFOPTR for the beginning and > ATH_BUF_FIFOEND for the last buffer in a list) and then making sure I > handle those right. > > Now, this seems to work - in both encrypted (CCMP/TKIP) and open mode. > I'm not getting the high throughput I expect though - it looks like > I'm transmitting far too many single frames at the moment, rather than > being (more) aggressive at aggregation. I'll worry about that later. > This includes testing with stations in sleep mode (ie, traffic going > into the CABQ.) > > Now, what's left? > > * I have to finish converting over the axq_link references to > ath_hal_settxdesclink(), and kill axq_link as a concept. > * I need to figure out why we're seeing that panic with the AR9380 TX > completion FIFO saying that something is free on Q1 when the Q1 FIFO > is empty. > * I need to mark intermediary buffers in a buffer list with > ATH_BUF_BUSY, so they go onto the holdingbf queue. Otherwise the DMA > engine may hang (and this is a problem in ath9k too! Go go gadget code > review!) > * Lots, lots more testing. > > I'd really like to figure out why the aggregation isn't as aggressive > as it could be. I'll dig into that later. I should be seeing ~ > 250-280mbit TCP throughput on 3x3 HT40; but now I'm seeing ~150mbit > (ie, what I see with 2x2 HT/40.) That's obviously wrong. I'm seeing > very reliable MCS23 transmission and reception so it isn't that. It > seems to be something odd with how aggregates are being formed and > said aggregation logic seeming to transmit more single frames than > aggregate frames. Sigh. > > Anyway. If you want to test it out, the patch above applies cleanly to > -HEAD and you _do_ need to update to the latest git HAL or encryption > just plain won't work.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomtQFjiGZRR0ME3HvGaJjHfXq%2BRT6a699UUDqGnJM1zjw>