From owner-freebsd-wireless@FreeBSD.ORG Thu Feb 28 23:35:34 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 D0DE9DFD for ; Thu, 28 Feb 2013 23:35:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC2C956 for ; Thu, 28 Feb 2013 23:35:33 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id fm10so1994572wgb.9 for ; Thu, 28 Feb 2013 15:35:33 -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=ZnVtT+9dEHUmDEKHcUgfrlmsVAUoT1C5LGKVHT/xuWk=; b=s4HGNeJW3Vl5NiEojuBp7kcLeRQXTyByfKOMFZRKHUhbucMgxIVv5GHNF6UYeXQ72u XCSmLFQXqHWCyUGonhSFoXj+M/EN0nTWi/VQynlNN7MBMrSg1sLAUTPbN0BWA/l8KJcY ymjx2ESxzbSw1qXlOEpJ4gHhGCOykzRRdzPWL0urbRzjCmw8LhaS6Gq9TRxz8r7GJ/+N cqpXpkhQTE8++so5cKrBXP1Xjac0qy6Nu+NnKAwveg4NqkKFRVMTDiqVds90zJE5y1aI cii7zdwcgnmV+8amfU8kDB8i9hXlZ/vUZpi6DR6VPVccc37Y1/TS/E0vZNBoB8KmkXwJ /V9g== MIME-Version: 1.0 X-Received: by 10.180.73.238 with SMTP id o14mr616358wiv.32.1362094533020; Thu, 28 Feb 2013 15:35:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Thu, 28 Feb 2013 15:35:32 -0800 (PST) In-Reply-To: References: Date: Thu, 28 Feb 2013 15:35:32 -0800 X-Google-Sender-Auth: qI2xwgv3oysixWn7r2xCzxQGeUY Message-ID: Subject: Re: [RFT] net80211 TX serialisation, take #4 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: Thu, 28 Feb 2013 23:35:34 -0000 Hi, Right - but then I still need to hold long held locks here across the net80211 _and_ the driver. Ie: * net80211 needs to hold a lock for the entire process of dequeuing a frame and running it to completion. It can't do this: * grab lock * dequeue frame * release lock --> here things race * grab net80211 lock * run with frame * release net80211 lock So you have to hold _some_ lock for the entire length of time you're processing that frame: * grab queue lock * dequeue frame * grab net80211 lock * process frame * release net80211 lock * release queue lock Same deal goes with the driver. That's the unfortunate side effect of having multiple stack and driver transmit paths all wanting to service the same queue. So either you have these long held locks but you can do fully inline, direct-dispatch transmit; or you use taskqueues and just serialise everything through the taskqueue. Adrian