Return-path: Received: from s3.sipsolutions.net ([5.9.151.49]:38212 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752601AbbBXKZA (ORCPT ); Tue, 24 Feb 2015 05:25:00 -0500 Message-ID: <1424773495.2192.23.camel@sipsolutions.net> (sfid-20150224_112513_283616_0F65D43B) Subject: Re: Throughput regression with `tcp: refine TSO autosizing` From: Johannes Berg To: Michal Kazior Cc: Eric Dumazet , Neal Cardwell , linux-wireless , Network Development , Eyal Perry Date: Tue, 24 Feb 2015 11:24:55 +0100 In-Reply-To: (sfid-20150212_084824_976893_36D95ADD) 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> (sfid-20150212_084824_976893_36D95ADD) Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Thu, 2015-02-12 at 08:48 +0100, Michal Kazior wrote: > > 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 > 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). Couldn't we just repurpose the existing skb->tstamp field for this, as long as the skb is fully contained within the wireless layer? Actually, it looks like we can't, since I guess timestamping options can be turned on on any socket. > 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? I have no doubt that would be rejected :) johannes