From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.217.43 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793459705; b=5Fswjd9HXfqTNOTcX8RFB5VaEffaApFZY0yxcNMKviRTmmXyDgjmLL8iY0TyRha1SjuP lXs2sZw57Tj8NXhqG/PKEVH3Rib9fKMZaG1WNUupPoi2moqilDfFhmfEKOwbUdRySKWuy bSjMcB3ujn53wHYAKjyT4gzoMt583M5h5oQx6U8dpFh9BvTS3AFR6rkNu5sib3HPrdc4j ukCDU3v0DfqPIUrWJ3XTHpHrE4b7krbo7kaR9CkJ8Oh7/Emlj5/TwUAnquS2Ujz/b80gP oO8lIH4O3DhSovZkpMpVhTG4Y/Q13zI2dMIs95ZbrKlvZVBW1zLIaRVSaW0lOyHnunw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793459705; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=u4AoREHEWHwqK+9vsy9N5I/xo3mEZgUmU5DSaNM6uCY=; b=bylYBKcnZdccbZrKWoRJXf5Wc3h9/Z9tmSazNWGgTa0EIZkdylqsA6Drc2Py0ThH93dr SrVWOmdPD++HAk11j+nl078AasGhScHZai8Sm+OWhfbEn0AQhlxH18Op8oSr+7PIee0FM aOuAxvk3rEhnk8NAdxmjicWSbK7KA0AAFwTslV2T82StO/Kvh4TJldANKzqQSMLoiTiS2 BKbcyUwj9h3zuLthQK5GdGNsjjWfNf/MHxVhnygpXnncCXpg0FBzCkqA+3p+nPqIFntc2 l4nVd25jUm3DF7/tEJTRE1wjoln75vM8SMj1+9twVVOENphwiBuwlVEKOqywJo1+TYQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b="PhqPg/E2"; arc=none smtp.remote-ip=209.85.217.43 Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8BADB606A32A for ; Sat, 31 Oct 2026 15:15:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 8BADB606A32A Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=PhqPg/E2 Received: by mail-vs1-f43.google.com with SMTP id ada2fe7eead31-7cc603a168fso509432137.3 for ; Sat, 31 Oct 2026 08:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793459704; x=1794064504; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=u4AoREHEWHwqK+9vsy9N5I/xo3mEZgUmU5DSaNM6uCY=; b=PhqPg/E24VOKRLpfl1ae1ubh4CKpCn29JqhLZjBp/MR26TAAiPCusNfbhZKqTqe7Xj KcQq5Lydqkv/yxQqi5C7ZY3ZDqurJIdEnXH0ucUJaLRRdFFYKlc9/hSNt/FBOqLJJqI7 p6jj64s7228VWY/vk1afOCOip01plUgqwJps6dk4WwMDU5fMSszkrzQk+rwDSKDYE+HI 68LbUdDAtL6NWwfUTf5zsmuxjMBjVb0I019RVHKueoF64p2AswdpFejX62Xr+afWIrOW DgPY165zFFs16BXhBuygZX7vyRNjKllQEoev9+VtxIjjr17scodCqljZafdWsq6sK09A Fhwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793459704; x=1794064504; h=content-transfer-encoding:content-type:mime-version:subject :references:in-reply-to:message-id:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=u4AoREHEWHwqK+9vsy9N5I/xo3mEZgUmU5DSaNM6uCY=; b=l+uuXET1aLxXU0PQgLJEXjom21D3+XFhW3kjFlSX5r7GaFglq7gFNX/YldWcjhOe7o V9yJP5K41fu3vK1zRXimYhI4lL1fYclZcv3ZZEVxXWTDN+gXXWuRdjEnVzvqLtG6VV/m hrisAHDJ6BE8X48s+aypnA1MhdTz1XWQa8KqgTCp+k2W84E2/mrw5/ETr+zJ4V4kwpJM VKdWfDAfjn9ROtCMbZX4aIOXCaCSyjMDrsz5Sz971rxwsil9NeL2bgqyZ+Q4Igv1g8vq 1eSlPUQXIzO3vN1D7I4VcaIE/Di6M7G4wMsFMEu3PptIUkxjzNkIgLPVz49Mbapje/E2 x4/w== X-Forwarded-Encrypted: i=1; AKwUvBz+/p/1xm/MptoNj6wlh4NnUi2VMeCaGgbrx/dcU4KbQaRfEB1DkEZ7llT8TI4qQH8PPjtEtKVGVL0=@vger.kernel.org X-Gm-Message-State: AFq9FYL+snXY1oMLUVEDBkoarYSlq48zPZ6hRSRs9DrCFgFoIlPD8NXv 7sRmqqlXu47/JCGjsmi2cW5IBMZi/qPbwyOZlw5Dl1aeLcYEupW2WG6d X-Gm-Gg: AYBFou2QJP8530ch2OjPPM4WFw3YfIfKJqn55BPjD+iRn//37R55guwLS8Uw5x8OX5d uf9FkR9DnTyQqaHEW5lqs/uDATpJdMSnMiC/D8eQzvh29AXgt7gcn2sclVyplNGlP+qOIZ+Y9Jz YDZzI1a0ig177Nfl3FiZ4BIg00HPOX3b1UM2HlZ1qMZGbr859Fz0A+Vat/2x7TCjwoaGAQR+Rbi WBpC/nQ8t4u4q+2sMffB/WIEmc2I82xWsAqRa0uuzS4DtdaAkDZcMHlQUyw2m13a792Nk0BaK1F XPvQ4khFKLbK5T0GhE6b5id/T339w51mPyCV2fmfVthifSmhmxsyMgjuMwCeYYtSocqYKprlepw 8BU4QEJplUKIKKoongykVa5gBKIv4AD5IZZcm4U3IqYWEsEm4MO86OYiN2yJeMyl2MVA9CrjPjP oelguvFTrj+Au2GaVl8gpYAva1AFcsqr3iIFc5ON/vqjocI2M3fPtNX15nFxTO6vi6TUBPCLuKg SpTV0huri91evetwxwWp0UvNRoX6Eg23yUaEtArnBwBgpb0NNyCMePIuYK/sjTBNLp2ZBgWjHGD Y7o0klTKPHrT8ot7SaejQ+wgW4Wl+d4KaeR5SGkjlv9AIRn9/XalB5wh/l+zz62/WTTafKnKzmW p2KkMTQDHgTx1ckOl5w61NswSuW+F8ytrG3Lclht+Ynp8Wgxy+nawM0lZ6PipYb8Vu647 X-Received: by 2002:a67:e116:0:b0:7a1:fa0f:1106 with SMTP id ada2fe7eead31-7d072d759a9mr2050864137.36.1793459704527; Sat, 31 Oct 2026 08:15:04 -0700 (PDT) Received: from gmail.com (111.46.245.35.bc.googleusercontent.com. [35.245.46.111]) by smtp.gmail.com with ESMTPSA id 71dfb90a1353d-5ec69c5d183sm6032016e0c.13.2026.10.31.08.15.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 31 Oct 2026 08:15:03 -0700 (PDT) Date: Sat, 31 Oct 2026 11:15:03 -0400 From: Willem de Bruijn To: Vitaly Zuevsky , netdev@vger.kernel.org Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Shuah Khan , Randy Dunlap , Richard Henderson , Matt Turner , Magnus Lindholm , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Andreas Larsson , Kuniyuki Iwashima , Willem de Bruijn , Arnd Bergmann , Christian Brauner , Andrew Halaney , Jori Koolstra , Alexander Mikhalitsyn , Tariq Toukan , Saeed Mahameed , Chuang Wang , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, sparclinux@vger.kernel.org, linux-arch@vger.kernel.org Message-ID: In-Reply-To: <20261031113330.45704-2-vitaly.zuevsky@gcore.com> References: <20261031113330.45704-1-vitaly.zuevsky@gcore.com> <20261031113330.45704-2-vitaly.zuevsky@gcore.com> Subject: Re: [RFC PATCH net-next v1 1/2] net: add SO_NO_RFS to exclude a socket from RFS and aRFS X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Vitaly Zuevsky wrote: > RFS and accelerated RFS are enabled per host and per rx queue, but > whether steering helps is a property of the flow. A host that carries > a few long-lived flows which benefit from steering alongside a large > churn of short-lived flows has no way to express that today. > > Add a boolean socket option, SO_NO_RFS. When set, sock_rps_record_flow() > does not record the socket in rps_sock_flow_table, so get_rps_cpu() > finds no match and neither software RFS nor ndo_rx_flow_steer() acts > on the flow; it stays on the CPU chosen by RSS or RPS. > > The option is kept in sk_flags so that sk_clone_lock() copies it to > accepted children: setting it on a listening socket excludes every > connection accepted from it, while sockets the same process connects > itself remain eligible. > > sock_rps_delete_flow() is skipped as well, because a socket that never > recorded itself must not clear a table slot that may belong to another > flow. > > The test sits after the TCP_ESTABLISHED check and inside the > rfs_needed static branch, so hosts without RFS pay nothing and hosts > with RFS pay one test_bit() on a cache line tcp_recvmsg() already > touches. > > Signed-off-by: Vitaly Zuevsky The Documentation change can/should be included in the main patch. > --- > arch/alpha/include/uapi/asm/socket.h | 2 ++ > arch/mips/include/uapi/asm/socket.h | 2 ++ > arch/parisc/include/uapi/asm/socket.h | 2 ++ > arch/sparc/include/uapi/asm/socket.h | 2 ++ > include/net/rps.h | 13 +++++++++++++ > include/net/sock.h | 1 + > include/uapi/asm-generic/socket.h | 2 ++ > net/core/sock.c | 8 ++++++++ > 8 files changed, 32 insertions(+) > > diff --git a/include/net/rps.h b/include/net/rps.h > index e33c6a2fa8bb..5afa48868236 100644 > --- a/include/net/rps.h > +++ b/include/net/rps.h > @@ -98,6 +98,13 @@ static inline void _sock_rps_record_flow(const struct sock *sk) > * [1] : sk_state and sk_prot are in the same cache line. > */ > if (sk->sk_state == TCP_ESTABLISHED) { > + /* SO_NO_RFS: application asked us to never steer this flow. > + * Tested after sk_state so the common case stays on one > + * cache line. > + */ Avoid verbose comments. Bots comment a lot more than kernel style. Also arguably incorrect as TCP_ESTABLISHED is the common case. > + if (unlikely(sock_flag(sk, SOCK_NO_RFS))) > + return; > + > /* This READ_ONCE() is paired with the WRITE_ONCE() > * from sock_rps_save_rxhash() and sock_rps_reset_rxhash(). > */ > @@ -111,6 +118,12 @@ static inline void _sock_rps_delete_flow(const struct sock *sk) > rps_tag_ptr tag_ptr; > u32 hash, index; > > + /* Never recorded, so never clear a slot that may belong to > + * another flow. Never is too strong here: can be set during socket lifetime. Even if it had been correct, still another example of unnecessary verbosity. > + */ > + if (sock_flag(sk, SOCK_NO_RFS)) > + return; > + Both here and _sock_rfs_record_flow: probably should be in their callers, like the other precondition check rfs_is_needed. > hash = READ_ONCE(sk->sk_rxhash); Optionally maybe also skip writing sk_rxhash if this is the only user. > if (!hash) > return;