Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp379147pxj; Thu, 10 Jun 2021 03:07:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxrtwpaCQqtCPRv9Yj/FOF0otZRI4yVTgsM2p1jFbQJAtK1d1JYSfNW5rQWjBe8Wz1UI3Wy X-Received: by 2002:a17:906:b317:: with SMTP id n23mr3802954ejz.324.1623319639314; Thu, 10 Jun 2021 03:07:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623319639; cv=none; d=google.com; s=arc-20160816; b=xpT7R50Oyxte9MzoHWNjTVN6Jn1OIHEfzBHXmUnKQxzMXTMesFtM3jZhmdVG6a3SO3 Wg3VR67nlPV+IGLpmyVb9G50DPDnQtM8IZ4Hru+OZBNxCuSw878wWedT4EJC9zx91pv7 oxUhtOqOzk4cB55vl4NFjMAOA4nDUJRHMx9nDuTPaVxO61o1Gwo/xMzTXDUQ+yL0YqkE znXw+ufHhztBdvp9YBh5ft4LOJLkqwqiBDBuCTpWXC20g3HSsODLkIXaQdsPuSy5ZcSt 4zf7xx5DLvgX07zn7H1EKv99ANNbYvAHzK90lKYnTDtvb/f0O3RwWWJdEWO5XrNxLEUI 48OA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=y1t1gThwqk4P3CmoGImUqahvI/YhwYgwDOhTQsQgvaA=; b=SY1yH3c+3JqHcJheWYIoCizlwpQYDx4TRetF0fLK3K1q96FnacwFPLgSA8/wR+4FGb 2HKibWgLdxTwrGME8CWMOggaIcgbgAPtrF9NHiXIR1gq6QOdAE7fMQtEp/NSIhfRX0XX jIYwx96z4b0z3U/TAmxJMym+GG+b6zUZM9CKVsB4HRlgMAb+sdKGd1yZtW45t7g4Uy1z W88GF7TzbrcYUn6RYg1EtQyNOllIZTFGtwsyz3q5JRI5W7yviFMZX8dlfHmRheu0SyFL X0TTeO3oG8NbV2IucNZQTWLztCwnOX+Q+Dacb/KamMZkjh+O9Tg6T3P5q6mJKsdeuh3h uJ1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Fo5PxKwz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cq9si1917068edb.321.2021.06.10.03.06.55; Thu, 10 Jun 2021 03:07:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Fo5PxKwz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230216AbhFJKGy (ORCPT + 99 others); Thu, 10 Jun 2021 06:06:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229961AbhFJKGw (ORCPT ); Thu, 10 Jun 2021 06:06:52 -0400 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 357C7C061574 for ; Thu, 10 Jun 2021 03:04:49 -0700 (PDT) Received: by mail-yb1-xb30.google.com with SMTP id i6so25299496ybm.1 for ; Thu, 10 Jun 2021 03:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y1t1gThwqk4P3CmoGImUqahvI/YhwYgwDOhTQsQgvaA=; b=Fo5PxKwzHWbMPPS1iiWO2GC+MRsiSG+6qXKY/mJ/8+7ab/qIWgpJGQVg99FSMR59zt L+z+SMHv4atQvkUU+725zAvAEtaDTy9Yh0HZGmPZkqEve5SDUZFOBscTmtgsyMenyG8S IAi76+d89mduQPDfXVeeIyAVTDccEEn+imq2ABlI57gwY5WGv1pXTZaqp/BRpHisTPPS GfaHjkwECD96YVgA8t1W0kmiioSEfBzKDGXtbuEV7jmAInCnH7zyVxf0GHB8pyzJZZiO 4EAZOM+pokM+kdAIbQR6JsQkllDWaMu7mFrz1GoNVlfNvBL4u4BlbvA7PYQ6pp0ynTax zLNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y1t1gThwqk4P3CmoGImUqahvI/YhwYgwDOhTQsQgvaA=; b=uABhrPZGpGpSAM2fHaODTftAdE2yfiNeKtA6tFxB7E2tQpBhHyB/eAqgrRoep4gAUF LArc/kkAO133FbugkaQD7S6Q4tMahYO29nb3Wk4InqyiUHO8UtrSkso0c+TIHmZe8Sqe 4Ijn1+KQp34QGvG56yjqNlqGk3QLX0kHRFM7VWFycjqsMfr832zHcun1G3mXVp7lhAvW YwC8gJ0O30LsV8cGX61I/TWa9yBfTKIokLJq/J7tVdBdzdRdv5DbdhDjJjo4ptsQ0Zt6 33padCrbJvxSHPS0Evr2dGeRmoACQhi/ImmrZOCANozmRHmH7LVVZptAW+0qngEeAQ7o Ma2g== X-Gm-Message-State: AOAM531D1kk5eUrLT+Qt7o8WiujiDQ+46PY0Iz6BNwH44eItgVfkmD2N 8chv5z6qb+JUxiKgV6MZkjyx5A7tQITK/Yosc0jowA== X-Received: by 2002:a05:6902:4b2:: with SMTP id r18mr6636440ybs.446.1623319488149; Thu, 10 Jun 2021 03:04:48 -0700 (PDT) MIME-Version: 1.0 References: <1623058534-78782-1-git-send-email-chengshuyi@linux.alibaba.com> <0e938649-986d-ce79-e3c4-1f29bdcb64e0@linux.alibaba.com> <258e3c94-f479-509c-a4b0-5a881779dd14@linux.alibaba.com> In-Reply-To: <258e3c94-f479-509c-a4b0-5a881779dd14@linux.alibaba.com> From: Eric Dumazet Date: Thu, 10 Jun 2021 12:04:37 +0200 Message-ID: Subject: Re: [PATCH net-next] net: tcp: Updating MSS, when the sending window is smaller than MSS. To: Shuyi Cheng Cc: David Miller , Jakub Kicinski , Hideaki YOSHIFUJI , David Ahern , netdev , LKML , kernel-janitors@vger.kernel.org, Mao Wenan Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 10, 2021 at 8:00 AM Shuyi Cheng wrote: > Thank you very much for your reply! > > Maybe it's not clear enough that I described it. The scenario where the > above problem occurs is precisely because the tcp server sets the size > of RCVBUFF to be smaller after the connection is established. Here is a > sample code that caused the problem. > > # default tcp_rmem is 87380 Except that this value is overridden at connection establishment. tcp_rmem[1] is only a floor value, say if you want a reasonable value even if MSS == 100 > tcpServerSocket= socket.socket(socket.AF_INET, socket.SOCK_STREAM) > tcpServerSocket.bind(server_addr) > tcpServerSocket.listen() > while True: > connection,client_addr = tcpServerSocket.accept() > # Shrink rmem > connection.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 16*1024) > > Therefore, when the developer calls the sock_setsockopt function to > reset RCVBUF, we can use sock to determine the TCP state. When in the > connected state, it is not allowed to set RCVBUF smaller than mss. > Sure, but the application can _also_ set SO_RCVBUF before listen() or connect() We can not have assumptions about SO_RCVBUF values and socket states. Otherwise we would have to add some sk_rcvbuf adjustments every time the socket state is changed.