updates

Signed-off-by: Daman Arora <aroradaman@gmail.com>

Author: aroradaman

keps/sig-network/4963-kube-proxy-services-acceleration/README.md

@@ -74,15 +74,20 @@ This KEP proposes utilizing the flowtable infrastructure within the Linux kernel
 
 ## Motivation
 
-Kube-proxy manages Service traffic by manipulating iptables/nftables rules. This approach can introduce performance overhead, particularly for services with high throughput or a large number of connections. The kernel's flowtables offer a more efficient alternative for handling established connections, bypassing the standard netfilter processing pipeline.
+Every packet entering the Linux kernel is evaluated against all rules attached to the netfilter hooks, even for established connections. These rules may be added by CNIs, system administrators, firewalls, or kube-proxy, and together they define how packets are filtered, routed, or rewritten. As a result, packets continue to traverse the full netfilter processing path, which can add unnecessary overhead for long-lived or high-throughput connections.
+
+A connection becomes established only after the initial packets successfully pass through all applicable rules without being dropped or rejected. Once established, packets associated with a Kubernetes service can be offloaded to the kernel fast path using flowtables. This allows subsequent service packets to bypass the full netfilter stack, accelerating kube-proxy traffic and reducing CPU usage.
+
 
 ### Goals
 
-- Provide an option for kube-proxy users to enable Service traffic acceleration.
+- Provide an option for kube-proxy users to enable traffic acceleration for TCP and UDP services.
 
 ### Non-Goals
 
 - Separation of Concerns: Kube-proxy's primary responsibility is to manage Service traffic. Extending the flowtable offloading functionality to non-Service traffic will potentially introduce unintended side effects. It's better to keep the feature focused on its core purpose.
+- Supporting service traffic acceleration for iptables and ipvs backends.
+- Supporting service traffic acceleration for SCTP services.
 
 ## Proposal
 
@@ -155,14 +160,13 @@ As a cluster administrator managing a cluster where services typically handle sm
 
 ### Risks and Mitigations
 
-Once the network traffic moves to the fastpath it completely bypass the kernel stack, so
-any other network applications that depend on the packets going through the network stack (monitoring per example) will not be able to see the connection details. The feature will only apply the fastpath based on a defined threshold, that will also allow to disable the feature.
+Moving network traffic to the fastpath causes packets to bypass the standard netfilter hooks after the ingress hook. Flowtables operate at the ingress hook, and packets still traverse taps, so tools like tcpdump and Wireshark will continue to observe traffic. However, any applications that rely on hooks or rules evaluated after the ingress hook may not observe or process these packets as expected. To mitigate this, fastpath offload will be applied selectively based on a configurable threshold, and users will have the option to disable the feature entirely.
 
 Flowtables netfilter infrastructure is not well documented and we need to validate assumptions to avoid unsupported or suboptimal configurations. Establishing good relations and involve netfilter maintainers in the design will mitigate these possible problems.
 
 ## Design Details
 
-This feature will only work with kube-proxy nftables mode. We will add a new configuration option to kube-proxy to enable Service traffic offload based on a number of packets threshold per connection.
+This feature will only work with kube-proxy nftables mode for TCP and UDP traffic. We will add a new configuration option to kube-proxy to enable Service traffic offload based on a number of packets threshold per connection.
 
 The packet threshold approach offers several advantages over the [alternatives](#alternatives):
 
@@ -299,11 +303,19 @@ Kube-proxy will insert a rule to offload all Services established traffic in the
 		tx.Add(&knftables.Rule{
 			Chain: filterForwardChain,
 			Rule: knftables.Concat(
-				"ct original", ipX, "daddr", "@", clusterIPsSet,
-				"ct packets >", proxier.fastpathPacketThreshold,
+                "ct packets >", proxier.fastpathPacketThreshold,
+				"ct original", ipX, "daddr", "@", serviceIPsSet,
 				"flow offload", "@", serviceFlowTable,
 			),
 		})
+        tx.Add(&knftables.Rule{
+            Chain: filterForwardChain,
+            Rule: knftables.Concat(
+                "ct packets >", proxier.fastpathPacketThreshold,
+                "ct original", "th dport", "@", servicePortsSet,
+                "flow offload", "@", serviceFlowTable,
+            ),
+        })
 	}
 ```
 

keps/sig-network/4963-kube-proxy-services-acceleration/kep.yaml

@@ -2,6 +2,7 @@ title: Kube-proxy Services Acceleration
 kep-number: 4963
 authors:
   - "@aojea"
+  - "@aroradaman"
 owning-sig: sig-network
 status: implementable
 creation-date: 2024-11-14
@@ -22,9 +23,9 @@ latest-milestone: "v1.33"
 
 # The milestone at which this feature was, or is targeted to be, at each stage.
 milestone:
-  alpha: "v1.33"
-  beta: "v1.34"
-  stable: "v1.35"
+  alpha: "v1.35"
+  beta: "v1.36"
+  stable: "v1.37"
 
 # The following PRR answers are required at alpha release
 # List the feature gate name and the components for which it must be enabled
@@ -36,4 +37,4 @@ disable-supported: true
 
 # The following PRR answers are required at beta release
 metrics:
-  - count_accelerated_connections_total
+  - kubeproxy_accelerated_connections_count_total