From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 D4F523B495 for ; Tue, 19 Apr 2016 05:31:41 -0400 (EDT) Received: by mail-wm0-x22c.google.com with SMTP id e201so6509492wme.0 for ; Tue, 19 Apr 2016 02:31:41 -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=iUeF88FN39zOt1VrDEuZEx/TlkQ9O+2MZJ4SDfTHZK4=; b=Ew28WJlQB97WCQuaPWW7zZFXzSg4BQqjvMW96iF2YLiCFS59E4h4RvEuCYJ1AgkHkS ZqthjqbSuXXduaN4AKkdPN+tPP8+KrPJMF2PxbC/1jezXG8V3N+6AnfOZ3/QAWfw+qQ/ cyEsUQCTUdFMBvGdMTw56BkxYlYP9FekEh3HQ= 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=iUeF88FN39zOt1VrDEuZEx/TlkQ9O+2MZJ4SDfTHZK4=; b=Xi/wxlN853RzTuaafuFNMIJiBgndjQaD30aLyCEwqYtDnXLQWNuhDkHGqVqTA6hchr hZoI4ZWeL59IXU31YND08WM7+eTW0TIGUx3I6goLQYon/fhSPQSaAbpTpGTRJ/+XbQwP Ce2PlRq+wdz3La3Ue4iLEARylkS+/RT/YPf/2xbn1ZEEZs/6wLQT1oVU/yJPH5BThr5y Q5qQvPznlNJAI0XMPVlAbZQgRmuNlER5Tp7sM2ySgjHg71PJxb5WWTDuRcu5oDvrL/9g FdceiZsaEPTm5MdPNNapgEBITmd6GkWrkYDXEhuBkbPoqUrl+giPVRL4AWPX5ZnMqgVl zW/g== X-Gm-Message-State: AOPr4FV/51s4qm0DNL6cSmccgiCsrL69ytwj+Ta8ppKYJxH+p8kGNVTltIxBxdTwHFLUqe6h2NL0E999ygJ3DuwrDE5OCFc8OyFAxLdwdbqpyZO+jRBBdS4OwHNU8WkP2+zTXbUtDrX9QRYP11OfZAD4ng== MIME-Version: 1.0 X-Received: by 10.28.54.148 with SMTP id y20mr2500332wmh.68.1461058300841; Tue, 19 Apr 2016 02:31:40 -0700 (PDT) Received: by 10.194.115.3 with HTTP; Tue, 19 Apr 2016 02:31:40 -0700 (PDT) In-Reply-To: <1461056788.2766.13.camel@sipsolutions.net> 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> <1461056788.2766.13.camel@sipsolutions.net> Date: Tue, 19 Apr 2016 11:31:40 +0200 Message-ID: From: Michal Kazior To: Johannes Berg Cc: linux-wireless , Dave Taht , make-wifi-fast@lists.bufferbloat.net, codel@lists.bufferbloat.net, Avery Pennarun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Subject: Re: [Codel] [PATCHv3 4/5] mac80211: implement codel on fair queuing flows 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: Tue, 19 Apr 2016 09:31:42 -0000 On 19 April 2016 at 11:06, Johannes Berg wrote: > On Mon, 2016-04-18 at 14:38 +0200, Michal Kazior wrote: >> On 18 April 2016 at 07:31, Michal Kazior >> wrote: >> > >> > On 17 April 2016 at 00:29, Johannes Berg > > > 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. Still tricky in a similar fashion as hw_key. > We should just get rid of all the rate stuff and convert everything to > use rate tables, but ... :) I'm guessing it's not trivial either and you risk breaking a lot of stuff? = :) >> 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? I didn't see any explicit synchronization but maybe I missed something. Micha=C5=82