From owner-freebsd-net@FreeBSD.ORG Mon Oct 29 17:52:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 92F6038B; Mon, 29 Oct 2012 17:52:56 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 301E68FC16; Mon, 29 Oct 2012 17:52:55 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id wc20so6299209obb.13 for ; Mon, 29 Oct 2012 10:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=H6UIu1viDS7/ULG8ZXlWQYGpRnJK290lXLYbkhIhJJw=; b=pgxAVRoi8mMswUhDDitkFBC8cJMJgCBkiTooDANVOc68XzFNvclBgSdSeOpxno76zH oMnjV43biBi1XyydD9HefofuufDcrM6hV5M69tym0HwjxTl5bvTx9w6IeSSgQ+r7uRrH 2gcZ13vYa9hXeFn9ZfE041NNed15redRKFncMFYTeZZM4/gfr0St4Awb6IL8HnUcRzWa ECJe0YYHdwJGt8mAfgHYGBAspHKMc6FS109gj/4bC4HHjE6qVRKGjK3FQbdb1k8H/NxN 44OWerHwkz7xsWOPmI7jvPcCJiJrGsz8ksP90Zmac/hHdgRT8GG56xX/2FkXIZ5StCEL hqig== MIME-Version: 1.0 Received: by 10.182.69.50 with SMTP id b18mr25300096obu.75.1351533175595; Mon, 29 Oct 2012 10:52:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.76.27.65 with HTTP; Mon, 29 Oct 2012 10:52:55 -0700 (PDT) In-Reply-To: References: <508E50A3.1030008@networx.ch> Date: Mon, 29 Oct 2012 10:52:55 -0700 X-Google-Sender-Auth: XduIE-ahB3kfGazWrAdsRRvCLU0 Message-ID: Subject: Re: request for help: 'fixing' the 802.11 TX path From: Adrian Chadd To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , freebsd-wireless@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 17:52:56 -0000 The problem with this is that fragments need to be handed as an entire list to the driver. ath(4) looks ahead to the next fragment, calculates the rate, and then adds that to the NAV of the previous frame. So yeah what I'm thinking about for now is something like the following: * say that wifi drivers have to move to if_transmit(); * "abuse" if_transmit() semantics to assume a m_nextpkt chain of mbufs is a fragment list for a single frame; * for now, figure out why the hell the ath(4) TX taskqueue setup is providing crappy throughput and fix _that_; * then migrate the net80211 TX to a taskqueue; * .. and then just undo the ath(4) TX taskqueue since now TX is serialised by if_transmit() inside the net80211 TX taskqueue. There are other things to do, mostly surrounding fixing up the power save queue handling to repopulate the queue packet-by-packet, rather than doing if_snd gymnastics. Once that's done, we can look at ways to implement serialisation besides just using a taskqueue - eg, using the running/not-running flag idea you've suggested. The big problem here is that once TX completion occurs, drivers kick off new TX. Now, if all TX is triggered by a frame TX, the TX will stall until the next frame is attempted. What we'd have to do is tell the drivers how to 'kick' the net80211 stack TX again. Adrian