On Tue, Aug 20, 2013 at 02:34:40PM -0700, Romain Lenglet wrote: > > From: "Ben Pfaff" <b...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
