From owner-freebsd-wireless@FreeBSD.ORG Tue Mar 26 20:10:09 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EF69A66B for ; Tue, 26 Mar 2013 20:10:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 92062B4F for ; Tue, 26 Mar 2013 20:10:09 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id ez12so1531076wid.12 for ; Tue, 26 Mar 2013 13:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=ga1xXajtlPFb/ZEr2Xr//8VHT+piylVXssxx60rV19Q=; b=ki2kdPh8VjHrugoc04qCW+HDXmlXzpkAP7wiYSePTCrIeg33yheydso7zxpHXw/5nr zFWKG56B6XPNuUDAvLOSeIiS5YsdNHRhpB9XFsX5To6338/LJPc+NmiMC1DhbHB7YVkT Q9JgXMTmCE/Q3RlsFgirVhkmuBgkoeitAZYw9cNofvBXWZK6slkaOCy6DlRZ1gMos1or P+bPoqt6abnJTOMrvp/eUOhBE/3G5z5/Nvuv/nIvf6r48k1VU/eYqMcS5f+dfMUtuvCi rwvPjM7aADYqO/WscSwQY8TavbHsiG58iXHGTekzEh67KfvqO+3ShEMKS7P+i+vRoknK kbCA== MIME-Version: 1.0 X-Received: by 10.180.189.205 with SMTP id gk13mr5501551wic.25.1364328608874; Tue, 26 Mar 2013 13:10:08 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Tue, 26 Mar 2013 13:10:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Mar 2013 13:10:08 -0700 X-Google-Sender-Auth: 0yfeGNHNhHMj9xm6sxf-cJCpgZc Message-ID: Subject: Re: [wip] ar9300 hostap support From: Adrian Chadd To: freebsd-wireless@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 20:10:10 -0000 .. and it's all now in -HEAD. Please update to -HEAD before you test out the AR9380 support. Joshua - I've also put in a work around to stop things crashing on an empty tx queue. It'll just log a warning. I'm going to add some further debugging code to ensure that frames going into a TXQ actually _have_ the right queue ID set in the descriptor. It's quite possible that I've screwed this up somewhere. Thanks, Adrian On 25 March 2013 23:01, Adrian Chadd wrote: > 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 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.