Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > 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. Sure, its a question on definition as to what "flow start time" means. See below for yet another proposal. > 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? If I understood correctly its about using conntrack events + timestamp extension to get (passive) RTT measurements. > 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? I think cost depends on the clock source, hopefully most systems do not have a too expensive one nowadays. What about using skb_tstamp() first? If skb already had rx tstamp enabled, we'd get an even more accurate start time (packet arrival), even before ct got allocated.
