On Fri, Oct 15, 2021 at 2:57 AM Florian Westphal <fw@xxxxxxxxx> wrote: > > Maciej Żenczykowski <zenczykowski@xxxxxxxxx> wrote: > > > 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
