From mboxrd@z Thu Jan 1 00:00:00 1970 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) 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:in-reply-to:references :mime-version:content-transfer-encoding; bh=+wXqDF5Mk4irfMDajryGcVa4b4H3geL/MDwHL7uvpO4=; b=xLHH0W3lOjMzoaugIPNNMwN1hmuAiscU10lwQEk7ntROJGoA5jZejUlHOE7+SV3Nrg GcBEOMAYRqdNjmUUY4kmjHweFRH6hx7b7ncIRO/21XVBvbYXoLAAcaKlHj26KWBQXYlX l1F9Qdkyq6a/5DFOViFvOwTPdhMpnN68iK5hP3VNNzfj/D1L1ojy9R0cPBtwfxp+NDrJ wcj2F50omtxE6wp05E18XOuXvTf75rHSZieHRbk1Dp2gbMrzi0QJ/6+UM4Asx101sbgk RAmFjZ3pGq7VKtN9UR+QjKLdpTuJdyMBaO6UJPKC7Y2MsFzelZymFDspjJfWzb/+01NR mcUw== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=+wXqDF5Mk4irfMDajryGcVa4b4H3geL/MDwHL7uvpO4=; b=sze+YRe+g4HiZMeMoo7kgrYa6YJvSEGFtE47RX2GEQOlrUuXo3jRG4QuREVHdXqX5d 8By58GUaXbpdtXeZ2SfAux84GfRZTK3XzPhyxD90BIQptZRfk/q82wZIuBoy/7VOpIZZ 2RsbB+jmQzUVrnMHe+gco7AiMIrD0q9JMJ6u110JF5SMXJVUAEPtVgAfaUOU9q18VCdl GjwOTMgJMYMWa/2WZjkbpr4JkFWJZzmS5F1mgaNwyxmUvFa98iVzZ7lb2wBQkpSz+s1x g9xnkbFTIeDaSzMTcmk4mA3bPPYoJ9vrRkfymvoM1feCpOvRjLkGAFtVtzOx33wSyG6s g1yg== X-Gm-Message-State: AFeK/H0njZDvm4AF87fhBGwXmvJUgYgL3sfUZ8NsTnFdnJv5tvCnekg40CqSVy9dRncH9vwu X-Received: by 10.223.150.81 with SMTP id c17mr7821060wra.85.1490362517957; Fri, 24 Mar 2017 06:35:17 -0700 (PDT) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id e72sm2506126wma.5.2017.03.24.06.35.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 24 Mar 2017 06:35:17 -0700 (PDT) Date: Fri, 24 Mar 2017 14:35:15 +0100 From: Olivier Matz To: Jerin Jacob Cc: "Ananyev, Konstantin" , Jan Blunck , "Richardson, Bruce" , "dev@dpdk.org" Message-ID: <20170324143515.57e6299a@platinum> In-Reply-To: <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> <20170324083400.io6h7vggj4xuljeg@localhost.localdomain> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 13:40:23 -0000 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