From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier Matz Subject: Re: [RFC 0/8] mbuf: structure reorganization Date: Fri, 24 Mar 2017 14:35:15 +0100 Message-ID: <20170324143515.57e6299a@platinum> 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> <20170324083400.io6h7vggj4xuljeg@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Cc: "Ananyev, Konstantin" , Jan Blunck , "Richardson, Bruce" , "dev@dpdk.org" To: Jerin Jacob Return-path: Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com [209.85.128.181]) by dpdk.org (Postfix) with ESMTP id 2147ED003 for ; Fri, 24 Mar 2017 14:40:23 +0100 (CET) Received: by mail-wr0-f181.google.com with SMTP id y90so1991666wrb.0 for ; Fri, 24 Mar 2017 06:40:23 -0700 (PDT) In-Reply-To: <20170324083400.io6h7vggj4xuljeg@localhost.localdomain> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Jerin, On Fri, 24 Mar 2017 14:05:04 +0530, Jerin Jacob wrote: > On Wed, Mar 22, 2017 at 05:42:12PM +0000, Ananyev, Konstantin wrote: > >=20 > > Hi Olivier, > > =20 > > > > > > > > Another thing that doesn't look very convenient to me here - > > > > > > > > We can have 2 different values of timestamp (both normalize= d 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 wit= h his own > > > > > > > > solution. =20 > > > > > > > > > > > > > > It depends: > > > > > > > - the solution you describe is to have the application storin= g 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 =20 > > > > uint64_t dev_ops->timestamp_normalise(uint64_t timestamps); =20 > > >=20 > > > 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. > > >=20 > > > My current idea: > > >=20 > > > - a rte_timestamp library holds the normalization code > > > - we decide, for instance, that "normalized" means: > > > - unit: nanosecond > > > - based on system clock > > > - reference: 0 =3D 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 tim= estamp) > > >=20 > > > =20 > > > > 5. If the user wants to use that function it would be his responsib= ility to map mbuf > > > > to the port it was received from. =20 > > >=20 > > > Yes, if the application uses a port_id, it's its responsibility to en= sure > > > that this port exists. =20 > >=20 > > 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? =20 >=20 > Hi Olivier, >=20 > The ARM alignment fix also will be part of the v17.05. Right? It's in this patchset, planned for v17.05. =46rom what I see, there is no strong opposition to the patchset, so it should go in. (note, the v1 is here: http://dpdk.org/ml/archives/dev/2017-March/059693.ht= ml) If you (and others) have time to test or review, that may help to integrate it faster. Regards, Olivier