On Tue, 21 Feb 2017 22:51:00 +0100, Morten Brørup
[off-list ref] wrote:

Regarding m->timestamp I have previously argued for keeping it NIC
specific, and not normalizing it. But I have changed my mind:
Normalizing it makes gives the user the ability to transparently swap
out a NIC from one vendor with one from another vendor. And with a
hardware timestamp from the NIC, the normalization only involves
multiplying by a constant factor, as Olivier pointed out previously.
So if the resolution is high enough, a normalized value is
preferable. 1 ns is roughly 10 bytes at 100 Gbit/s, so I suppose a
resolution of 1 ns suffices.

But how about NICs without hardware timestamps...

1. Are their PMDs supposed to set the timestamp or not, and are they
supposed to ensure that two packets received by the same port do not
carry the same timestamp?

The timestamp would only be set if the user asks for it through an
ethdev API. For NICs that do not support timestamps, the PMD can either
not support it, or implement it in software. I don't think they should
ensure that two packets do not carry the same timestamp. It depends on
the unit, and on the precision of the measure.

2. And if the CPU clock frequency is not constant, normalizing a
software generated timestamp is not just a matter of multiplying the
CPU's cycle counter with a constant factor - which could be important
if the timestamps are used for some sort of metrics analysis. (I have
no knowledge about such use cases, I'm just mentioning potential
pitfalls here.)

Since timestamp is a time reference, its unit has to be a constant
clock. On the CPUs I know, even when the internal frequency is not
constant, there is a also time reference with a constant clock (ex:
the tsc on Intel).

I guess a lot of NICs aren't configured to provide packet timestamps,
so in order to avoid code duplication in a bunch of PMDs, a software
timestamping library (or common set of helper functions) might be
handy for the PMDs.

Yes

Furthermore, the timers on separate NICs will be unsynchronized
anyway (regardless if the timestamps are generated by hardware or
software), so the timestamps are out of order when considering
multiple ingress ports anyway.

Generally, I support the idea of making the somewhat exotic features
compile time optional. In that context, it is a question of defining
what is common, and what is exotic. But +1 to Jan's suggestion about
making it compile time optional for the PMDs to set the m->timestamp,
since they are probably not used by typical data plane packet
forwarding applications, and they cost a few instruction cycles for
each packet. Even though this cost is small, adding a more such
exotic features with small individual costs will eventually make
their total cost significant.

I don't agree. Having compile-time options is something we should try
to avoid (knowing the DPDK is also a set of libraries provided by
distros). If the timestamp can be enabled/disabled at port
initialization, I think the cost of the feature will be negligible (it
can be one test for a bulk of packets).


Olivier