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

[Andrew Rybchenko]

On 02/17/2017 04:51 PM, Jan Blunck wrote:
> On Fri, Feb 17, 2017 at 1:49 PM, Nélio Laranjeiro
> <nelio.laranjeiro at 6wind.com> wrote:
>> Hi Olivier, Jan,
>>
>> On Fri, Feb 17, 2017 at 11:51:53AM +0100, Olivier Matz wrote:
>>> Hi Jan,
>>>
>>> On Thu, 16 Feb 2017 18:26:39 +0100, Jan Blunck <jblunck at infradead.org>
>>> wrote:
>>>> 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.
>>>  From what I've understand, at least it does not work like this for
>>> mellanox NICs: timestamp is a metadata attached to a rx packet. But
>>> maybe they (and other NIC vendors interrested in the feature) can
>>> confirm or not.
>> Olivier is right, this timestamp information is returned by the hardware
>> as the other fields describing the Rx packet (length, RSS hash, checksum
>> ...).  The PMD only copy it into the Mbuf.
>>
> Indeed, for Mellanox the timestamp is stored in the CQ entry.
> Solarflares write it relative to the packet header.

Confirmed. We have pseudo-header just before the packet itself and 
timestamp is put to pseudo-header by the HW.