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

[Jan Blunck]

On Fri, Feb 24, 2017 at 3:00 PM, Olivier Matz <olivier.matz at 6wind.com> wrote:
>
> In my opinion, if we have the room in the first cache line, we should
> put it there. The only argument I see against is "we may find something
> more important in the future, and we won't have room for it in the
> first cache line". I don't feel we should penalize today's use cases for
> hypothetic future use cases.
>
>
>
>> 2. timestamp normalization point
>>      inside PMD RX vs somewhere later as user needs it (extra
>> function in dev_ops?).
>
> This point could be changed. My initial proposition tries to provide a
> generic API for timestamp. Let me remind it here:
>
> a- the timestamp is in nanosecond
> b- the reference is always the same for a given path: if the timestamp
>    is set in a PMD, all the packets for this PMD will have the same
>    reference, but for 2 different PMDs (or a sw lib), the reference
>    would not be the same.
>
> We may remove a-, and just have:
>  - the reference and the unit are always the same for a given path: if
>    the timestamp is set in a PMD, all the packets for this PMD will have
>    the same reference and unit, but for 2 different PMDs (or a sw lib),
>    they would not be the same.
>
> In both cases, we would need a conversion code (maybe in a library) if
> the application wants to work with timestamps from several sources. The
> second solution removes the normalization code in the PMD when not
> needed, it is probably better.

I agree.

>
> About having the timestamp in the packet data, I don't think it is
> a good solution for a generic API in DPDK. The timestamp is a metadata,
> it has to go in the mbuf metadata. The packet data should not be
> modified when the timestamp is enabled.

Good NICs already do that based on the packet type (e.g. NTP/PTP packets).

>
> But this would not prevent to have driver-specific features to do that.
> In that case, the application will be aware that it is using this
> specific driver and that it will receive a timestamp in the packet data.
>
> To summarize, the generic API could be:
> - an ethdev API to enable the timestamp in a PMD for received packets
> - a mbuf flag "timestamp present"
> - a mbuf 64b field to store the timestamp value
>
> Additionally, a driver-specific API can be added for a given PMD.
> Example:
> - the generic timestamp ethdev is disabled (or not supported)
> - a driver-specific feature "put timestamp in packet" is enabled
> It would have no additional cost compared to what we have today, since
> the timestamp in mbuf is not read/written.
>

Thanks for the writeup. This sounds like a reasonable approach to me.

Do you still want to call the 64bit field "timestamp" or rename it to
something neutral and document that it is used together with the mbuf
flags?