From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <johannes@sipsolutions.net>
Received: from sipsolutions.net (s3.sipsolutions.net [5.9.151.49])
 (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 E07703B2D2;
 Tue, 19 Apr 2016 05:06:34 -0400 (EDT)
Received: by sipsolutions.net with esmtpsa
 (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87)
 (envelope-from <johannes@sipsolutions.net>)
 id 1asRc6-0002Qc-52; Tue, 19 Apr 2016 11:06:30 +0200
Message-ID: <1461056788.2766.13.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
To: Michal Kazior <michal.kazior@tieto.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>, Dave Taht
 <dave.taht@gmail.com>, make-wifi-fast@lists.bufferbloat.net, 
 codel@lists.bufferbloat.net, Avery Pennarun <apenwarr@gmail.com>
Date: Tue, 19 Apr 2016 11:06:28 +0200
In-Reply-To: <CA+BoTQkQrUyihsk9MMMGY3XXGD+RqwziLwe+jKsKTG5q=StuAg@mail.gmail.com>
 (sfid-20160418_143823_205581_D0138FB9)
References: <1459420104-31554-1-git-send-email-michal.kazior@tieto.com>
 <1460636302-31161-1-git-send-email-michal.kazior@tieto.com>
 <1460636302-31161-5-git-send-email-michal.kazior@tieto.com>
 <1460845772.2075.31.camel@sipsolutions.net>
 <CA+BoTQkHAOhwFh5grveGCH5tfsxOT=BXAx2qgF1c=GcT7SrSQw@mail.gmail.com>
 <CA+BoTQkQrUyihsk9MMMGY3XXGD+RqwziLwe+jKsKTG5q=StuAg@mail.gmail.com>
 (sfid-20160418_143823_205581_D0138FB9)
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.18.5.1-1 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [Make-wifi-fast] [PATCHv3 4/5] mac80211: implement codel on
	fair queuing flows
X-BeenThere: make-wifi-fast@lists.bufferbloat.net
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: <make-wifi-fast.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/make-wifi-fast>,
 <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/make-wifi-fast>
List-Post: <mailto:make-wifi-fast@lists.bufferbloat.net>
List-Help: <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/make-wifi-fast>,
 <mailto:make-wifi-fast-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2016 09:06:35 -0000

On Mon, 2016-04-18 at 14:38 +0200, Michal Kazior wrote:
> On 18 April 2016 at 07:31, Michal Kazior <michal.kazior@tieto.com>
> wrote:
> > 
> > On 17 April 2016 at 00:29, Johannes Berg <johannes@sipsolutions.net
> > > wrote:
> > > 
> > > On Thu, 2016-04-14 at 14:18 +0200, Michal Kazior wrote:
> > > > 
> > > > 
> > > > +                             struct ieee80211_vif *vif;
> > > > +
> > > > +                             /* When packets are enqueued on
> > > > txq
> > > > it's easy
> > > > +                              * to re-construct the vif
> > > > pointer.
> > > > There's no
> > > > +                              * more space in tx_info so it
> > > > can
> > > > be used to
> > > > +                              * store the necessary enqueue
> > > > time
> > > > for packet
> > > > +                              * sojourn time computation.
> > > > +                              */
> > > > +                             u64 enqueue_time;
> > > > +                     };
> > > I wonder if we could move something like the hw_key into
> > > tx_control
> > > instead?
> > Hmm.. It's probably doable. From a quick look it'll require quite
> > some
> > change here and there (e.g. tdls_channel_switch op will need to be
> > extended to pass tx_control). I'll play with the idea..
> This is actually far more than I thought initially. 

Fair enough. Perhaps it could be done for the vif? But ISTR there were
issues with that when I looked.

We should just get rid of all the rate stuff and convert everything to
use rate tables, but ... :)

> A lot of drivers
> (b43, b43legacy, rtlwifi, wlxxxx, cw1200) access hw_key outside of tx
> op context (tx workers, tx completions). I'm not even sure this is
> safe (keys can be freed in the meantime by mac80211 hence invaliding
> the pointer inside skb, no?).
> 

Hm, yeah, that does seem problematic unless they synchronize against
key removal somehow?

johannes