From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 5F5F63B25E for ; Wed, 10 Aug 2016 11:41:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Filter: OpenDKIM Filter v2.10.3 mail2.tohojo.dk E54AF40D5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1470843711; bh=zuxTf/8QYL+XpCx+Mvs5PgsnUFbFwCTBpOqKQAXdu0Q=; h=In-Reply-To:References:Subject:From:Date:To:CC:From; b=drdXJfzVx12NnZq6dCDHensteFlZARjH+cTQVQkJ6kvGw10YNGLk4JQwA0GTHP4kW 6oNTvN0PaopVkH21x80n+wHR0n4OelAWnfGnS688HPRTYDta4+YQ/8RDTgPRdNce1R 1XwQr77jO10bPRSmePppZGriTjVaqHvlkf1dDMUw= In-Reply-To: References: <8760r8bwxm.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= Date: Wed, 10 Aug 2016 17:41:50 +0200 To: Michal Kazior CC: make-wifi-fast@lists.bufferbloat.net X-Clacks-Overhead: GNU Terry Pratchett Message-ID: Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] Carrying the CoDel timestamp into the driver 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: Wed, 10 Aug 2016 15:41:54 -0000 On 10 August 2016 17:27:16 CEST, Michal Kazior = wrote: >On 10 August 2016 at 15:00, Toke H=C3=B8iland-J=C3=B8rgensen >wrote: >> Hi Michal >> >> In your mac80211 FQ-CoDel patch, you put the CoDel timestamp into a >> union with the vif pointer in struct ieee80211_tx_info. This means >the >> timestamp is not available in the driver. I'm experimenting with some >> changes where having the enqueue time available would be useful. >> >> Do you have any good ideas as to where else we could store the >enqueue >> time somewhere the driver can retrieve it? > >I did explore this idea for different purposes though - to maintain >per-packet expected_duration. I think it should be in the >linux-wireless archives. It compacted band, ack_frame_id I think but >you get limited number of *bits*. > >.. or you could remove the rate control stuff from tx_info and convert >all drivers to use mac80211 API to fetch it per-station on-demand only >I guess.. Right. Guess I'll put that on the "things to look into" list. Exactly why is it we can't just grow tx_info by a couple of bytes? -Toke