On Wed, 3 Jun 2020 16:26:52 -0400
Vivien Didelot <vivien.dide...@gmail.com> wrote:
> On Wed, 3 Jun 2020 13:11:39 -0700, Stephen Hemminger
> <step...@networkplumber.org> wrote:
> > On Wed, 3 Jun 2020 18:50:51 +0100
> > Ferruh Yigit <ferruh.yi...@intel.com> wrote:
> >
> > > On 5/23/2020 6:21 PM, Vivien Didelot wrote:
> > > > When capturing packets into a PCAP file, DPDK currently uses
> > > > microseconds for the timestamp. But libpcap supports interpreting
> > > > tv_usec as nanoseconds depending on the file timestamp precision.
> > > >
> > > > To support this, use PCAP_TSTAMP_PRECISION_NANO when creating the
> > > > empty PCAP file as specified by PCAP_OPEN_DEAD(3PCAP) and implement
> > > > nanosecond timeval addition. This also ensures that the precision
> > > > reported by capinfos is nanoseconds (9).
> > >
> > > Overall good idea and patch looks good.
> > >
> > > Only concern is change in the libpcap dependency. Do you know which
> > > libpcap
> > > version supports 'PCAP_TSTAMP_PRECISION_NANO'?
> > > If a user of pcap PMD updates to latest DPDK and the environment doesn't
> > > have
> > > new version of the libpcap, this change will require an environment
> > > update and
> > > this may or may not be easy to do. That is why not sure if the updates
> > > require
> > > dependency change should wait for the LTS or not.
> > >
> > > Another things is the backward compatibility, as far as I understand the
> > > pcap
> > > file recorded with nanosecond precision can be read and parsed without
> > > problem
> > > by old application that doesn't know the nanosecond precision, but can you
> > > please confirm this?
> >
> > We should do pcapng instead of doing the pcap with nano timestamp.
> > My impression is that libpcap is a dormant project at this point, and the
> > finer grain timestamp is a hack that is only in some verisions.
> > That was one of the reasons pcapng started.
>
> Reading tv_usec as nanoseconds has been supported for years in libpcap.
>
> For instance PCAP_TSTAMP_PRECISION_NANO was introduced in ba89e4a18e8b
> ("Make timestamps precision configurable") on May 17, 2013.
>
> BTW, I have no clue what you mean by "floating point math".
It was a concern that 1e9 constant in C is interpreted as floating point.
But probably a non-issue. Have gotten burned in the past by floating point
creeping into DPDK (in Qos code).
