Re: [PATCH net-next v3 0/3] net: tunnel: introduce noref xmit flows for tunnels
From: Jakub Kicinski <kuba@kernel.org>
Date: 2025-09-24 23:31:16
On Wed, 24 Sep 2025 18:27:46 +0200 Marek Mietus wrote:
quoted
On Mon, 22 Sep 2025 13:06:19 +0200 Marek Mietus wrote:quoted
This patchset introduces new noref xmit helpers and incorporates them in the OpenVPN driver. A similar improvement can also be applied to other tunnel code in the future. The implementation for OpenVPN is a good starting point as it doesn't use the udp_tunnel_dst_lookup helper which adds some complexity.You're basically refactoring an API, it's fairly unusual to leave both APIs in place upstream. Unless the number of callers is really huge, say >100, or complexity very high. Not sure how others feel but IMHO you should try to convert all the tunnels.I'm introducing an opt-in API, which is useful in some cases, but not always as it optimizes flows that follow a specific pattern. Since this API is opt-in, there is no need to over-complicate code to integrate the new API. The current API is still retained and is not made redundant by the new API. Some tunnels may benefit from the new API with only minor complications, and should be modified in separate patchsets after this one.
My objection stands. Unless you have a reason why some tunnels need to ref the dst you should just convert all. Otherwise this is just technical debt you're pushing on posterity.
quoted
quoted
There are already noref optimizations in both ipv4 and ip6 (See __ip_queue_xmit, inet6_csk_xmit). This patchset allows for similar optimizations in udp tunnels. Referencing the dst_entry is now redundant, as the entire flow is protected under RCU, so it is removed. With this patchset, I was able to observe a 4% decrease in the total time for ovpn_udp_send_skb using perf.Please provide more meaningful perf wins. Relative change of perf in one function doesn't tell use.. well.. anything.Okay. Currently, I'm getting a consistent 2% increase in throughput on a VM, using iperf. Is this what I should mention in the next cover-letter?
Yes, that's much better! Some kind of average over multiple runs and/or stddev would be ideal.