Re: [PATCH nf-next] netfilter: conntrack: collect start time as early as possible

[Florian Westphal <fw@strlen.de>]

Pablo Neira Ayuso <pablo@netfilter.org> 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.