Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp612745ybp; Fri, 11 Oct 2019 01:17:28 -0700 (PDT) X-Google-Smtp-Source: APXvYqz/wrddGfv4p7vihh+U7dzgqPuxydEl4M2B/4PFmUCOnEDJwj+D+70TLZY7vXzXlMrdOQ0a X-Received: by 2002:a17:907:20c8:: with SMTP id qq8mr12344916ejb.311.1570781848172; Fri, 11 Oct 2019 01:17:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570781848; cv=none; d=google.com; s=arc-20160816; b=bPVQeqigTvg625C0GGhyh5VDKeaW24jRbEHC9ChLB8sA59GBvSVCK5egv9bEvlUXrP 9fzbd966dmUFfY1C2aafS4kwbMFwkDGJPgErfdorfqKDsSxFztPWNRNsl2W9TNe58f+4 yw4C+U/5sQM0GDWr9xD58Ari4WzvFPvXKi5F2Vp+x4GZ3CKrKixk8VKbyBnBJTxabtkD V9ex5SK4Bqv6a3Qgk5WdxEfGY5IwmHHxpMj13a1U0llq63a0ga4lNTq4ehIm0yc72L6K Z8giGpGmGUsQd3WoGoWmkeHeIUsY/sBbG2uZnun5gbu3m8jt6Ikwh3Tk9vaSYiNGaGaN 8dRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=fTZRZ4PlL8Rnqq6X0ng9xz+aYOhAQ7I4Oa3l4xz/9Lw=; b=KFEfCNety52Pk59Fzeuxh+oGb9uG17ePgPLSEeDa3PBnbBhz4W/qIcOKELgHqPRScA XVnD0/hZyZBQHo34vc6N6mJLrBEQVtZFyKJX1xkjTI+IjBK+30H3FcuEG8ehNVj9rZpJ QflJAphUlWYcI7H+mP52ZL4kO6yxIcnDjTB+wgrdHOoPGw1X32757ROSxXddFPpMSBeD iZfT8snrVACMQCO9L5Lo9M72SsW8qkRhZFOLbw6UL21XsvX2IvgL0kqMNf6Law+AiX21 P5+sCJNWmVPryhGamjR3h5ku0T3cwvj+42dpKIz/jkh3BUOGJGG1YrQru40cBEt1mMOR Pjgg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e23si4701362edq.344.2019.10.11.01.16.51; Fri, 11 Oct 2019 01:17:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726328AbfJKIQf (ORCPT + 99 others); Fri, 11 Oct 2019 04:16:35 -0400 Received: from s3.sipsolutions.net ([144.76.43.62]:34194 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726174AbfJKIQf (ORCPT ); Fri, 11 Oct 2019 04:16:35 -0400 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.92.2) (envelope-from ) id 1iIq68-000582-Kg; Fri, 11 Oct 2019 10:16:29 +0200 Message-ID: <3cbedfe48e796b9d2c28d97c301a08a03b42869c.camel@sipsolutions.net> Subject: Re: [PATCH v3 1/2] mac80211: Implement Airtime-based Queue Limit (AQL) From: Johannes Berg To: Kan Yan , Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: linux-wireless@vger.kernel.org, make-wifi-fast@lists.bufferbloat.net, Felix Fietkau , ath10k@lists.infradead.org, Yibo Zhao Date: Fri, 11 Oct 2019 10:16:27 +0200 In-Reply-To: (sfid-20191011_042420_744343_355715ED) References: <20191010022502.141862-1-kyan@google.com> <20191010022502.141862-2-kyan@google.com> <87ftk0jr70.fsf@toke.dk> (sfid-20191011_042420_744343_355715ED) Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5 (3.30.5-1.fc29) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Thu, 2019-10-10 at 19:24 -0700, Kan Yan wrote: > > > + * ieee80211_txq_aql_check - check if a txq can send frame to device > > I wonder if this really should even be have "aql" in the name? It's also > > going to return NULL if there's nothing on the TXQ, for example, right? > > Renamed to ieee80211_txq_airtime_check() :) > This function is not for finding next eligible txq, but return a > boolean to indicate if a given txq can send more packets to device. It > is also called from ath10k: > static bool ath10k_mac_tx_can_push(struct ieee80211_hw *hw, > struct ieee80211_txq *txq) > { > ... > if (!ieee80211_txq_airtime_check(hw, txq)) > return false; Sure, I get that. I phrased this badly before because I neglected to look at the code of the function closely. You were documenting it as + * Return true if the AQL's airtime limit has not been reached and the txq can + * continue to send more packets to the device. Otherwise return false. but with the current implementation that's not really true. For example, if there are no packets on the TXQ at all, then the function still returns true, even if it's not true that "the txq can continue to send more packets to the device". So I guess really what I should ask is if the documentation shouldn't be rephrased to say something like [...] has not been reached and the TXQ is eligible to send packets to the device, regardless of whether or not it currently can or cannot (e.g. if it has no packets, or is stopped, etc.) to make it more obvious that this really is *only* concerned about the airtime aspects. > > But then again, we don't really care *that* much about overflow or > > underflow in this code path - it's not going to be security critical. > > But it seems that your code there actually can cause UB? That would be > > nice to avoid. > > Actually, that condition can never be true, right? Wait, ok, this one > > can because integer promotion? > > I don't think that condition could happen. The WARN_ONCE() was added > per your earlier comment. The older version don't have underflow check > and reset pending_airtime part and I didn't find any issues. Of course it will never happen with a valid driver :-) But it seems like a very easy mistake to make - add an estimate, and later subtract the actual airtime, which may be more ... > > Except aql_total_pending_airtime is still defined as s32 and that causes > > different behaviour? > > All this confuses me ... is it possible to write this more clearly? > > I revised it to something similar to the original version, which > ieee80211_sta_update_pending_airtime() takes extra parameter to > indicate whether it is for a tx completion event. > void ieee80211_sta_update_pending_airtime(struct ieee80211_sta *pubsta, u8 tid, > u32 tx_airtime, bool tx_completed) > This help get rid of the problem that airtime need be signed. Also > added the inline function of > ieee80211_sta_register/release_pending_airtime() as you suggested. ok johannes