Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization

[Olivier Matz <olivier.matz@6wind.com>]

On Tue, 21 Feb 2017 22:51:00 +0100, Morten Brørup
<mb@smartsharesystems.com> 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