Re: [PATCH nf-next] netfilter: conntrack: add conntrack event timestamp

[Florian Westphal <fw@strlen.de>]

Florian Westphal <fw@strlen.de> wrote:
> Nadia Pinaeva writes:
>   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.
> 
> At this time, conntrack events can only get timestamped at recv time in
> userspace, so there can be some delay between the event being generated
> and the userspace process consuming the message.
> 
> There is sys/net/netfilter/nf_conntrack_timestamp, which adds a
> 64bit timestamp (ns resolution) that records start and stop times,
> but its not suited for this either, start time is the 'hashtable insertion
> time', not 'conntrack allocation time'.
> 
> There is concern that moving the start-time moment to conntrack
> allocation will add overhead in case of flooding, where conntrack
> entries are allocated and released right away without getting inserted
> into the hashtable.
> 
> Also, even if this was changed it would not with events other than
> new (start time) and destroy (stop time).
> 
> Pablo suggested to add new CTA_TIMESTAMP_EVENT, this adds this feature.
> The timestamp is recorded in case both events are requested and the
> sys/net/netfilter/nf_conntrack_timestamp toggle is enabled.

I was about to send v2 of this patch, but I found following comment in
ulogd source code (input/flow/ulogd_inpflow_NFCT.c):

 *      - add nanosecond-accurate packet receive timestamp of event-changing
 *        packets to {ip,nf}_conntrack_netlink, so we can have accurate IPFIX
 *        flowStart / flowEnd NanoSeconds.


I'm leaning towards reworking this patch to replace ktime_get_real_ns()
by

ktime_to_ns(skb_tstamp_cond(skb, 1)))

so that the event carries the packet receive timestamp if that was
available or the current clock time as fallback.

Thoughts?  Otherwise I can ignore above comment and keep
ktime_get_real_ns() usage.