From owner-freebsd-net@freebsd.org Thu Sep 3 14:11:32 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB1DE9C9B89 for ; Thu, 3 Sep 2015 14:11:32 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 893631C3D for ; Thu, 3 Sep 2015 14:11:32 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 862A29C9B88; Thu, 3 Sep 2015 14:11:32 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85C459C9B87 for ; Thu, 3 Sep 2015 14:11:32 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D0641C3C; Thu, 3 Sep 2015 14:11:32 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by wibz8 with SMTP id z8so100496781wib.1; Thu, 03 Sep 2015 07:11:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:cc:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=CqRLcYZMgES5BX9I92noyYk8ghnMFFHCLl6p56UGtL4=; b=IfOQsvDgBN4HNnX3peUuAFI1TdCYQ1s3EBhAvuBVkzZP/9JjDFbmvPc3DcNHxnrMuO VWATxoHLShU30a2NqrlfVOJGLKJX1aJFJA7ugd7nrtLTPOH5BRA2rP+WXAIZU6UsHglp 0PBJtFIGfIxbiwJSYQZjgB0BzoHMxbm6wWm5fnxp0fBioQiknGjwPMrD80rbfahcm9/W DwDXly72Mxz/3N+D2XJeZWLDpxroqgxN6pc2kMeEfiNQbyStWqMXPDqX1G6NyreFB4Si lVeeyCHNp0jbjDOI4mlChFmE+62MMzBcj44ytF7oLMdS1U8gAFqUOkDtXhFYzB3aY9AJ vZaQ== X-Received: by 10.194.110.132 with SMTP id ia4mr51540073wjb.103.1441289490419; Thu, 03 Sep 2015 07:11:30 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by smtp.gmail.com with ESMTPSA id ej5sm38010495wjd.22.2015.09.03.07.11.29 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 03 Sep 2015 07:11:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Gleb Smirnoff" Cc: "Lawrence Stewart" , "Adrian Chadd" , "net@freebsd.org" Subject: Re: mbufq-less iwn(4) References: <20150901112043.GB1023@glebius.int.ru> <20150902060324.GF1023@glebius.int.ru> Date: Thu, 03 Sep 2015 17:11:27 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: <20150902060324.GF1023@glebius.int.ru> User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 14:11:32 -0000 > Adrian, > > On Tue, Sep 01, 2015 at 12:33:53PM -0700, Adrian Chadd wrote: > A> We have to do mbuf queues in drivers for wifi, because of 11n > A> aggregation. So on one hand we want to have if_transmit() apply > A> backpressure through the stack, but there's also going to be some > A> buffering. :P > > No, that's not because of 11n aggregation. That's a remnant of > ifnet ifqueue. Note that I'm speaking about queueing in drivers, > not in net80211 stack. Look at the iwn patch, it doesn't remove > any functionality except of enqueueing and dequeueing. > > Look at your own ath(4) - there is no software queue there already :) > > A> I'd like to see that for ic_transmit(). > A> > A> Other thing - ic_transmit() also needs to handle fragments, like I do > A> with ath. Ie, handing it a list of packets is actually a list of > A> 802.11 fragments, rather than separate MPDUs. > A> > A> Another thing - we're modifying the mbufs (adding 802.11 data to it) > A> before we pass them to the driver, and if the driver fails to > A> transmit, we can't just pass it back up the net80211 stack to the tcp > A> or udp layer.. > > Sure, stack probably would need to strip the data. Anyway, that's > a future task. > What about https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193569 ?