From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A9E713B25E for ; Tue, 10 May 2016 03:15:12 -0400 (EDT) Received: by mail-ig0-x22a.google.com with SMTP id bi2so125645228igb.0 for ; Tue, 10 May 2016 00:15:12 -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:message-id:subject :from:to:cc; bh=y54VGlV1QClCEtrPmcr1mhw5VCLhLUYbUp53l/nQ4Z8=; b=wKcvcEG1CIkgWixk3IOWoK0hVEUf5dcYISeK4SSBnF5aGZmY697Q7OjWta478Mn3wZ TJX64qMPkPxeZDBJvBZmgnbUctrAvGx2Y/Nal2jGBt6tv5XY4IbJ3/cpWSP0u3ShET6M Ivvh7yUjqRrrMl1Z2wvuQM/BmZ+LZvwPnM0zAU1yWVijfbsA5IuTObNOU5iZnpdsg9US CjpqTQcLaEs8s7Whqa9lfMQ9YoTvsZevY39sR3cdxsu3cL39Na2RqOHR7Hhzm4F2fD6i h4UVhNIbZuSCVfxz7yJ9OAKKMXtsK/8Jvsh7xxt/AVFCvqSkAbMxECHahW1B0CWW8tgB x0nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=y54VGlV1QClCEtrPmcr1mhw5VCLhLUYbUp53l/nQ4Z8=; b=R9LaXZrf4QF0dxsi9NnIkIjh2s/AO6kyfCasYQS0teKNH14qBgPFVrvSUmZgFaGzcz TpvdyASyR/DEwzDa+jGdJVvML+D2sdd3xGn1VK/RDnWH/2Mfxgs/RvijMfvSJfr44CDL 94Dj+XWzWcz4ZIT5RU52DdS0aaPeF8BjWtsGMCugjIZHCijvUbQJDVMEl1lmqj0AYED5 aM0FbXQSj+ltBa71YIMEPBPH5fqU7UwWuIxrkTjX7+DO30dUdVzEupqRs5v4rm+j7GOm A+Xij/GEDzwNdmG15QD3kTfI5yyvJVi3yVXTB2q09wVwiss2WEACJQKFSGVHtjrXyjK6 cNKg== X-Gm-Message-State: AOPr4FUVgps59HDrTtrk3Jz2X3HP+IKq1CmWESAxA7SSReKDLTZxZrVASdOVjbazMfldtlmaYHT21nKo/DO6kw== MIME-Version: 1.0 X-Received: by 10.50.3.73 with SMTP id a9mr14818015iga.22.1462864512052; Tue, 10 May 2016 00:15:12 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.113.3 with HTTP; Tue, 10 May 2016 00:15:11 -0700 (PDT) In-Reply-To: References: <871t5bpkc7.fsf@toke.dk> <6ADC1A9D-72C9-47A5-BDC7-94C14ED34379@gmail.com> Date: Tue, 10 May 2016 00:15:11 -0700 X-Google-Sender-Auth: 0lQtzqy8KCQBer_OCKAn-LWmC3Y Message-ID: From: Adrian Chadd To: Dave Taht Cc: Jonathan Morton , make-wifi-fast@lists.bufferbloat.net, "ath9k-devel@lists.ath9k.org" , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: text/plain; charset=UTF-8 Subject: Re: [Make-wifi-fast] [ath9k-devel] Diagram of the ath9k TX path X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 07:15:12 -0000 Well, there shouldn't /also/ be a software queue behind each TXQ at that point. Eg, in FreeBSD, I queue up to 64 frames per station and then default to round robining between stations when it's time to form another aggregate. It's done that way so i or someone else can implement a wifi queue discipline in between the per-station / per-TID queues and the hardware queue that knew about time of flight, etc. The variations on the internal driver tended to slide some more complicated queue management and rate control between the bit that dequeued from the per-TID/per-STA packet queue and formed aggregates. Ie, the aggregate was only formed at hardware queue time, and only two were pushed into the hardware at once. There were only deep hardware queues in very old, pre-11n drivers, to minimise CPU overhead. So yeah, do reduce that a bit. The hardware queue should be two frames, there shouldn't be anything needed to be queued up behind it in the software queue backing it if you're aggregating, and if you /are/, that queue should be backed based on flight time (eg lots of little frames, or one big aggregate, but not lots of big aggregates.) Yeah, I also have to add NOACK support for A-MPDU in the freebsd driver for various reasons (voice, yes, but also multicast A-MPDU.) You just need to ensure that you slide along the BAW in a way that flushes the sender, or you may drop some frames but you're in the BAW, and then the receiver buffers them for up to their timeout value (typically tens of milliseconds) waiting for more frames in the BAW (hopefully retries). I dunno if you're really allowed to be sending NOACK data frames if you've negotiated immediate blockack though! And yeah for time? totally depends on what you're doing. Yes, if you have lots of stations actively doing traffic, then yes you should just form smaller aggregates. It's especially good for dealing with the full frame retries (ie, RTS/CTS worked, but the data frame didn't, and you didn't get a block-ack at all.) On longer aggregates, that can /really/ hurt - ie, you're likely better off doing one full retry only and then failing it so you can requeue it in software and break it up into a smaller set of aggregates after the rate control code gets the update. (God, I should really do this all to freebsd now that I'm kinda allowed to again..) -adrian