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

[Jan Blunck]

On Thu, Feb 16, 2017 at 2:48 PM, Olivier Matz <olivier.matz at 6wind.com> wrote:
> On Mon, 6 Feb 2017 18:41:27 +0000, "Ananyev, Konstantin"
> <konstantin.ananyev at intel.com> wrote:
>> >
>> > The main changes are:
>> > - reorder structure to increase vector performance on some non-ia
>> >   platforms.
>> > - add a 64bits timestamp field in the 1st cache line
>>
>> Wonder why it deserves to be in first cache line?
>> How it differs from seqn below (pure SW stuff right now).
>
> In case the timestamp is set from a NIC value, it is set in the Rx
> path. So that's why I think it deserve to be located in the 1st cache
> line.
>
> As you said, the seqn is a pure sw stuff right: it is set in a lib, not
> in a PMD rx path.
>

If we talk about setting the timestamp value in the RX path this
implicitly means software timestamps. Hardware timestamping usually
works by letting the hardware inject sync events for coarse time
tracking and additionally injecting fine granular per-packet ticks at
a specific offset in the packet. Out of performance reasons I don't
think it makes sense to extract this during the burst and write it
into the mbuf again.

The problem with timestamps is to get the abstraction right wrt the
correction factors and the size of the tick vs. the timestamp in the
events injected. From my perspective it would be better to extract the
handling of timestamp data into a library with PMD specific
implementation of the conversions. That way the normalized timestamp
values can get extracted if they are present. The mbuf itself would
only indicate the presence of timestamp metadata in that case.