Re: [PATCH net 2/2] net: ioam6: mitigate the two reallocations problem

From: Justin Iurman
Date: Thu Jul 04 2024 - 07:59:04 EST


On 7/4/24 11:23, Paolo Abeni wrote:
On Tue, 2024-07-02 at 19:44 +0200, Justin Iurman wrote:
@@ -313,6 +316,10 @@ static int ioam6_output(struct net *net, struct sock *sk, struct sk_buff *skb)
orig_daddr = ipv6_hdr(skb)->daddr;
+ local_bh_disable();
+ dst = dst_cache_get(&ilwt->cache);
+ local_bh_enable();
+
switch (ilwt->mode) {
case IOAM6_IPTUNNEL_MODE_INLINE:

I now see that the way you coded patch 1/2 makes this one easier.

Hi Paolo,

Indeed. I originally had it as a single two-in-one patch, then I thought it would be clearer to split it up (looks like I was wrong, sorry).

Still I think it's quite doubtful to make the dst cache access
unconditional.

By unconditional, you mean to get the cache _before_ the switch, right? If so, that's indeed the only solution to provide it to the encap/inline function for the mitigation. However, I don't see it as a problem. Instead of having (a) call encap/fill function, then (b) get cache; you'd have (a) get cache, then (b) call encap/fill function. IMHO, it's the same. I'll re-run our measurements and compare them to our previous results in order to confirm getting the cache early does not impact performance. The only exception would be when skb_cow_head returns an error in encap/fill functions: in that case, getting the cache early would be a waste of time, but this situation suggests there is a problem already so it's probably fine.

Given the above I suggest to replace the 2 patches with a single one
moving the whole dst_cache logic before the switch statement.

Will do!

Also this does not address a functional issue, IMHO it's more a
performance improvement, could as well target net-next with no fixes
tag.

Hmmm, it's indeed OK to target net-next for patch #2 since it could be considered as an improvement (not really a functional issue per se). However, I'm not sure for patch #1. Wouldn't the kernel crash if not enough headroom was allocated (assuming no check is done before writing in the driver)?

WRT seg6 and rpl tunnels, before any patch, I think we first need
confirmation the problem is present there, too.

Ack. I'll try to run some tests to check that.

Thanks,
Justin

Thanks,

Paolo