On 6/3/2020 9:11 PM, Stephen Hemminger 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. >
When there is a way to get better precision timestamp from pcap, why not benefit from it. We can discuss switching to pcapng separately I think.
