On Tue, Oct 29, 2024 at 08:16:24AM +0100, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > On Sat, Oct 26, 2024 at 12:50:13PM +0200, Florian Westphal wrote: > > > Sample start time at allocation time, not when the conntrack entry > > > is inserted into the hashtable. > > > > Back at the time, long time ago, I remember to have measured a > > performance impact on this. > > You mean when enabling timestamp + conntracks get dropped before > confirm, correct? Yes. > > > In most cases this makes very little difference, but there are > > > cases where there is significant delay beteen allocation and > > > confirmation, e.g. when packets get queued to userspace. > > > > I delayed this to insertion time because packet could dropped before, > > rendering this conntrack timestamp useless? There is no event > > reporting for conntrack that never get confirmed. > > Sure, but the "issue" is that the reported start time doesn't account > for a possible delay. I did not measure huge delta before/after this > patch but if you have e.g. nfqueue in between alloc+confirm then the > start timestamp will account for that delay after this patch. I see. I think the question is what this start timestamp is. For me, it is the start time since the conntrack is _confirmed_ which is what we expose to userspace via ctnetlink and /proc interface. Is this user trying to trying to profile nfqueue? Why does this user assume conntrack allocation time is the right spot to push the timestamp on the ct? On top of this, at that time I made this, I measured ~20-25% performance drop to get this accurate timestamp, probably this is cheaper now in modern equipment?
