From owner-freebsd-wireless@FreeBSD.ORG Fri Feb 22 23:25:43 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 73AE69B3 for ; Fri, 22 Feb 2013 23:25:43 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 047BA1B1 for ; Fri, 22 Feb 2013 23:25:42 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hi18so1349524wib.15 for ; Fri, 22 Feb 2013 15:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=qxtwEYq1kfw/V+3/UH1cREO4/H0iB+mLCVehsvQUH18=; b=jiHo9Oi8IKYMWeajtznGIP1FDJWX4RBXV/FGgFuu1xiGiiP5B/vZDMywU3+BzvXrzS u1Y/zlBcb4xRQ5y8a0q/A4WvqggB+5LiYL+Ex5UV6JxzUx0WuRly+qLxRzuuOyLM8O5N TXguR8Nluq0I/as2//RHJaRLDjGXawETXF7pz7RLEiLEZLDIe/EeH+CTWcWVVTvoKP8q BqncKeu83dM1xq8KJYgKOBIB+kLhV7bTa17PlBqKKNDwKyp38AX9kt8QcibudlEXpzzR FRw9XlsuflyRQ3kXG5QkGaVHtEh6DzXFU+adRI01JWP6M7zHNG0h491FlhFbbgAvj5CC yXSg== MIME-Version: 1.0 X-Received: by 10.194.5.137 with SMTP id s9mr5556057wjs.5.1361575536259; Fri, 22 Feb 2013 15:25:36 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.74.194 with HTTP; Fri, 22 Feb 2013 15:25:36 -0800 (PST) Date: Fri, 22 Feb 2013 15:25:36 -0800 X-Google-Sender-Auth: ROdRJ-LhQEDGLOK-wzzzvrMefQ8 Message-ID: Subject: [RFT] net80211 TX serialisation, take #4 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: Fri, 22 Feb 2013 23:25:43 -0000 Hi, Here's take four of the TX serialisation. http://people.freebsd.org/~adrian/ath/20130223-net80211-tx-lock-4.diff This patch increases the lock "reach" so it locks the encap path for both data and management frames, so the path between sequence number allocation and driver queuing is held. There are some drivers that directly access ni_txseqs[] (ie, iwn and ath) and I'll have to think about this a little more. Sometimes it'll be called with the VAP TX lock held (ie, if it's called from driver if_transmit / driver if_start / ic_raw_xmit) but sometimes the TX path is called from the addba response callback, the TX completion methods, a software frame taskqueue. None of these grab the VAP TX lock at any point. I'd like to avoid making the VAP TX lock a reentrant lock (ew.) I'm open to ideas/suggestions. Thanks, Adrian