From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <nelio.laranjeiro@6wind.com> Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 6807B952 for <dev@dpdk.org>; Fri, 17 Feb 2017 13:50:03 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id c85so14062683wmi.1 for <dev@dpdk.org>; Fri, 17 Feb 2017 04:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=WyMhjtOjdSlELslnjkLG28GaEeAIqMYOHyz5ja7tr0I=; b=wNJYE49+JOdnYPmz4+cTB7HZ2A3nQMOec1IVtNufeMg+CTMLmDRPYLGHBJ/koa9PJU CEf4o+UW7U9pnsWyB/xSeCZUdxEAkRCo8PCtJn4sqmXpHtpflbrTAJ5T9x9MzrywDJLk zz276qkRZBD8FsL6CSIAoFK9Bzi+4u1iNNDZUw0qXC5O9ziHtTazTczxNDozSxQKOXtO QDUHXATbnpV6kjHyljpubyEciKuQE87GGOC7qBn1Tu+Vdtyt7NAxNtTaj/ilwnM+yicD p8rTEZzPzcOYML/gqGTtTHUeuXOO/jPp/ONH4a/UwTB+hAtavLVWsAJCzFAYeaEUgeNa v2/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=WyMhjtOjdSlELslnjkLG28GaEeAIqMYOHyz5ja7tr0I=; b=hU6sc3oTUPxtZL8uC98RfwJFCc2O/6eQB/BxnPJsnlU2MZcVouCfJMKbHw/XFsnjYl LvWICkZUNpDdFCPHYktOqOGp+8tZLOJ4KGygEiyYodQhkdcmkGDmM2zigQSXUZaMp/CQ rE3N5gNV2a9ZtpXrdM9MpMqQgiwe64jXPxMfWYMR1kMSpB2czVVQlH8dRgMhp/Yfc40N feImU5QfSt2SHbOqtbHOzQN4DbY1/TBVgjye0FjkhvnWBx7gcln3k5pJ3MBXgyHQ90fW wypgdxGlGqN0Ps3mGSipMZ3UUcGSgOK4foYA9xxtoRB2GvUzuveHHaIUXA5A5+1riwZZ PzCg== X-Gm-Message-State: AMke39lGXyXIDtyIZG+2/ZvMHqrI0L0K9R1paWNkz68M4jn4GXN5s/erCg0D30BqIYKDX8rp X-Received: by 10.28.145.210 with SMTP id t201mr3173438wmd.42.1487335802967; Fri, 17 Feb 2017 04:50:02 -0800 (PST) Received: from autoinstall.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id n18sm12729069wra.64.2017.02.17.04.50.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 04:50:02 -0800 (PST) Date: Fri, 17 Feb 2017 13:49:54 +0100 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro <nelio.laranjeiro@6wind.com> To: Olivier Matz <olivier.matz@6wind.com> Cc: Jan Blunck <jblunck@infradead.org>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "dev@dpdk.org" <dev@dpdk.org> Message-ID: <20170217124954.GO23344@autoinstall.dev.6wind.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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170217115153.0afeb061@platinum> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list 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> X-List-Received-Date: Fri, 17 Feb 2017 12:50:03 -0000 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: > > On Thu, Feb 16, 2017 at 2:48 PM, Olivier Matz > > <olivier.matz@6wind.com> wrote: > > > On Mon, 6 Feb 2017 18:41:27 +0000, "Ananyev, Konstantin" > > > <konstantin.ananyev@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. > > 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. > > 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. > > I agree however that we need to properly define the meaning of this > field. My idea is: > > - the timestamp is in nanosecond > - 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. > > I think it's enough for many use cases. > We can later add helpers to compare timestamps with different > references. > > Regards, > Olivier Regards, -- Nélio Laranjeiro 6WIND