From mboxrd@z Thu Jan  1 00:00:00 1970
From: Olivier MATZ <olivier.matz@6wind.com>
Subject: Re: [PATCH 1/3] mbuf: embedding timestamp into the packet
Date: Tue, 24 Jan 2017 16:27:47 +0100
Message-ID: <20170124162747.5039bf93@glumotte.dev.6wind.com>
References: <1476369308-17021-1-git-send-email-olegk@mellanox.com>
 <1476369308-17021-2-git-send-email-olegk@mellanox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org
To: Oleg Kuporosov <olegk@mellanox.com>
Return-path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; Tue, 24 Jan 2017 16:27:54 +0100 (CET)
Received: by mail-wm0-f49.google.com with SMTP id c85so187106692wmi.1
 for <dev@dpdk.org>; Tue, 24 Jan 2017 07:27:54 -0800 (PST)
In-Reply-To: <1476369308-17021-2-git-send-email-olegk@mellanox.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Thu, 13 Oct 2016 14:35:06 +0000, Oleg Kuporosov <olegk@mellanox.com>
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 <olegk@mellanox.com>
> ---
>  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