* [PATCH net-next v9] net: reduce RFS/ARFS flow updates by checking LLC affinity
@ 2026-09-08 6:04 Chuang Wang
2026-09-08 20:36 ` Jakub Kicinski
0 siblings, 1 reply; 5+ messages in thread
From: Chuang Wang @ 2026-09-08 6:04 UTC (permalink / raw)
Cc: Chuang Wang, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Kuniyuki Iwashima, Willem de Bruijn,
Stanislav Fomichev, Hangbin Liu, Samiullah Khawaja,
Neal Cardwell, Roman Gushchin, netdev, linux-kernel
The current implementation of rps_record_sock_flow() updates the flow
table every time a socket is processed on a different CPU. In high-load
scenarios, especially with Accelerated RFS (ARFS), this triggers
frequent flow steering updates via ndo_rx_flow_steer.
For drivers like mlx5 that implement hardware flow steering, these
constant updates lead to significant contention on internal driver locks
(e.g., arfs_lock). This contention often becomes a performance
bottleneck that outweighs the steering benefits.
This patch introduces a cache-aware update strategy: the flow record is
only updated if the flow migrates across Last Level Cache (LLC)
boundaries. This minimizes expensive hardware reconfigurations while
preserving cache locality for the application. A new sysctl,
net.core.rps_feat_llc_affinity, is added to toggle this feature.
Additionally, export sock_rps_record_flow_hash() and
sock_rps_record_flow(). This resolves a symbol visibility compilation
error triggered by 'tun' using sock_rps_record_flow_hash() in
tun_flow_update() when CONFIG_TUN is built as a module. The same logic
is applied to SCTP, allowing it to use sock_rps_record_flow() safely
when built as a module.
Performance Test Results:
The patch was tested in a K8s environment (AMD CPU 128*2, 16-core Pod
with CPU pinning, mlx5 NIC) using brpc[1] echo_server and rpc_press.
rpc_press Commands:
for i in {1..8}; do
./rpc_press -proto=./echo.proto -method=example.EchoService.Echo
-server=<IP>:8000 -input='{"message":"hello"}'
-qps=0 -thread_num=512 -connection_type=pooled &
done
Monitor mlx5e_rx_flow_steer frequency:
/usr/share/bcc/tools/funccount -i 1 mlx5e_rx_flow_steer
Frequency of mlx5e_rx_flow_steer (via funccount[2]):
Before: ~335,000 counts/sec
After: ~23,000 counts/sec (reduced by ~93%)
System Metrics (after enabling rps_feat_llc_affinity):
CPU Utilization: 38% -> 32%
CPU PSI (Pressure Stall Information): 20% -> 10%
These results demonstrate that filtering updates by LLC affinity
significantly reduces driver lock contention and improves overall
CPU efficiency under heavy network load.
[1] https://github.com/apache/brpc/
[2] https://github.com/iovisor/bcc/blob/master/tools/funccount.py
Signed-off-by: Chuang Wang <nashuiliang@gmail.com>
---
v8 -> v9:
- fix errors in AI submissions by Simon Horman
v6 -> v8:
- simplify code and fix errors in AI submissions by Simon Horman
v5 -> v6:
- remove the multi-check 'old_val == new_val' by Xuan Zhuo
- fix 'modpost: "sock_rps_record_flow_hash" [drivers/net/tun.ko] undefined!' by kernel
test robot
- fix 'tcp.c:(.text+0x3e90): undefined reference to `sock_rps_record_flow'' by kernel test
robot
v4 -> v5: fix 'modpost: "rps_llc_check" [net/sctp/sctp.ko] undefined!' by kernel test robot
v3 -> v4: add rps_llc_check by Eric Dumazet
v2 -> v3: patch net -> net-next by Jakub Kicinski
v1 -> v2: add rps_feat_llc_affinity; add brpc tests
include/net/rps.h | 29 ++++++-----------
net/core/dev.c | 65 ++++++++++++++++++++++++++++++++++++++
net/core/sysctl_net_core.c | 7 ++++
3 files changed, 81 insertions(+), 20 deletions(-)
diff --git a/include/net/rps.h b/include/net/rps.h
index e33c6a2fa8bb..fc301ce3987d 100644
--- a/include/net/rps.h
+++ b/include/net/rps.h
@@ -12,6 +12,7 @@
extern struct static_key_false rps_needed;
extern struct static_key_false rfs_needed;
+extern struct static_key_false rps_feat_llc_affinity;
/*
* This structure holds an RPS map which can be of variable length. The
@@ -55,11 +56,14 @@ struct rps_sock_flow_table {
#define RPS_NO_CPU 0xffff
+bool rps_llc_check(u32 old_val, u32 new_val);
+
static inline void rps_record_sock_flow(rps_tag_ptr tag_ptr, u32 hash)
{
unsigned int index = hash & rps_tag_to_mask(tag_ptr);
u32 val = hash & ~net_hotdata.rps_cpu_mask;
struct rps_sock_flow_table *table;
+ u32 old_val;
/* We only give a hint, preemption can change CPU under us */
val |= raw_smp_processor_id();
@@ -68,7 +72,9 @@ static inline void rps_record_sock_flow(rps_tag_ptr tag_ptr, u32 hash)
/* The following WRITE_ONCE() is paired with the READ_ONCE()
* here, and another one in get_rps_cpu().
*/
- if (READ_ONCE(table[index].ent) != val)
+ old_val = READ_ONCE(table[index].ent);
+ if (old_val != val &&
+ (((old_val ^ val) & ~net_hotdata.rps_cpu_mask) || rps_llc_check(old_val, val)))
WRITE_ONCE(table[index].ent, val);
}
@@ -136,25 +142,8 @@ static inline bool rfs_is_needed(void)
#endif
}
-static inline void sock_rps_record_flow_hash(__u32 hash)
-{
-#ifdef CONFIG_RPS
- if (!rfs_is_needed())
- return;
-
- _sock_rps_record_flow_hash(hash);
-#endif
-}
-
-static inline void sock_rps_record_flow(const struct sock *sk)
-{
-#ifdef CONFIG_RPS
- if (!rfs_is_needed())
- return;
-
- _sock_rps_record_flow(sk);
-#endif
-}
+void sock_rps_record_flow_hash(__u32 hash);
+void sock_rps_record_flow(const struct sock *sk);
static inline void sock_rps_delete_flow(const struct sock *sk)
{
diff --git a/net/core/dev.c b/net/core/dev.c
index 290e0f099e6b..3a0dd1f98084 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5052,6 +5052,7 @@ struct static_key_false rps_needed __read_mostly;
EXPORT_SYMBOL(rps_needed);
struct static_key_false rfs_needed __read_mostly;
EXPORT_SYMBOL(rfs_needed);
+struct static_key_false rps_feat_llc_affinity __read_mostly;
static u32 rfs_slot(u32 hash, rps_tag_ptr tag_ptr)
{
@@ -5263,6 +5264,48 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
return cpu;
}
+/**
+ * rps_llc_check - determine if RPS flow table should be updated.
+ * @old_val: previous flow record value.
+ * @new_val: target flow record value.
+ *
+ * Return: true if the record needs an update, false otherwise.
+ */
+bool rps_llc_check(u32 old_val, u32 new_val)
+{
+ u32 old_cpu = old_val & net_hotdata.rps_cpu_mask;
+ u32 new_cpu = new_val & net_hotdata.rps_cpu_mask;
+
+ /*
+ * RPS LLC Affinity Feature:
+ * Reduce RFS/ARFS flow updates by checking LLC affinity.
+ *
+ * Frequent flow table updates can trigger constant hardware steering
+ * reconfigurations (e.g., ndo_rx_flow_steer), leading to significant
+ * contention on driver internal locks (like mlx5's arfs_lock).
+ *
+ * This strategy only updates the flow record if it migrates across LLC
+ * boundaries. This minimizes expensive hardware updates while preserving
+ * cache locality for the application.
+ */
+ if (static_branch_unlikely(&rps_feat_llc_affinity)) {
+ /* Force update if the recorded CPU is invalid or has gone offline */
+ if (old_cpu >= nr_cpu_ids || !cpu_active(old_cpu))
+ return true;
+
+ /*
+ * If CPUs do not share a cache, allow the update to prevent
+ * expensive remote memory accesses and cache misses.
+ */
+ if (!cpus_share_cache(old_cpu, new_cpu))
+ return true;
+
+ return false;
+ }
+
+ return true;
+}
+
#ifdef CONFIG_RFS_ACCEL
/**
@@ -5318,6 +5361,28 @@ static void rps_trigger_softirq(void *data)
#endif /* CONFIG_RPS */
+void sock_rps_record_flow_hash(__u32 hash)
+{
+#ifdef CONFIG_RPS
+ if (!rfs_is_needed())
+ return;
+
+ _sock_rps_record_flow_hash(hash);
+#endif
+}
+EXPORT_SYMBOL(sock_rps_record_flow_hash);
+
+void sock_rps_record_flow(const struct sock *sk)
+{
+#ifdef CONFIG_RPS
+ if (!rfs_is_needed())
+ return;
+
+ _sock_rps_record_flow(sk);
+#endif
+}
+EXPORT_SYMBOL(sock_rps_record_flow);
+
/* Called from hardirq (IPI) context */
static void trigger_rx_softirq(void *data)
{
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index 23310581f494..e13af75d9f25 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -555,6 +555,13 @@ static struct ctl_table net_core_table[] = {
.mode = 0644,
.proc_handler = rps_sock_flow_sysctl
},
+ {
+ .procname = "rps_feat_llc_affinity",
+ .data = &rps_feat_llc_affinity.key,
+ .maxlen = sizeof(rps_feat_llc_affinity.key),
+ .mode = 0644,
+ .proc_handler = proc_do_static_key
+ },
#endif
#ifdef CONFIG_NET_FLOW_LIMIT
{
--
2.47.3
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH net-next v9] net: reduce RFS/ARFS flow updates by checking LLC affinity
2026-09-08 6:04 [PATCH net-next v9] net: reduce RFS/ARFS flow updates by checking LLC affinity Chuang Wang
@ 2026-09-08 20:36 ` Jakub Kicinski
2026-09-13 3:49 ` chuang
0 siblings, 1 reply; 5+ messages in thread
From: Jakub Kicinski @ 2026-09-08 20:36 UTC (permalink / raw)
To: Chuang Wang
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Kuniyuki Iwashima, Willem de Bruijn, Stanislav Fomichev,
Hangbin Liu, Samiullah Khawaja, Neal Cardwell, Roman Gushchin,
netdev, linux-kernel
On Tue, 8 Sep 2026 14:04:00 +0800 Chuang Wang wrote:
> v8 -> v9:
> - fix errors in AI submissions by Simon Horman
I commented on v8 6 hours before you sent this.
Please pay more attention to what you're doing.
--
pw-bot: cr
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH net-next v9] net: reduce RFS/ARFS flow updates by checking LLC affinity
2026-09-08 20:36 ` Jakub Kicinski
@ 2026-09-13 3:49 ` chuang
2026-09-13 4:14 ` Eric Dumazet
0 siblings, 1 reply; 5+ messages in thread
From: chuang @ 2026-09-13 3:49 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Kuniyuki Iwashima, Willem de Bruijn, Stanislav Fomichev,
Hangbin Liu, Samiullah Khawaja, Neal Cardwell, Roman Gushchin,
netdev, linux-kernel
Hi, let me restructure the issues.
> 1) Also not sure why you're trying to touch RFS, the change only helps
aRFS and you could avoid bulk of the refactoring issues.
The scenario is similar to the one described in "[RFC] problems with
RFS on bRPC applications"[1].
I attempted to enable ARFS on a Mellanox CX-6 NIC. While it performs
well for simple workloads, performance degrades significantly when
running a bRPC[2] workload on a 2-node NUMA machine. After tracing, I
identified patterns that ARFS/RFS fails to handle efficiently:
- Multiple threads use epoll to read from the same socket, causing
frequent flow updates in sock_flow_table.
- Threads reading from the socket migrate frequently between CPUs.
I tested a PoC version using a bRPC service, utilizing funccount [3]
to monitor execution frequency and perf top to observe hotspots:
Before Patch
The mlx5e_rx_flow_steer frequency is over 380k/s, and queued_spin_lock
is a major hotspot (6.30% in perf top). The application also suffers
from a noticeable drop.
FUNC COUNT
mlx5e_rx_flow_steer 387594
FUNC COUNT
mlx5e_rx_flow_steer 390142
FUNC COUNT
mlx5e_rx_flow_steer 386694
FUNC COUNT
mlx5e_rx_flow_steer 389094
# perf top hotspot:
queued_spin_lock 6.30%
After Patch
The ARFS update frequency is significantly reduced. queued_spin_lock
is no longer a hotspot in perf top, and the application's overall
performance has improved.
FUNC COUNT
mlx5e_rx_flow_steer 43
FUNC COUNT
mlx5e_rx_flow_steer 9
FUNC COUNT
mlx5e_rx_flow_steer 207
FUNC COUNT
mlx5e_rx_flow_steer 26
> 2) You put a very fast path function out-of-line, why ?
The reason is that tun uses sock_rps_record_flow_hash(). When I moved
all rps_record_sock_flow and rps_record_cond modifications into
include/net/rps.h, it triggered the following compilation errors due
to symbol visibility:
ERROR: modpost: "cpus_share_cache" [drivers/net/tun.ko] undefined!
ERROR: modpost: "cpus_share_cache" [net/sctp/sctp.ko] undefined!
make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
This arises because the patch uses cpus_share_cache() to limit the
RFS/ARFS update frequency at the LLC level. To keep this in the fast
path, I could move cpus_share_cache() to
include/linux/sched/topology.h.
1: https://lore.kernel.org/netdev/CAHCEFEwToeQe_Ey8e=sf8fOmoobvrDCPsxw+hfUSoRawPX03+Q@mail.gmail.com/t/#u
2: https://github.com/apache/brpc
3: https://github.com/iovisor/bcc/blob/master/tools/funccount.py
On Wed, Sep 9, 2026 at 4:36 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 8 Sep 2026 14:04:00 +0800 Chuang Wang wrote:
> > v8 -> v9:
> > - fix errors in AI submissions by Simon Horman
>
> I commented on v8 6 hours before you sent this.
> Please pay more attention to what you're doing.
> --
> pw-bot: cr
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH net-next v9] net: reduce RFS/ARFS flow updates by checking LLC affinity
2026-09-13 3:49 ` chuang
@ 2026-09-13 4:14 ` Eric Dumazet
2026-09-14 12:01 ` chuang
0 siblings, 1 reply; 5+ messages in thread
From: Eric Dumazet @ 2026-09-13 4:14 UTC (permalink / raw)
To: chuang
Cc: Jakub Kicinski, David S. Miller, Paolo Abeni, Simon Horman,
Kuniyuki Iwashima, Willem de Bruijn, Stanislav Fomichev,
Hangbin Liu, Samiullah Khawaja, Neal Cardwell, Roman Gushchin,
netdev, linux-kernel
On Sat, Sep 12, 2026 at 8:50 PM chuang <nashuiliang@gmail.com> wrote:
>
> Hi, let me restructure the issues.
>
> > 1) Also not sure why you're trying to touch RFS, the change only helps
> aRFS and you could avoid bulk of the refactoring issues.
>
> The scenario is similar to the one described in "[RFC] problems with
> RFS on bRPC applications"[1].
>
> I attempted to enable ARFS on a Mellanox CX-6 NIC. While it performs
> well for simple workloads, performance degrades significantly when
> running a bRPC[2] workload on a 2-node NUMA machine. After tracing, I
> identified patterns that ARFS/RFS fails to handle efficiently:
>
> - Multiple threads use epoll to read from the same socket, causing
> frequent flow updates in sock_flow_table.
> - Threads reading from the socket migrate frequently between CPUs.
>
> I tested a PoC version using a bRPC service, utilizing funccount [3]
> to monitor execution frequency and perf top to observe hotspots:
>
> Before Patch
>
> The mlx5e_rx_flow_steer frequency is over 380k/s, and queued_spin_lock
> is a major hotspot (6.30% in perf top). The application also suffers
> from a noticeable drop.
>
> FUNC COUNT
> mlx5e_rx_flow_steer 387594
>
> FUNC COUNT
> mlx5e_rx_flow_steer 390142
>
> FUNC COUNT
> mlx5e_rx_flow_steer 386694
>
> FUNC COUNT
> mlx5e_rx_flow_steer 389094
>
> # perf top hotspot:
> queued_spin_lock 6.30%
>
> After Patch
>
> The ARFS update frequency is significantly reduced. queued_spin_lock
> is no longer a hotspot in perf top, and the application's overall
> performance has improved.
>
> FUNC COUNT
> mlx5e_rx_flow_steer 43
>
> FUNC COUNT
> mlx5e_rx_flow_steer 9
>
> FUNC COUNT
> mlx5e_rx_flow_steer 207
>
> FUNC COUNT
> mlx5e_rx_flow_steer 26
>
> > 2) You put a very fast path function out-of-line, why ?
>
> The reason is that tun uses sock_rps_record_flow_hash(). When I moved
> all rps_record_sock_flow and rps_record_cond modifications into
> include/net/rps.h, it triggered the following compilation errors due
> to symbol visibility:
>
> ERROR: modpost: "cpus_share_cache" [drivers/net/tun.ko] undefined!
> ERROR: modpost: "cpus_share_cache" [net/sctp/sctp.ko] undefined!
> make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
>
> This arises because the patch uses cpus_share_cache() to limit the
> RFS/ARFS update frequency at the LLC level. To keep this in the fast
> path, I could move cpus_share_cache() to
> include/linux/sched/topology.h.
Hmmm
If the LLC affinity check is performed in set_rps_cpu() inside
net/core/dev.c before triggering ndo_rx_flow_steer:
net/core/dev.c is built-in, so it can call cpus_share_cache() directly
without any module export issues.
sock_rps_record_flow() and sock_rps_record_flow_hash() in
include/net/rps.h remain 100% inline, retaining the zero-cost static
key NOP in the TCP/socket fast path.
No exports, no refactoring of tun.ko or sctp.ko, and no fast-path degradation.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH net-next v9] net: reduce RFS/ARFS flow updates by checking LLC affinity
2026-09-13 4:14 ` Eric Dumazet
@ 2026-09-14 12:01 ` chuang
0 siblings, 0 replies; 5+ messages in thread
From: chuang @ 2026-09-14 12:01 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jakub Kicinski, David S. Miller, Paolo Abeni, Simon Horman,
Kuniyuki Iwashima, Willem de Bruijn, Stanislav Fomichev,
Hangbin Liu, Samiullah Khawaja, Neal Cardwell, Roman Gushchin,
netdev, linux-kernel
On Sun, Sep 13, 2026 at 12:14 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Sat, Sep 12, 2026 at 8:50 PM chuang <nashuiliang@gmail.com> wrote:
> >
> > Hi, let me restructure the issues.
> >
> > > 1) Also not sure why you're trying to touch RFS, the change only helps
> > aRFS and you could avoid bulk of the refactoring issues.
> >
> > The scenario is similar to the one described in "[RFC] problems with
> > RFS on bRPC applications"[1].
> >
> > I attempted to enable ARFS on a Mellanox CX-6 NIC. While it performs
> > well for simple workloads, performance degrades significantly when
> > running a bRPC[2] workload on a 2-node NUMA machine. After tracing, I
> > identified patterns that ARFS/RFS fails to handle efficiently:
> >
> > - Multiple threads use epoll to read from the same socket, causing
> > frequent flow updates in sock_flow_table.
> > - Threads reading from the socket migrate frequently between CPUs.
> >
> > I tested a PoC version using a bRPC service, utilizing funccount [3]
> > to monitor execution frequency and perf top to observe hotspots:
> >
> > Before Patch
> >
> > The mlx5e_rx_flow_steer frequency is over 380k/s, and queued_spin_lock
> > is a major hotspot (6.30% in perf top). The application also suffers
> > from a noticeable drop.
> >
> > FUNC COUNT
> > mlx5e_rx_flow_steer 387594
> >
> > FUNC COUNT
> > mlx5e_rx_flow_steer 390142
> >
> > FUNC COUNT
> > mlx5e_rx_flow_steer 386694
> >
> > FUNC COUNT
> > mlx5e_rx_flow_steer 389094
> >
> > # perf top hotspot:
> > queued_spin_lock 6.30%
> >
> > After Patch
> >
> > The ARFS update frequency is significantly reduced. queued_spin_lock
> > is no longer a hotspot in perf top, and the application's overall
> > performance has improved.
> >
> > FUNC COUNT
> > mlx5e_rx_flow_steer 43
> >
> > FUNC COUNT
> > mlx5e_rx_flow_steer 9
> >
> > FUNC COUNT
> > mlx5e_rx_flow_steer 207
> >
> > FUNC COUNT
> > mlx5e_rx_flow_steer 26
> >
> > > 2) You put a very fast path function out-of-line, why ?
> >
> > The reason is that tun uses sock_rps_record_flow_hash(). When I moved
> > all rps_record_sock_flow and rps_record_cond modifications into
> > include/net/rps.h, it triggered the following compilation errors due
> > to symbol visibility:
> >
> > ERROR: modpost: "cpus_share_cache" [drivers/net/tun.ko] undefined!
> > ERROR: modpost: "cpus_share_cache" [net/sctp/sctp.ko] undefined!
> > make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
> >
> > This arises because the patch uses cpus_share_cache() to limit the
> > RFS/ARFS update frequency at the LLC level. To keep this in the fast
> > path, I could move cpus_share_cache() to
> > include/linux/sched/topology.h.
>
> Hmmm
>
> If the LLC affinity check is performed in set_rps_cpu() inside
> net/core/dev.c before triggering ndo_rx_flow_steer:
>
> net/core/dev.c is built-in, so it can call cpus_share_cache() directly
> without any module export issues.
>
> sock_rps_record_flow() and sock_rps_record_flow_hash() in
> include/net/rps.h remain 100% inline, retaining the zero-cost static
> key NOP in the TCP/socket fast path.
>
> No exports, no refactoring of tun.ko or sctp.ko, and no fast-path degradation.
Great idea, this indeed minimizes the changes.
Although there is a slight semantic difference compared to
net_hotdata.rps_sock_flow_table, meaning the CPU recorded in
`sock_flow_table[flow_id].ent` might not perfectly align with the one
used in `set_rps_cpu`. It is still the least intrusive approach.
How about the following simple change?
diff --git a/net/core/dev.c b/net/core/dev.c
index 3a0dd1f98084..7c513bf14221 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5236,7 +5236,7 @@ static int get_rps_cpu(struct net_device *dev,
struct sk_buff *skb,
* have been dequeued, thus preserving in order delivery.
*/
if (unlikely(tcpu != next_cpu) &&
- (tcpu >= nr_cpu_ids || !cpu_online(tcpu) ||
+ (tcpu >= nr_cpu_ids || !cpu_online(tcpu) ||
!rps_check_llc_affinity(tcpu, next_cpu) ||
((int)(READ_ONCE(per_cpu(softnet_data,
tcpu).input_queue_head) -
rflow->last_qtail)) >= 0)) {
tcpu = next_cpu;
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-09-14 12:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-08 6:04 [PATCH net-next v9] net: reduce RFS/ARFS flow updates by checking LLC affinity Chuang Wang
2026-09-08 20:36 ` Jakub Kicinski
2026-09-13 3:49 ` chuang
2026-09-13 4:14 ` Eric Dumazet
2026-09-14 12:01 ` chuang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®