From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 196A16936 for ; Wed, 19 Oct 2016 12:16:17 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 19 Oct 2016 03:16:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,514,1473145200"; d="scan'208";a="1056022334" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga001.fm.intel.com with ESMTP; 19 Oct 2016 03:16:16 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.6]) by IRSMSX153.ger.corp.intel.com ([169.254.9.140]) with mapi id 14.03.0248.002; Wed, 19 Oct 2016 11:14:36 +0100 From: "Pattan, Reshma" To: Olivier Matz , Oleg Kuporosov CC: "Richardson, Bruce" , "Ananyev, Konstantin" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 1/3] mbuf: embedding timestamp into the packet Thread-Index: AQHSJV8ThfAmOPJOW0KOln5cWxpuAaCuUVSAgAFD5gA= Date: Wed, 19 Oct 2016 10:14:36 +0000 Message-ID: <3AEA2BF9852C6F48A459DA490692831F010AFE30@IRSMSX109.ger.corp.intel.com> References: <1476369308-17021-1-git-send-email-olegk@mellanox.com> <1476369308-17021-2-git-send-email-olegk@mellanox.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzRiN2EzM2QtMzA1Yi00YmQzLThiNjQtODQyZGE1ZjZiOWE2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjFSSlFkK2NSc05NZTEzelFkRTFXdDU4Vmp4aE9TQ0RybVRaYStJYTl3ZGM9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf: embedding timestamp into the packet X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 10:16:18 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz > Sent: Tuesday, October 18, 2016 4:44 PM > To: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf: embedding timestamp into the > packet >=20 >=20 >=20 > On 10/13/2016 04:35 PM, Oleg Kuporosov wrote: > > The hard requirement of financial services industry is accurate > > timestamping aligned with the packet itself. This patch is to satisfy > > this requirement: > > > > - include uint64_t timestamp field into rte_mbuf with minimal impact to > > throughput/latency. Keep it just simple uint64_t in ns (more than 580 > > years) would be enough for immediate needs while using full > > struct timespec with twice bigger size would have much stronger > > performance impact as missed cacheline0. > > > > - it is possible as there is 6-bytes gap in 1st cacheline (fast path) > > and moving uint16_t vlan_tci_outer field to 2nd cacheline. > > > > - such move will only impact for pretty rare usable VLAN RX stripping > > mode for outer TCI (it used only for one NIC i40e from the whole set = and > > allows to keep minimal performance impact for RX/TX timestamps. >=20 > This argument is difficult to accept. One can say you are adding a field = for a > pretty rare case used by only one NIC :) >=20 > Honestly, I'm not able to judge whether timestamp is more important than > vlan_tci_outer. As room is tight in the first cache line, your patch subm= ission is > the occasion to raise the question: how to decide what should be in the f= irst part > of the mbuf? There are also some other candidates for moving: m->seqn is = only > used in librte_reorder and it is not set in the RX part of a driver. >=20 > About the timestamp, it would be valuable to have other opinions, not onl= y > about the placement of the field in the structure, but also to check that= this API > is also usable for other NICs. >=20 > Have you measured the impact of having the timestamp in the second part o= f > the mbuf? >=20 > Changing the mbuf structure should happen as rarely as possible, and we h= ave to > make sure we take the correct decisions. I think we will discuss this at = dpdk > userland 2016. >=20 >=20 I just read this mail chain, to make every one aware again, I am emphasizin= g on the point that I am also adding new "time_arraived" field=20 to mbuf struct as part of below 17.02 Road map item.=20 " Extended Stats (Latency and Bit Rate Statistics): Enhance the Extended NI= C Stats (Xstats) implementation to support the collection and reporting of = latency and bit rate measurements. Latency statistics will include min, max= and average latency, and jitter. Bit rate statistics will include peak and= average bit rate aggregated over a user-defined time period. This will be = implemented for IXGBE and I40E." Adding new field " time_arrived" to the 2nd cache line of rte_mbuf struct= to mark the packet arrival time for latency measurements.=20 Adding this new filed to second cache line will not break the ABI. I implem= ented a new library to mark the time as part of rte_eth_rx callbacks and use that time stamp inside rte_eth_tx callback for measuring the latenc= y. Below is the latest v3 RFC patch for reference.=20 http://dpdk.org/dev/patchwork/patch/16655/ Comments are welcome. Thanks, Reshma