From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 D2F583B2AE for ; Wed, 30 Mar 2016 06:04:28 -0400 (EDT) Received: by mail-wm0-x230.google.com with SMTP id p65so175379217wmp.1 for ; Wed, 30 Mar 2016 03:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=p1SyFjQcI0TAemW5b49Zi+tfkdoCkSssBMf5MNWXS+o=; b=dKaQLxLsZpcn58aIZ6iJ9OrLLs8IqtO7Tmn3D3HO0lOrLXyNq7GDzBNmUuzfIfEI3q TfowNmeSK//e4hqn9ulbpi98Lfgc+DrEvB+/wN6F5B0EiE5rUbuFK5tMJYD54BULxmDP boCHLW8rcEFI1S4Lq+WX2l+ZKXQ+vSLPJExnI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=p1SyFjQcI0TAemW5b49Zi+tfkdoCkSssBMf5MNWXS+o=; b=cDw+Y5JHy7v3RWQ5HForHUwJhnCp3skU40deOuIi3hZJoCDww3XwddqShcG/rK2ItR zXiPGFLR8guin+vjG9B83keeE6Q2XoCyei3oVXpFEo84G/Q8ycqUicI87O8gqtcXENbt dUD+AHDTEKG2yJTLR20Y1qGS4gCEXYw0x+Yj22hkRX91SrskynsiHSbM3IPYBrN/D5W3 PehugrKYrBEq93tsw9E7orHM4VjiWE2YFxNMgDTT0HW7VvTvpWYlGlYm1KdE2ehXfwWR sMUKu6+8MNVKFCVLLrZZsrYNTbcLduzy3O7AFdJgTrfXb72TD2SVQAv+t5WTRh6c7l6X cbRA== X-Gm-Message-State: AD7BkJJk0hh9FZG7PO20ewpob7kZMgjQVQiajltadMXF6CyLn1i9JP/fuuVZgoKZpGppa2cdLYQ9cD8hnU4+ZBf31O6KCpYeSkqT6t4BkPxeg+NAhuFLug0XsGsyDM7MH/a2F0Z0F/PkFjcbCOAC28zDMA== MIME-Version: 1.0 X-Received: by 10.28.130.6 with SMTP id e6mr9041576wmd.71.1459332267944; Wed, 30 Mar 2016 03:04:27 -0700 (PDT) Received: by 10.194.115.3 with HTTP; Wed, 30 Mar 2016 03:04:27 -0700 (PDT) In-Reply-To: References: <1458898743-21118-1-git-send-email-michal.kazior@tieto.com> Date: Wed, 30 Mar 2016 12:04:27 +0200 Message-ID: From: Michal Kazior To: Dave Taht Cc: "ath10k@lists.infradead.org" , linux-wireless , make-wifi-fast@lists.bufferbloat.net, "codel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Subject: Re: [Codel] [RFC] ath10k: implement dql for htt tx X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 10:04:29 -0000 On 30 March 2016 at 02:57, Dave Taht wrote: > As a side note of wifi ideas complementary to codel, please see: > > http://blog.cerowrt.org/post/selective_unprotect/ > > On Tue, Mar 29, 2016 at 12:49 AM, Michal Kazior = wrote: [...] >> On the other hand DQL will react also to host system interrupt service >> time. On slow CPUs (typically found on routers and such) you might end >> up grinding the CPU so much you need deeper tx queues to keep the hw >> busy (and therefore keep performance maxed). DQL should automatically >> adjust to that while "txop limit" might not. > > Mmmm.... current multi-core generation arm routers should be fast enough. While this helps it doesn't mean you can magically un-serialize interrupt/txrx completion work. [...] >>>> To sum things up: >>>> - DQL might be able to replace the explicit txop queue limiting >>>> (which requires rate control info) >>> >>> I am pessimistic. Perhaps as a fallback? >> >> At first I was (too) considering DQL as a nice fallback but the more I >> think about the more it makes sense to use it as the main source of >> deriving time slices for tx scheduling. > > I don't really get how dql can be applied per station in it's current for= rm. I was thinking of the following scheme: - disable excessive retries in fw (apparently doable via WMI pdev paramete= r) - deficit-based round-robin over stations - maintain DQL structure per station - when station gets its turn to xmit push frames to fw - keep doing that (with regard to per station DQL limits) until either: - associated software queue becomes empty - 1 timeslice for given station has elapsed - i was thinking of extracting timeslices from DQL or maintaining it separately - try next station - do not submit packets to multiple stations at once (MU will need more work..), i.e. always drain tx completely before switching to next station - each station may need a different timeslice (to squeeze out max burst performance) [...] >>>> PS. I'm not feeling comfortable attaching 1MB attachment to a mailing >>>> list. Is this okay or should I use something else next time? >>> >>> I/you can slam results into the github blogcerowrt repo and then pull >>> out stuff selectively.... >> >> Good idea, thanks! > > You got commit privs. Yep, thanks! Micha=C5=82