From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Blunck <jblunck@infradead.org>
Subject: Re: [RFC 0/8] mbuf: structure reorganization
Date: Fri, 17 Feb 2017 14:51:57 +0100
Message-ID: <CALe+Z00doV3Ar7AWTVEwUCpU7GEwh2k=cs65NjZ+ET-boJVYAA@mail.gmail.com>
References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com>
 <2601191342CEEE43887BDE71AB9772583F111A29@irsmsx105.ger.corp.intel.com>
 <20170216144807.7add2c71@platinum>
 <CALe+Z00Y_=4rsAjTeyaEzKFqtuMb6HMRUEUDL2LveJx6bWL-dA@mail.gmail.com>
 <20170217115153.0afeb061@platinum>
 <20170217124954.GO23344@autoinstall.dev.6wind.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Olivier Matz <olivier.matz@6wind.com>,
 "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>
To: =?UTF-8?Q?N=C3=A9lio_Laranjeiro?= <nelio.laranjeiro@6wind.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49])
 by dpdk.org (Postfix) with ESMTP id 40E88201
 for <dev@dpdk.org>; Fri, 17 Feb 2017 14:51:58 +0100 (CET)
Received: by mail-wm0-f49.google.com with SMTP id c85so15623964wmi.1
 for <dev@dpdk.org>; Fri, 17 Feb 2017 05:51:58 -0800 (PST)
In-Reply-To: <20170217124954.GO23344@autoinstall.dev.6wind.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Fri, Feb 17, 2017 at 1:49 PM, N=C3=A9lio Laranjeiro
<nelio.laranjeiro@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@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.