Re: [PATCH netfilter] netfilter: conntrack: udp: generate event on switch to stream timeout

On Fri, Oct 15, 2021 at 2:57 AM Florian Westphal [off-list ref] wrote:

Maciej Żenczykowski [off-list ref] wrote:

quoted

quoted

Hm, I still don't understand why do you need this extra 3rd
update/assured event event. Could you explain your usecase?

Currently we populate a flow offload array on the assured event, and
thus the flow in both directions starts bypassing the kernel.
Hence conntrack timeout is no longer automatically refreshed - and
there is no opportunity for the timeout to get bumped to the stream
timeout of 120s - it stays at 30s.
We periodically (every just over 60-ish seconds) check whether packets
on a flow have been offloaded, and if so refresh the conntrack
timeout.  This isn't cheap and we don't want to do it even more often.
However this 60s cycle > 30s non-stream udp timeout, so the kernel
conntrack entry expires (and we must thus clear out the flow from the
offload).  This results in a broken udp stream - but only on newer
kernels.  Older kernels don't have this '2s' wait feature (which makes
a lot of sense btw.) but as a result of this the conntrack assured
event happens at the right time - when the timeout hits 120s (or 180s
on even older kernels).

By generating another assured event when the udp stream is 'confirmed'
and the timeout is boosted from 30s to 120s we have an opportunity to
ignore the first one (with timeout 30) and only populate the offload
on the second one (with timeout 120).

I'm not sure if I'm doing a good job of describing this.  Ask again if
it's not clear and I'll try again.

Thanks for explaining, no objections to this from my side.

Do you think it makes sense to just delay setting the ASSURED bit
until after the 2s period?

That would work for this particular use case.... but I don't know if
it's a good idea.
I did of course think of it, but the commit message seemed to imply
there's a good reason to set the assured bit earlier rather than
later...

A udp flow becoming bidirectional seems like an important event to
notify about...
Afterall, the UDP flow might become a stream 29 seconds after it
becomes bidirectional...
That seems like a pretty long time (and it's user configurable to be
even longer) to delay the notification.

I imagine the pair of you know best whether 2 events or delay assured
event until stream timeout is applied makes more sense...

- Maciej