Return-path: Received: from mail-ob0-f178.google.com ([209.85.214.178]:36494 "EHLO mail-ob0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751846AbbBLIdy convert rfc822-to-8bit (ORCPT ); Thu, 12 Feb 2015 03:33:54 -0500 MIME-Version: 1.0 In-Reply-To: References: <1422537297.21689.15.camel@edumazet-glaptop2.roam.corp.google.com> <1422628835.21689.95.camel@edumazet-glaptop2.roam.corp.google.com> <1422903136.21689.114.camel@edumazet-glaptop2.roam.corp.google.com> <1422926330.21689.138.camel@edumazet-glaptop2.roam.corp.google.com> <1422973660.907.10.camel@edumazet-glaptop2.roam.corp.google.com> <1423051045.907.108.camel@edumazet-glaptop2.roam.corp.google.com> <1423053531.907.115.camel@edumazet-glaptop2.roam.corp.google.com> <1423055810.907.125.camel@edumazet-glaptop2.roam.corp.google.com> <1423056591.907.130.camel@edumazet-glaptop2.roam.corp.google.com> <1423084303.31870.15.camel@edumazet-glaptop2.roam.corp.google.com> <1423141038.31870.38.camel@edumazet-glaptop2.roam.corp.google.com> <1423142342.31870.49.camel@edumazet-glaptop2.roam.corp.google.com> <1423147286.31870.59.camel@edumazet-glaptop2.roam.corp.google.com> <1423156205.31870.86.camel@edumazet-glaptop2.roam.corp.google.com> <1423230001.31870.128.camel@edumazet-glaptop2.roam.corp.google.com> <1423230785.31870.131.camel@edumazet-glaptop2.roam.corp.google.com> <1423494690.31870.189.camel@edumazet-glaptop2.roam.corp.google.com> <1423577962.2215.2.camel@sipsolutions.net> Date: Thu, 12 Feb 2015 00:33:53 -0800 Message-ID: (sfid-20150212_093431_634938_5C234663) Subject: Re: Throughput regression with `tcp: refine TSO autosizing` From: Dave Taht To: Michal Kazior Cc: Johannes Berg , Eric Dumazet , Neal Cardwell , linux-wireless , Network Development , Eyal Perry Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Wed, Feb 11, 2015 at 11:48 PM, Michal Kazior wrote: > On 11 February 2015 at 09:57, Michal Kazior wrote: >> On 10 February 2015 at 15:19, Johannes Berg wrote: >>> On Tue, 2015-02-10 at 11:33 +0100, Michal Kazior wrote: >>> >>>> + if (msdu->sk) { >>>> + ewma_add(&ar->tx_delay_us, >>>> + ktime_to_ns(ktime_sub(ktime_get(), skb_cb->stamp)) / >>>> + NSEC_PER_USEC); >>>> + >>>> + ACCESS_ONCE(msdu->sk->sk_tx_completion_delay_cushion) = >>>> + (ewma_read(&ar->tx_delay_us) * >>>> + msdu->sk->sk_pacing_rate) >> 20; >>>> + } >>> >>> To some extent, every wifi driver is going to have this problem. Perhaps >>> we should do this in mac80211? >> >> Good point. I was actually thinking about it. I can try cooking a >> patch unless you want to do it yourself :-) > > I've taken a look into this. The most obvious place to add the > timestamp for each packet would be ieee80211_tx_info (i.e. the > skb->cb[48]). The problem is it's very tight there. Even squeezing 2 > bytes (allowing up to 64ms of tx completion delay which I'm worried I will argue strongly in favor of never allowing more than 4ms packets to accumulate in the firmware. > won't be enough) will be troublesome. Some drivers already use every > last byte of their allowance on 64bit archs (e.g. ar5523 uses entire > 40 bytes of driver_data). > > I wonder if it's okay to bump skb->cb to 56 bytes to avoid the cascade > of changes required to implement the tx completion delay accounting? > > > Michał > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks