Florian Westphal <fw@xxxxxxxxx> 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.
