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 4CAF12A5D for ; Fri, 17 Feb 2017 19:42:05 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2017 10:42:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,173,1484035200"; d="scan'208";a="935193138" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga003.jf.intel.com with ESMTP; 17 Feb 2017 10:42:03 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.38]) by IRSMSX108.ger.corp.intel.com ([169.254.11.173]) with mapi id 14.03.0248.002; Fri, 17 Feb 2017 18:42:02 +0000 From: "Ananyev, Konstantin" To: Olivier Matz , Jan Blunck CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization Thread-Index: AQHSdlXOvL8VQlbyOU+/T85mDKip26FcYNGAgA9pHoCAAD0PgIABJAiAgAAukACAAArJAIAASJ3g Date: Fri, 17 Feb 2017 18:42:01 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583F118DD7@irsmsx105.ger.corp.intel.com> References: <1485271173-13408-1-git-send-email-olivier.matz@6wind.com> <2601191342CEEE43887BDE71AB9772583F111A29@irsmsx105.ger.corp.intel.com> <20170216144807.7add2c71@platinum> <20170217115153.0afeb061@platinum> <20170217151708.20bf4a49@platinum> In-Reply-To: <20170217151708.20bf4a49@platinum> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] [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, 17 Feb 2017 18:42:05 -0000 Hi guys, > -----Original Message----- > From: Olivier Matz [mailto:olivier.matz@6wind.com] > Sent: Friday, February 17, 2017 2:17 PM > To: Jan Blunck > Cc: Ananyev, Konstantin ; dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC 0/8] mbuf: structure reorganization >=20 > Hi Jan, >=20 > On Fri, 17 Feb 2017 14:38:32 +0100, Jan Blunck > wrote: > > On Fri, Feb 17, 2017 at 11:51 AM, Olivier Matz > > wrote: > > > Hi Jan, > > > > > > On Thu, 16 Feb 2017 18:26:39 +0100, Jan Blunck > > > wrote: > > >> On Thu, Feb 16, 2017 at 2:48 PM, Olivier Matz > > >> wrote: > > >> > On Mon, 6 Feb 2017 18:41:27 +0000, "Ananyev, Konstantin" > > >> > wrote: > > >> >> > > > >> >> > The main changes are: > > >> >> > - reorder structure to increase vector performance on some > > >> >> > non-ia platforms. > > >> >> > - add a 64bits timestamp field in the 1st cache line > > >> >> > > >> >> Wonder why it deserves to be in first cache line? > > >> >> How it differs from seqn below (pure SW stuff right now). > > >> > > > >> > In case the timestamp is set from a NIC value, it is set in the > > >> > Rx path. So that's why I think it deserve to be located in the > > >> > 1st cache line. > > >> > > > >> > As you said, the seqn is a pure sw stuff right: it is set in a > > >> > lib, not in a PMD rx path. > > >> > > > >> > > >> If we talk about setting the timestamp value in the RX path this > > >> implicitly means software timestamps. Hardware timestamping usually > > >> works by letting the hardware inject sync events for coarse time > > >> tracking and additionally injecting fine granular per-packet ticks > > >> at a specific offset in the packet. Out of performance reasons I > > >> don't think it makes sense to extract this during the burst and > > >> write it into the mbuf again. > > > > > > From what I've understand, at least it does not work like this for > > > mellanox NICs: timestamp is a metadata attached to a rx packet. But > > > maybe they (and other NIC vendors interrested in the feature) can > > > confirm or not. > > > > > > > Mellanox NICs use a 48bit cycle counter split into a high and low > > part. To convert the cycle values into a timestamp you need to > > initialize and maintainer a timecounter that shifts the cycle count > > e.g. nanosecs. IIRC Mellanox doesn't generate explicit clock events > > but the cycle counter is large enough so that the user can easily > > maintain the timecounter by manually updating it. > > > > >> > > >> The problem with timestamps is to get the abstraction right wrt the > > >> correction factors and the size of the tick vs. the timestamp in > > >> the events injected. From my perspective it would be better to > > >> extract the handling of timestamp data into a library with PMD > > >> specific implementation of the conversions. That way the > > >> normalized timestamp values can get extracted if they are present. > > >> The mbuf itself would only indicate the presence of timestamp > > >> metadata in that case. > > > > > > I agree however that we need to properly define the meaning of this > > > field. My idea is: > > > > > > - the timestamp is in nanosecond > > > - the reference is always the same for a given path: if the > > > timestamp is set in a PMD, all the packets for this PMD will have > > > the same reference, but for 2 different PMDs (or a sw lib), the > > > reference would not be the same. > > > > > > I think it's enough for many use cases. > > > We can later add helpers to compare timestamps with different > > > references. > > > > 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. >=20 > Sorry, I don't really get your point. My comprehension of the timestamp > usage in a PMD is as following: >=20 > rx_burst(struct rxq *rxq, ...) > { > unsigned long factor =3D rxq->timestamp_factor; > unsigned port =3D rxq->port; >=20 > for each hw_desc { > m =3D rte_pktmbuf_alloc(rxq->pool); > m->len =3D hw_desc->len; > m->port =3D port; > m->ol_flags =3D > ... > m->timestamp =3D hw_desc->timestamp * factor; > } > ... > } >=20 > 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? Konstantin