Thread (7 messages) 7 messages, 2 authors, 2025-09-24

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help