From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from unimail.uni-dortmund.de (mx1.hrz.uni-dortmund.de [129.217.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9AAAD3976B2; Mon, 6 Jul 2026 15:37:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=129.217.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783352224; cv=none; b=TeuJLvuiNvoW2/urdnrHHjGEhPx5BScWtfMx96UlHgCYIGRZ9vh7FgKD/cmAYbg7dY4WzJJxqnsgFJzis00il3BdiqhMqew2e9rlJa5wfMYeOBk9QP7EZ1yktCskA/pZnANuqpv5YBhB9jsmA/BHc9NBfk1VZilJxy3w6Sg032o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783352224; c=relaxed/simple; bh=/gLU1ZYIoBZNDWpqrT3SqMshBw/xL7i3z8xLVloSYAU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VdpAMASFDMkQiNCBDsCKKw2yWAvpJNMAFnVQ2v9aUl0WKoW8G789uuNDvvEsAJQ36iJ0WKYTVF84/tJlVFpFGD3t9L3cEH6w1p5XuNE3DatlnrLYR7KvCxlFnnXFc4MVjPOcPjSGD3hreYKEKHqaGS1cWWQyUUF9i2CbjSgkKfE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=tu-dortmund.de; spf=pass smtp.mailfrom=tu-dortmund.de; dkim=pass (1024-bit key) header.d=tu-dortmund.de header.i=@tu-dortmund.de header.b=m1i2jSKS; arc=none smtp.client-ip=129.217.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=tu-dortmund.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tu-dortmund.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=tu-dortmund.de header.i=@tu-dortmund.de header.b="m1i2jSKS" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tu-dortmund.de; s=unimail; t=1783352020; bh=LcT8nSRPPRwrKXE781yHHNVxYxj3ib/wKkBEPXxseS8=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=m1i2jSKS9nvyY5iUatK2T5uv4V0M85q0KcXiSWCes3Y7qiOJod8A7BVHwUm++zcO9 CRaeZtbEd8uTeRI1rju6xjUS0AEMRyS+Mgm9ZR+zEetvEtuiJzA6bGGM7zMbRAKC1d 7koO4jd+j+IMPRAkpazTV3VedhGWX6y24MtzuLeM= Received: from [129.217.186.105] ([129.217.186.105]) (authenticated bits=0) by unimail.uni-dortmund.de (8.19.0.2/8.19.0.2) with ESMTPSA id 666FXc6A027333 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 6 Jul 2026 17:33:38 +0200 (CEST) Message-ID: <2728c540-2e76-4e06-9064-ed1dff071cbe@tu-dortmund.de> Date: Mon, 6 Jul 2026 17:33:38 +0200 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net v2] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE To: "Michael S. Tsirkin" , Brett A C Sheffield Cc: Willem de Bruijn , Jason Wang , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, Simon Horman , Jonathan Corbet , Shuah Khan , Andrew Lunn , Tim Gebauer , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260706094242.115992-1-simon.schippers@tu-dortmund.de> <20260706091706-mutt-send-email-mst@kernel.org> Content-Language: en-US From: Simon Schippers In-Reply-To: <20260706091706-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 7/6/26 15:23, Michael S. Tsirkin wrote: > On Mon, Jul 06, 2026 at 12:11:15PM +0200, Brett A C Sheffield wrote: >> On 2026-07-06 11:42, Simon Schippers wrote: >>> Commit 1d6e569b7d0c ("tun/tap & vhost-net: avoid ptr_ring tail-drop >>> when a qdisc is present") did not show a relevant performance regression >>> in my testing but on Brett Sheffield's librecast testbed it shows a >>> significant performance drop in a IPv6 multicast testcase. The regression >>> can be pinpointed when multiple iperf3 UDP threads are sending. For 8 >>> threads the performance dropped from 13.5 Gbit/s to 9.13 Gbit/s. This is >>> the reason why this patch makes the qdisc backpressure behavior opt-in. >> >> Your v1 commit message was correct. The iperf3 tests were TCP, not UDP. >> >> The original failing test that alerted me to the problem was IPv6 multicast >> (UDP), but the reproducer tests I provided stats for in the regression report >> were TCP "To eliminate my code and any multicast weirdness" and also to verify >> that this also affected TCP. >> >> Sorry for the confusion. The command lines used are in the regression report. >> >> I've tested the v2 patch (with IPv6 multicast), and verified the >> previously failing test passes. >> >> Tested-by: Brett A C Sheffield >> >> Cheers, > > > Just to clarify, it's more of a work-around, not a fix. > > It's not really great to have a flag that says "change something > opaque in the internals of the device, it affects performance > in some way, we can't predict how". Yes, I agree, but in the end I am just using netif_tx_stop_queue() and netif_tx_wake_queue()... > > So maybe we really should revert for now, and work on something > more coherent for the next linux. But even if we could perfectly fix the performance issues, maybe users even users rely on the dropping behavior. From Brett [1]: "In our multicast use case data is sent by multiple threads to multiple groups simultaneously, this just breaks things to the extent that a <2 second test times out after 5 minutes." We are *not* factor 5min * 60sec/min / 2s = 150 times slower than without the patchset. My theory is that the sender sends a fixed amount of data of which most is dropped without backpressure, which is much faster then the real processing, and so the test *relies* on the tail-dropping to work. @Brett can you maybe support this theory? Thank you both very much! :) [1] Link: https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/ > > >> >> Brett >> -- >> Brett Sheffield (he/him) >> Librecast - Decentralising the Internet with Multicast >> https://librecast.net/ >> https://blog.brettsheffield.com/ >