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

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Nov 05, 2024 at 05:23:46PM +0100, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Sun, Nov 03, 2024 at 11:26:36AM +0100, Nadia Pinaeva wrote:
> > > I would like to provide some more context from the user point of view.
> > > I am working on a tool that allows collecting network performance
> > > metrics by using conntrack events.
> > > Start time of a conntrack entry is used to evaluate seen_reply
> > > latency, therefore the sooner it is timestamped, the better the
> > > precision is.
> > > In particular, when using this tool to compare the performance of the
> > > same feature implemented using iptables/nftables/OVS it is crucial
> > > to have the entry timestamped earlier to see any difference.
> > > 
> > > I am not sure if current timestamping logic is used for anything, but
> > > changing it would definitely help with my use case.
> > > I am happy to provide more details, if you have any questions.
> > 
> > The start time will be accurate. However, stop time will not be very
> > accurate: the netlink message containing the SEEN_REPLY status flag
> > can sit in the socket queue for some quite time until the userspace
> > software has a chance to receive and parse it.
> > 
> > @Florian: Would you explore instead to extend the nf_conntrack_ecache
> > infrastructure to allow to provide timestamps for netlink events? This
> > can be enabled via toggle. That would allow to have a more accurate
> > delta between two events messages.
> 
> Simply using current time in ctnetlink won't help, the NEW event comes
> after confirm.
> 
> It will help for SEEN_REPLY.  But I don't see how it will avoid this
> patch.

Not current time from ctnetlink, but use the ecache extension to store
the timestamp when the conntrack is allocated, ecache is already
initialized from init_conntrack() path.