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