[ovs-dev] [PATCH] ipfix: implement flow caching and aggregation in exporter

[Ben Pfaff]

On Tue, Aug 20, 2013 at 02:34:40PM -0700, Romain Lenglet wrote:
> > From: "Ben Pfaff" <blp at nicira.com>
> > Perhaps on the same topic, this is the first time I've run into
> > timercmp(). ??It appears to be a nonstandard BSDism. ??Is there a reason
> > to use "struct timeval" instead of the "long long int as msecs from
> > the epoch" that we usually use in OVS? ??The latter is nice, when you
> > can use it, because arithmetic and relational operators are meaningful
> > and simple.
> 
> I send microsecond-granularity timestamps in the IPFIX flow records, and
> only timeval provides values at that granularity.
> Even though it doesn't matter much right now since timestamping is done
> in userspace and is imprecise, I'd like to be able to support precise
> (e.g. hardware, or at least kernelspace) timestamping later.

What's the motivation, that is, why does anyone care when a packet
arrived to a precision beyond 1 ms?

Anyway, if we really need this, I can think of a couple of
possibilities.  One is to define a timeval_compare_3way() in
timeval.[ch] that returns a strcmp()-like return value.  Another is to
use a long long int count of usecs instead of msecs.

> > 70 minutes is a curious number to choose as the maximum for
> > cache_active_timeout. ??Is this the maximum value allowed by IPFIX?
> 
> This is because I send timestamps as unsigned 32-bit deltas in
> microseconds.  This corresponds to ~71.5 minutes.
> That's a limit in the standard:
> http://tools.ietf.org/html/rfc5102#section-5.9
> 
> That constraint on the timestamps directly translates into a
> constraint on the cache timeouts.

That makes sense.  Thanks.