From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 B868D3B2C5 for ; Mon, 18 Apr 2016 08:38:22 -0400 (EDT) Received: by mail-wm0-x232.google.com with SMTP id v188so117417022wme.1 for ; Mon, 18 Apr 2016 05:38:22 -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=063eHazB3oVmK4ZaGQT8tFr+ZdaXccSAeDrCVeYY15I=; b=ZXgQOOIBAyOJ9AZY+dqp8C5AXrLvQvyUQ51BADrKxv/eaauowD6pFDz57xCnJ5KyRR +Bz+QMHDUWrhSE4MrjDV4aFkFcnTNpEekSBk4mg3oA0vqSFzj+hAAla4y2nzfOuqKsrc jtY9imCaVjulA3o7qFwo/U+izGztGCIEbGIr4= 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=063eHazB3oVmK4ZaGQT8tFr+ZdaXccSAeDrCVeYY15I=; b=XODgP7em0IfNs+jIXgX7y36loKck45Ac1+7TS/slJd2nmiOU1qjorfBIJjmUf4Mm6g +1xq/M2XmIiN8zoHszlxCsvNHwzol4AKH+IX216hXQGP93FXRrfE4fmVzP9F38WqlkZb Bcvh5cCkrDJDSRKnliqfdTTEwMV/QzIAyV7s/QXvoLuKN/uqYR6xl+2C2rBA8zTzLulf vWuOYApFB1PoQ/K4nHZBetpizisPtl0zA/QtMnq6OFH154yTwiU1wm/qBrft5b1FYWrm xLfy6QOU5ugMPjX/615KQTZMaDyNa7fnq5hjqDcvlh4Q0jJwtV9Q6E/iQ6j588F8iFOv IWIQ== X-Gm-Message-State: AOPr4FWoR5fLQQHzvcOFOLMjyPWZBPh+QFjZClFwDheeTZm9K6pBihBU5c1QBfdyzVgWc6fgh7A5qcS9sRSk+K6FeFBpynneBq+aYvZbSOP2DRuKnnf5o++oVtDhSohLRS6yfu8OrZGKcZBjRe01aX7HHA== MIME-Version: 1.0 X-Received: by 10.28.60.134 with SMTP id j128mr18719879wma.71.1460983101685; Mon, 18 Apr 2016 05:38:21 -0700 (PDT) Received: by 10.194.115.3 with HTTP; Mon, 18 Apr 2016 05:38:21 -0700 (PDT) In-Reply-To: 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> Date: Mon, 18 Apr 2016 14:38:21 +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: Mon, 18 Apr 2016 12:38:22 -0000 On 18 April 2016 at 07:31, Michal Kazior wrote: > On 17 April 2016 at 00:29, Johannes Berg wrot= e: >> 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. 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?). Micha=C5=82