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? 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.) 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. 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. Med venlig hilsen / kind regards - Morten Brørup
