From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Subject: Re: [RFC 0/8] mbuf: structure reorganization
Date: Fri, 24 Mar 2017 14:05:04 +0530
Message-ID: <20170324083400.io6h7vggj4xuljeg@localhost.localdomain>
References: <20170228102359.5d601797@platinum>
 <2601191342CEEE43887BDE71AB9772583F11EA11@irsmsx105.ger.corp.intel.com>
 <20170228115043.3f78ce52@platinum>
 <2601191342CEEE43887BDE71AB9772583F11EA96@irsmsx105.ger.corp.intel.com>
 <20170228132825.37586902@platinum>
 <2601191342CEEE43887BDE71AB9772583F11EE7A@irsmsx105.ger.corp.intel.com>
 <20170302174623.268592a7@platinum>
 <2601191342CEEE43887BDE71AB9772583FACBF10@IRSMSX109.ger.corp.intel.com>
 <20170320100036.086109e6@platinum>
 <2601191342CEEE43887BDE71AB9772583FAD3AC3@IRSMSX109.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Olivier Matz <olivier.matz@6wind.com>, Jan Blunck <jblunck@infradead.org>,
 "Richardson, Bruce" <bruce.richardson@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from NAM01-SN1-obe.outbound.protection.outlook.com
 (mail-sn1nam01on0073.outbound.protection.outlook.com [104.47.32.73])
 by dpdk.org (Postfix) with ESMTP id 4F947CF9E
 for <dev@dpdk.org>; Fri, 24 Mar 2017 09:35:24 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <2601191342CEEE43887BDE71AB9772583FAD3AC3@IRSMSX109.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>

On Wed, Mar 22, 2017 at 05:42:12PM +0000, Ananyev, Konstantin wrote:
> 
> Hi Olivier,
> 
> > > > > > > Another thing that doesn't look very convenient to me here -
> > > > > > > We can have 2 different values of timestamp (both normalized and not)
> > > > > > > and there is no clear way for the application to know which one is in
> > > > > > > use right now. So each app writer would have to come-up with his own
> > > > > > > solution.
> > > > > >
> > > > > > It depends:
> > > > > > - the solution you describe is to have the application storing the
> > > > > >   normalized value in its private metadata.
> > > > > > - another solution would be to store the normalized value in
> > > > > >   m->timestamp. In this case, we would need a flag to tell if the
> > > uint64_t dev_ops->timestamp_normalise(uint64_t timestamps);
> > 
> > I think (but I'm not sure, it's really out of scope of this patchset),
> > that the timestamp synchronization API will be more complex than that.
> > 
> > My current idea:
> > 
> > - a rte_timestamp library holds the normalization code
> > - we decide, for instance, that "normalized" means:
> >   - unit: nanosecond
> >   - based on system clock
> >   - reference: 0 = time when rte_timestamp_init() was called
> > - the PMD provides an API to get its clock
> > - the lib provides something like:
> >   uint64_t rte_timestamp_normalize(unsigned int port_id, uint64_t timestamp)
> > 
> > 
> > > 5. If the user wants to use that function it would be his responsibility to map mbuf
> > > to the port it was received from.
> > 
> > Yes, if the application uses a port_id, it's its responsibility to ensure
> > that this port exists.
> 
> Ok, so for 17.05 we'll have:
> - raw timestamp value inside mbuf
> - ol_flag bit to represenet is mbuf->timestamp value valid or not.
> That's it, correct?

Hi Olivier,

The ARM alignment fix also will be part of the v17.05. Right?

> 
> Konstantin