Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1997972ybl; Thu, 5 Dec 2019 10:15:16 -0800 (PST) X-Google-Smtp-Source: APXvYqyf/LsczXmj2OEcn4nnKpspYuCNuwpZK1ht7LdLmDGlZzwiyOzcZjq9qDH7yXgSb1fpaxaU X-Received: by 2002:a9d:1b4b:: with SMTP id l69mr7627600otl.303.1575569715979; Thu, 05 Dec 2019 10:15:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575569715; cv=none; d=google.com; s=arc-20160816; b=W6P/3Bkdr7yu42NJjtKc5h2Eb6kXdi66AzeuGs/gu78KA8RhNCl1w2vyfLtafJp5bG yy2rsCDvuqICm3GUf5ZzL5Dfo3X64RZjylKgFYsuSs2lpRd4jcyuHRnPO7Itupi//Kf/ Wg2rvbC4Hqzbs/Omsi43ii7b8IwONGheajKDXu9A/63pINKsvOR3L5TGZYZsg40ZWsq5 G35m8Y5g5wNrlpIdFdlVJTV2H6h0cNR1U5E/18P9o4733UqwiGyz86wFHlA5xN0+LiqM 7ZYBgtDLQAQl6c0ok8Lfb/Q0ux5xmXs6CgF84QltzDxZV15M2Tu8wG2yXgsHtjNfQrR0 NW8g== 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=Ot18B9jazL+8Hf8waBPJOHeWbiatwuaV46xSKBn6SBQ=; b=bQX/WIwGdRFjaO7qpOpfCItmruviQyWzPF8PG6N9uJSx+LIgvZpMAQ2V/Jt78n1BXX hCZn/g5gtCTXTmovsKMH1uqBc97MUKHMQQDMEg24yoiIGWCLmkULsbVvQDjJ8QtNkfWP BIMEDP3SR2j7HcBvWmsqf6orBHR6PsTIchuGy4TAnfSOrL58uHixLP9IsY95vej91pw/ ZYZoghso6SEem+xyVCqG5wjm3SNCDAyavzEgG3eTrVTL7yGOULZ8HrgH/cQM3HX/Aahn /z/Xvkwze9K5gS68IkeZVvxB1bjP6vSb2sv2ngk2dDf6o/GxtDpNdvaiIbPb6ANttfWt C1nw== 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 w11si3336434oig.45.2019.12.05.10.15.05; Thu, 05 Dec 2019 10:15:15 -0800 (PST) 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 S1729417AbfLESI7 (ORCPT + 99 others); Thu, 5 Dec 2019 13:08:59 -0500 Received: from s3.sipsolutions.net ([144.76.43.62]:59412 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726028AbfLESI7 (ORCPT ); Thu, 5 Dec 2019 13:08:59 -0500 Received: by sipsolutions.net with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.92.3) (envelope-from ) id 1icvYf-004MPF-T2; Thu, 05 Dec 2019 19:08:58 +0100 Message-ID: Subject: Re: debugging TXQs being empty From: Johannes Berg To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: "linux-wireless@vger.kernel.org" Date: Thu, 05 Dec 2019 19:08:55 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 (3.34.2-1.fc31) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Thu, 2019-12-05 at 18:12 +0100, Toke Høiland-Jørgensen wrote: > > I'm on mobile, so briefly: > > What you're describing sounds like it's TCP congestion control kicking > in and throttling at the stack. Agree, though need to think about the UDP scenario more. It's faster, but that's expected since it doesn't have the ACK backchannel, and it's not that *much* faster. > The "new flows" increasing is consistent with the queue actually > running empty (which you also see in the warnings). Oh, right ok. That makes sense, it just loses info about the flow once the queue is empty. > My hand-wavy explanation is the the TCP stack gets throttled and > doesn't get going again quickly enough to fill the pipe. Could be a > timing thing with aggregation? As I said, hand-wavy ;) So I should need deeper *hardware* queues to make up for the timing? Thing is, sometimes I even see the queue empty, then there are *two* MTU-sized frames, and then it's empty again - all the while there are only ~40 frames on the hardware queue. You'd think the higher layer would, once it starts feeding again, actually feed more? Hmm. Actually, I wonder why I'm not seeing TSO, something to check tomorrow. johannes