From owner-freebsd-wireless@FreeBSD.ORG Tue Mar 26 06:01:30 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 47983BE for ; Tue, 26 Mar 2013 06:01:30 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id D8799D3C for ; Tue, 26 Mar 2013 06:01:29 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id d7so561559wer.40 for ; Mon, 25 Mar 2013 23:01:29 -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=U7scILB9FLRLDKgivWs3ggUtoZ1ACs+DEs9yVUzI140=; b=q/u94nPIcntO2gDdrxEA6JOuHGPpisipC7Uf6aNvCxRdml/+SlVQ0u6DuhvOW/5NyU ogc/POLt3juf6WZkZsxkJG36uMS5CtbJc83pdbVwH7csvpmQCO+NQ+K8EDZ5xqwWJ+Nf LazaXD9edBD4FMpX73cdytx2W2asMfEdfCmq2qRzSWoHDoEHml2eny5uRIllodGkfIxL MBaGHd5OOU0f8OSOpmKKDbUzNScf4Rw499u/1cRODQL3sNmTJrQAtJImP6FfBXJa9eIU pYj77Np+WXWNUF6y3avKnrkIDldAPSvfJ5KfGFhb6Hbq0UBdgBDZlg1n5o8qT97QIG2N K83A== MIME-Version: 1.0 X-Received: by 10.194.171.74 with SMTP id as10mr22246925wjc.0.1364277688923; Mon, 25 Mar 2013 23:01:28 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 25 Mar 2013 23:01:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 23:01:28 -0700 X-Google-Sender-Auth: sdDAofmkoL5dGEV5GKe--v_n34g 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 06:01:30 -0000 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.