From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olivier MATZ <olivier.matz@6wind.com>
Subject: Re: [RFC 0/8] mbuf: structure reorganization
Date: Tue, 21 Feb 2017 10:53:49 +0100
Message-ID: <20170221105349.1fb36287@glumotte.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>
 <CALe+Z03QtPVmZ39bCaqGvmdsSipKftA_sZqc5K2F1WDjkEUrsg@mail.gmail.com>
 <20170217151708.20bf4a49@platinum>
 <2601191342CEEE43887BDE71AB9772583F118DD7@irsmsx105.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Olivier Matz <olivier.matz@6wind.com>, Jan Blunck
 <jblunck@infradead.org>, "dev@dpdk.org" <dev@dpdk.org>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48])
 by dpdk.org (Postfix) with ESMTP id 50F7858CF
 for <dev@dpdk.org>; Tue, 21 Feb 2017 10:53:57 +0100 (CET)
Received: by mail-wm0-f48.google.com with SMTP id v77so70960153wmv.0
 for <dev@dpdk.org>; Tue, 21 Feb 2017 01:53:57 -0800 (PST)
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F118DD7@irsmsx105.ger.corp.intel.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>

Hi Konstantin,

On Fri, 17 Feb 2017 18:42:01 +0000, "Ananyev, Konstantin"
<konstantin.ananyev@intel.com> wrote:
> Hi guys,
> 
> > > My point is that I still doubt that it belongs into the first
> > > cacheline. It requires accessing other structures for converting
> > > into nanoseconds anyway. Optimally I would like to see this
> > > happening on access instead but if that isn't achievable at least
> > > in a second step.  
> > 
> > Sorry, I don't really get your point. My comprehension of the
> > timestamp usage in a PMD is as following:
> > 
> > rx_burst(struct rxq *rxq, ...)
> > {
> > 	unsigned long factor = rxq->timestamp_factor;
> > 	unsigned port = rxq->port;
> > 
> > 	for each hw_desc {
> > 		m = rte_pktmbuf_alloc(rxq->pool);
> > 		m->len = hw_desc->len;
> > 		m->port = port;
> > 		m->ol_flags =
> > 		...
> > 		m->timestamp = hw_desc->timestamp * factor;
> > 	}
> > 	...
> > }
> > 
> > In that case, I think it deserves to be in the 1st cache line.  
> 
> So you are saying that:
> - for some HW that DPDK supports (mlx?) timestamp information
> Is available in HW RX descriptor
> - and as soon timestamp field will be available in mbuf, you plan
> to populate it using this HW RXD field.
> Is that so?

Yes, that's what I'm seeing in mellanox's patchset:
http://dpdk.org/ml/archives/dev/2016-October/048810.html

Do you know if Intel has plans to support some sort of timestamp using
this timestamp field?


Thanks,
Olivier