On Fri, Oct 15, 2021 at 03:15:07AM -0700, Maciej Żenczykowski wrote: > On Fri, Oct 15, 2021 at 2:57 AM Florian Westphal <fw@xxxxxxxxx> wrote: > > Maciej Żenczykowski <zenczykowski@xxxxxxxxx> wrote: [...] > 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... This 2 events looks awkward to me, currently the model we have to report events is: - status bits are updated - flow has changed protocol state (TCP). but in this case, this is reporting a timer update. Timeout updates are not reported on events, since this would trigger too many events one per packet. What's the concern with delaying the IPS_ASSURED bit? By setting a lower timeout (30 second) my understanding is that this flow is less important to those that are in the stream state (120s), so these should also be candidate to be removed by early_drop. IIRC, the idea behind the stream concept is to reduce lifetime of shortlived UDP flows to release slots from the conntrack table earlier.
