From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 2ADF22DECC0 for ; Mon, 21 Jul 2025 15:30:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753111803; cv=none; b=caHeVbo5nhFhVuyfBiVBnNvVIXLjJTjQgF/U5N4HjJnL1+w04elgRRHexJqZdMI3h63wKJxv1qGYzPSoxcRT+r7PB5V9/kA6oSOPemUKob8tBWF5Kn8psxz6ukU5bOb/siyzsdiuIFm/KCAwlpYMyQjevtA6htO22Dw64roIWwU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753111803; c=relaxed/simple; bh=h0v2JEv2YFslte7HCpvryskVRHBdbZfWpK/kkHRicPw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cpvpOUBw82lyQBcUoyZ4PIhYDy5p0Kz957VFdY0ZfZiVwg9gKtoNPA2T2XLrEszq7btUogZ1n5l5a2iMtxLD9ncuNIbTH/TWxhnVRvDoZ+3olMrynDF3d1HwqAOts0VfdERhz9LYzAC3mPQkE9zdItSywaF6NGXy5XlVEvW63RM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ayjOJGUN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ayjOJGUN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52BCCC4CEED; Mon, 21 Jul 2025 15:30:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1753111802; bh=h0v2JEv2YFslte7HCpvryskVRHBdbZfWpK/kkHRicPw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ayjOJGUNUhmujLQO6Z6WntDq3yzsO1csi5hxpOSEJsOUtNmHoZyzPV+EwjwzvZK33 vAFjOgehUgWZOihcHjGwRUlVkZAHnrvFyteYfZ+MqpBpoA5R/00SZC/qxL3z40QVl/ i66LKL0ZxmRAqmRCCd/7jSk8Eb7bnekv6RwDqSCy+CE2lITrABejfWV+Yv7imBHs+6 d0Hoy44MYLmNMotbMBnYvELPrMCJrhRJ7joMVgk0X3VvtOcgU2iZ4cR00K9ILRQCTu o5pffC9eZm1/xB1bPbiLj2dxnfT8qNhkz/+HBiONpCQjPSXSM2dOPmu+S+VuXW58ip AQvrdJT5xhTQw== Date: Mon, 21 Jul 2025 08:30:00 -0700 From: Jakub Kicinski To: Paolo Abeni Cc: Eric Dumazet , netdev@vger.kernel.org, Neal Cardwell , Kuniyuki Iwashima , "David S. Miller" , David Ahern , Simon Horman , Matthieu Baerts Subject: Re: [PATCH net-next 1/2] tcp: do not set a zero size receive buffer Message-ID: <20250721083000.5f545b8a@kernel.org> In-Reply-To: <20250721082728.355745f2@kernel.org> References: <3e080bdba9981988ff86e120df40a5f0dc6cd033.1752859383.git.pabeni@redhat.com> <1d78b781-5cca-440c-b9d0-bdf40a410a3d@redhat.com> <20250721082728.355745f2@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 21 Jul 2025 08:27:28 -0700 Jakub Kicinski wrote: > > With just the 0 rmem check in tcp_prune_queue(), such function will > > still invoke tcp_clamp_window() that will shrink the receive buffer to > > 110592. > > tcp_collapse() can't make enough room and the incoming packet will be > > dropped. I think we should instead accept such packet. > > > > Side note: the above data are taken from an actual reproduction of the issue > > > > Please LMK if the above clarifies a bit my doubt or if a full pktdrill > > is needed. > > Not the first time we stumble on packetdrills for scaling ratio. > Solving it is probably outside the scope of this discussion but > I wonder what would be the best way to do it. My go to is to > integrate packetdrill with netdevsim and have an option for netdevsim > to inflate truesize on demand. But perhaps there's a clever way we can > force something like tap to give us the ratio we desire. Other ideas? FWIW didn't see Eric's reply before hitting send..