From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 24B0E4CE4 for ; Tue, 24 Jan 2017 16:27:54 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id c85so187106692wmi.1 for ; Tue, 24 Jan 2017 07:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=nwHoCksPJWILTHSo4yLPfwVC6+0k9Fs18sINquMlXFs=; b=dxHGr02aacFkaCVD7B6/EYQWxDZAduKSetqnKPgiuxGNLk696cCSg2tmEoCbWJTdLX elCFnXIY3MK5BqG6Y8gDz/XKoVu6dVkGH4lEC7GNP7ZVWtYyfkI5vLw5Tz6Fxr96NCSL Ymh56l7DeSmFqI/dLEZowoUs+xyjxsCm1oxaMaMO3nDasUDQSzBURxMo4HUJD2w7qNjd r5he4GGUKzbCRJYokdbB82ReHXxp6wYBWZMm2M0WdUJZ3UyBOEbI7bFpkNNyF8i2l7Co q+Ottrl1X+Ltbde0/9MLVd/LZR7zH5g6a8nVsrw2dIq5h9cWYOSdldpz152vXHC1Aiou Wo9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=nwHoCksPJWILTHSo4yLPfwVC6+0k9Fs18sINquMlXFs=; b=YmPyczQq7X5QkxyDWa1FUIdE+sKxeS2Bv/TYXslKz76f89t7WOqUb9985Mr29FmLD8 G3NpZEXjyRXg4RHyYE7AysyaxUD5s1xCiMgO2hV5Uly8Wue/lnrbIPKPtzO4AOT8XcA1 E3xmZrkDpk/2pUEpoqw0sU40E51YfZGXcZKXnJHys4piuZxNXSeSCWczWOBEEYdwPo/j SUNu6sSwTsI4pXy9qohZL+od3PwzijBLTNxdgfuloG/Mu/SFP7N0REMvaYA4cqv/Wof/ ipP7pm/NRNYmtOaeJt2cWhHJv1uwN4nR4hPlLV9XGLx9ojh0400TnkhgjnC5u0e3/or9 vPeQ== X-Gm-Message-State: AIkVDXKwWKvNrunL0FmGCmR9scKe5eb2MMfdk0GV/oOnTtVujvnsmUJGPefdMu4Z5ygZfEmh X-Received: by 10.28.105.68 with SMTP id e65mr12741106wmc.44.1485271673819; Tue, 24 Jan 2017 07:27:53 -0800 (PST) Received: from glumotte.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id x39sm20437607wrb.3.2017.01.24.07.27.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Jan 2017 07:27:53 -0800 (PST) From: Olivier MATZ X-Google-Original-From: Olivier MATZ Date: Tue, 24 Jan 2017 16:27:47 +0100 To: Oleg Kuporosov Cc: dev@dpdk.org Message-ID: <20170124162747.5039bf93@glumotte.dev.6wind.com> In-Reply-To: <1476369308-17021-2-git-send-email-olegk@mellanox.com> References: <1476369308-17021-1-git-send-email-olegk@mellanox.com> <1476369308-17021-2-git-send-email-olegk@mellanox.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 15:27:54 -0000 On Thu, 13 Oct 2016 14:35:06 +0000, 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. > > Signed-off-by: Oleg Kuporosov > --- > lib/librte_mbuf/rte_mbuf.h | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > index 23b7bf8..1e1f2ed 100644 > --- a/lib/librte_mbuf/rte_mbuf.h > +++ b/lib/librte_mbuf/rte_mbuf.h > @@ -851,8 +851,7 @@ struct rte_mbuf { > > uint32_t seqn; /**< Sequence number. See also > rte_reorder_insert() */ > - /** Outer VLAN TCI (CPU order), valid if > PKT_RX_QINQ_STRIPPED is set. */ > - uint16_t vlan_tci_outer; > + uint64_t timestamp; /**< Packet's timestamp, usually > in ns */ > /* second cache line - fields only used in slow path or on > TX */ MARKER cacheline1 __rte_cache_min_aligned; > @@ -885,6 +884,9 @@ struct rte_mbuf { > }; > }; > > + /** Outer VLAN TCI (CPU order), valid if > PKT_RX_QINQ_STRIPPED is set. */ > + uint16_t vlan_tci_outer; > + > /** Size of the application private data. In case of an > indirect > * mbuf, it stores the direct mbuf private data size. */ > uint16_t priv_size; FYI, I posted a RFC patchset that introduces the timestamp field in the mbuf for v17.05: http://dpdk.org/ml/archives/dev/2017-January/056187.html Regards, Olivier