From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 142713CB35 for ; Fri, 8 Nov 2019 06:01:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573210899; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=2pehBU8sSxfSfaE4NqFPdAzFqvrsYq1VRgTX8hc2G1Y=; b=Yf1DTB1HkGqCsJEqpGv6VvJjcaBpKfqDSTRmlsJtAMcQY1zybAPH0Jn/Ab/+Omok8z2mpr pfDL3YVrE1cVH4EttMPTExr1Sty6S1Cr/UV2XMxfelmtAMcDK45LEtGixJWq0PIDJlat+z rM3fJ+1BV+usLMUc6ObOdyQ2r+1vihI= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-206-0n8D1XR0PF6aC6XQG-YOcw-1; Fri, 08 Nov 2019 06:01:36 -0500 Received: by mail-ed1-f71.google.com with SMTP id g16so4156047edp.13 for ; Fri, 08 Nov 2019 03:01:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=ZyyhMUlU9R9fEWMycrsCOqhiWueP8mUiq2raZisldTk=; b=Xtofes9Y8snfV5tlaPvhbB641ICSmsCjwkBjj9FQ5ye9DQAVfpQvpGs0ClzZj32VZN /6getHDNy1TEPPtOanjwhsEbUjyUzc/kR3n+n8cWCHJBQILqu2vIJM+ZqXEuOmOZUay6 fB98SmzrVn1GO98kmbifHBN6BKnudUDNFxmJZSC4enW9Xhay+Gb83yAUoDn+5LEEZ3t6 zbtiS6iz67iuQRmrzTzgbzzwNIVYLkVvsd4uwPjfA3cimS3I/5RmHBxXLbdHey4eP92u Pl17qD84vbmNgklxV1Wj1qO2HlZ6VOvwqSA1vU+uJZswVSdaV/FBqNQa+hx7jSkDvFR9 PUKQ== X-Gm-Message-State: APjAAAWRfzv16LHPUHzqHJhyyDmHXUNOzRQ8xKTpJK4x4Bs0FeHSaE5w G53NTOYPekSg8u/AkvGLIG3dl/jcaC2cN6X44MdOZNiEx1xAP36FhMtq0q5M4cAXwQiqAu/OGQ9 oWzOqDp576szUN2ydc9uJK9KioqOZSrCG6PI= X-Received: by 2002:a50:8969:: with SMTP id f38mr9359913edf.211.1573210894461; Fri, 08 Nov 2019 03:01:34 -0800 (PST) X-Google-Smtp-Source: APXvYqwWTp/rmoroMCiYVUg5skGWAlRu+PZp2l3Gpm6XBlHO+OWpIgcFnaYBh6CItZidwf+cGQInqg== X-Received: by 2002:a50:8969:: with SMTP id f38mr9359892edf.211.1573210894274; Fri, 08 Nov 2019 03:01:34 -0800 (PST) Received: from alrua-x1.borgediget.toke.dk ([2a00:7660:6da:443::2]) by smtp.gmail.com with ESMTPSA id v17sm117797edt.76.2019.11.08.03.01.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Nov 2019 03:01:33 -0800 (PST) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 09BC21818B5; Fri, 8 Nov 2019 12:01:33 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Johannes Berg Cc: linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, ath10k@lists.infradead.org, John Crispin , Lorenzo Bianconi , Felix Fietkau , Kan Yan , Rajkumar Manoharan , Kevin Hayes In-Reply-To: <0b43c4822ab83ea4d33a5a32d8ff6c7a56eff6c5.camel@sipsolutions.net> References: <157182473951.150713.7978051149956899705.stgit@toke.dk> <157182474399.150713.16380222749144410045.stgit@toke.dk> <0b43c4822ab83ea4d33a5a32d8ff6c7a56eff6c5.camel@sipsolutions.net> X-Clacks-Overhead: GNU Terry Pratchett Date: Fri, 08 Nov 2019 12:01:32 +0100 Message-ID: <877e4afx83.fsf@toke.dk> MIME-Version: 1.0 X-MC-Unique: 0n8D1XR0PF6aC6XQG-YOcw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [PATCH v6 4/4] mac80211: Use Airtime-based Queue Limits (AQL) on packet dequeue 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: Fri, 08 Nov 2019 11:01:40 -0000 Johannes Berg writes: > On Wed, 2019-10-23 at 11:59 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote= : >>=20 >> +=09if (info->tx_time_est) { >> +=09=09struct sta_info *sta =3D NULL, *s; >> +=09=09struct rhlist_head *tmp; >> + >> +=09=09rcu_read_lock(); >> + >> +=09=09for_each_sta_info(local, hdr->addr1, s, tmp) { >> +=09=09=09/* skip wrong virtual interface */ >> +=09=09=09if (!ether_addr_equal(hdr->addr2, s->sdata->vif.addr)) >> +=09=09=09=09continue; >> + >> +=09=09=09sta =3D s; >> +=09=09=09break; >> +=09=09} > > I guess that is better than looking up the sdata and then using > sta_info_get(), but I think I'd like to see this wrapped into a function > (even if it's an inline) in sta_info.{c,h}. OK, can do. >> +=09=09airtime =3D ieee80211_calc_expected_tx_airtime(hw, vif, txq->sta, >> +=09=09=09=09=09=09=09 skb->len); >> +=09=09if (airtime) { >> +=09=09=09/* We only have 10 bits in tx_time_est, so store airtime >> +=09=09=09 * in increments of 4us and clamp the maximum to 2**12-1 >> +=09=09=09 */ >> +=09=09=09airtime =3D min_t(u32, airtime, 4095) & ~3U; >> +=09=09=09info->tx_time_est =3D airtime >> 2; >> +=09=09=09ieee80211_sta_update_pending_airtime(local, tx.sta, >> +=09=09=09=09=09=09=09 txq->ac, airtime, >> +=09=09=09=09=09=09=09 false); > > I wonder if it'd be better to pass the shifted value to > ieee80211_sta_update_pending_airtime() to avoid all the shifting in all > places? > > You could even store the shifted value in "aql_tx_pending" and > "aql_total_pending_airtime" etc., it's completely equivalent, and only > shift it out for people looking at debugfs. My reasoning for doing it this way was that we have another set of APIs dealing with airtime which doesn't do any shifting; so keeping the APIs in the same unit (straight airtime) seemed less confusing. We could add (inline) setter and getter functions for the tx_time_est field instead to avoid sprinkling shifts all over the place? :) -Toke