From owner-freebsd-wireless@FreeBSD.ORG Sat Feb 16 23:46:59 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 BE951633 for ; Sat, 16 Feb 2013 23:46:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5BB32D1 for ; Sat, 16 Feb 2013 23:46:59 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so3757031wgb.29 for ; Sat, 16 Feb 2013 15:46:51 -0800 (PST) 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:cc:content-type; bh=E5Nh0vbv5QPbkRU9WaecuAU+yqcbJ1IMIqSchHvTbfc=; b=OQbhRtmNmlqufpWcq2Bb/SMdyRz7I0pZGYPLFVJ04gDBwBGbSV1xVbsD79IwOemjj6 5NZ6VJ5ji4vzh1jenKDSGZTCLCSE21YNQjJyI0a1s5RuyYqkFMNlfhJHRw3eYLYMk/C0 MCCPWLDQWdSOnEOa74raWIDKZdbCfirbm3zfkR3l4IMyMeWp9uYzDerE0XdnX9cAXA+h DTltdAXbPF+NdPP7y4N/kCoE0/TueYaUf0tx51q3KIukYrz5BPpLwRl3DRjRyT8qAcl7 p4UfJMlti9MhwQd02Vda5tEBKNR3AekiGM0Wm3wi2EoY3J9Ic1D6rdWNOOV++pN5xEER cw6w== MIME-Version: 1.0 X-Received: by 10.194.7.136 with SMTP id j8mr11377143wja.38.1361058411891; Sat, 16 Feb 2013 15:46:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Sat, 16 Feb 2013 15:46:51 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Feb 2013 15:46:51 -0800 X-Google-Sender-Auth: onvk25m0KpF17Oe82m5R8OAGeco Message-ID: Subject: Re: [RFC] serialising net80211 TX From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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: Sat, 16 Feb 2013 23:46:59 -0000 Hi, Here's the patch: * break out the per-packet send code into ieee80211_start_pkt() * introduce a per-vap TX lock * wrap the normal TX path ieee80211_encap(), parent->if_transmit and ic->ic_raw_xmit with the TX lock TODO: * the rest of the encap calls need to be wrapped in the TX lock - wds, superg, mesh. * the TX lock is not re-entrant but the TX path itself is (eg start -> start aggregation -> addba send -> mgmt_send -> (re) grab lock) so a bunch of this stuff needs to be rethought to be "clean" locking wise. I bet wds, superg and mesh is being called from the normal TX path and thus could be called with the TX lock already held. I should investigate this! * the TX aggregation state code should be protected by a lock - do that later? * add some lock / unlock assertion checks (eg assert the TX lock is held in ieee80211_encap()) and debug what code paths are / aren't being engaged. I'm still testing this. I've only tested it in STA mode thus far (iwn and ath.) thanks, Adrian Adrian