From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by dpdk.org (Postfix) with ESMTP id 5F2172C09 for ; Mon, 17 Oct 2016 13:24:55 +0200 (CEST) Received: by mail-qk0-f174.google.com with SMTP id n189so227939839qke.0 for ; Mon, 17 Oct 2016 04:24:55 -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:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=U9diwfkYQXXFksvZgLsrN2FxN1+LtmcN/KQW70zK/ww=; b=V9341W2U3Jl4E5pl5Tpvfna2dxSbN2QSdUjliporICXU/Zp25s954L/OgTfLyi8p1f yYwQHwrwG0+r3yJ7HJxLiv3lL66d14LteVr0mDBtNNWTe2oFv3VQvUfvFTRDxkrEXxH1 YKAbkdzCd0xA0LTnZm6rfa5oipGA7kq5SS/mH2aXe43UOy8lQIIb7k/ZlJJpr6npqT4R 6GJB8T5gzjyrc4uHHIyGdqU09BPWQ9Wt2NyIrTdJfgwr06qTKNwXQIfNJUGgb0GQ7sBB alB3nTx2pneQjrumbg4brZHp5wXOx+YleetZOONz6Lr/2sd5Rq7vJEISaedkD4F34gf5 czwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=U9diwfkYQXXFksvZgLsrN2FxN1+LtmcN/KQW70zK/ww=; b=AsRL/FgyeJESzXBRrMLa1U4BAJp1IGS9JB6frhG5KWPqDtX0RiixgcSmTyv0ymkjRe WEMt2S1ACgVOg4WGvqhfvAutZVlkUqVqvTvatMlqUnIVoRtBS4DjVwBHzu1/vBOXlNQm 9amcydjuOGC8B3T/0GZrDgZf8iRzVuRFhpsVjlQ484blEwVJz10EOH4KHt4fUK6n9uTX OS6oF8jF6uIrphPuGQjjznmJq+UxE4ZFEZA3uxdwagynW8nHb9k4q8OVwql2gyGrMouI 9eieQAmyUvEqoigDpFB7X02Uc6Xu6vbUX6yHSFEctvZGQaGVUMaNZTRtnU2ghW9kO4Yc gyoA== X-Gm-Message-State: AA6/9Rmez/0s1THViX63IgGYfITa8N8vCV5tBaT0odjdheAS4EqCvYbRw5suMUfaQXzEh9+i X-Received: by 10.194.235.103 with SMTP id ul7mr12604952wjc.201.1476703494716; Mon, 17 Oct 2016 04:24:54 -0700 (PDT) Received: from autoinstall.dev.6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id us3sm52301714wjb.32.2016.10.17.04.24.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Oct 2016 04:24:54 -0700 (PDT) Date: Mon, 17 Oct 2016 13:24:48 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: Oleg Kuporosov Cc: dev@dpdk.org Message-ID: <20161017112448.GE9078@autoinstall.dev.6wind.com> References: <1476369308-17021-1-git-send-email-olegk@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1476369308-17021-1-git-send-email-olegk@mellanox.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH 0/3] Improvements in packet timestamps support 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: Mon, 17 Oct 2016 11:24:55 -0000 On Thu, Oct 13, 2016 at 02:35:05PM +0000, Oleg Kuporosov wrote: > > Hello DPDK Developers, > > Financial Services Industry which is pretty eager for several DPDK > features especially low latency while high throughput. The major issue > so far for increasing DPDK adoption there is requirement for several > applications (capturers, some trading algorithms) to support of accurate > timestamping. The requirement mostly came from regulatory and customers > need strictly follow it. > > Current state of timestamping support in DPDK looks pretty good: > - there is API to enable/disable timestamping acquisition by > rte_eth_timesync_enable/disable > - get timestamps itself by timesync_read_rx/tx_timestamp > - and even implementation of NTP IEEE 1588 for time synchronization > by rte_eth_timesync_adjust_read/write_time APIs. > > But it misses the most important feature there – embedding timestamp > in rte_mbuf aligning it with packet. > > We would like to change this to increase DPDK adoption for several new > DPDK-based applications for FSI segment. It also might be very > applicable for several RT media and debugging purposes of network > flows/streams in other segments like HPC. > > There are several thoughts how to improve there: > - 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 keep minimal performance impact for timestamps. > - PMD can fill the field in their callback completion routines > depending on enabling this feature in runtime. > > We evaluated other possible options but looks it will have even worse > performance impact. > > > Oleg Kuporosov (3): > mbuf: embedding timestamp into the packet > app/testpmd: enabled control for packet timestamps > net/mlx5: implementation of Rx packet timestamping support > > app/test-pmd/cmdline.c | 122 +++++++++++++++ > app/test-pmd/parameters.c | 4 + > app/test-pmd/testpmd.c | 5 + > app/test-pmd/testpmd.h | 1 + > doc/guides/testpmd_app_ug/run_app.rst | 4 + > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 7 + > drivers/net/mlx5/mlx5.c | 7 +- > drivers/net/mlx5/mlx5.h | 10 +- > drivers/net/mlx5/mlx5_defs.h | 4 + > drivers/net/mlx5/mlx5_ethdev.c | 222 +++++++++++++++++++++++++++- > drivers/net/mlx5/mlx5_rxq.c | 2 + > drivers/net/mlx5/mlx5_rxtx.c | 19 ++- > drivers/net/mlx5/mlx5_rxtx.h | 7 +- > drivers/net/mlx5/mlx5_time.h | 53 +++++++ > drivers/net/mlx5/mlx5_trigger.c | 1 + > lib/librte_eal/common/include/rte_time.h | 45 ++++++ > lib/librte_mbuf/rte_mbuf.h | 6 +- > 17 files changed, 507 insertions(+), 12 deletions(-) > create mode 100644 drivers/net/mlx5/mlx5_time.h > > Thanks, > Oleg. > -- > 1.8.3.1 Reviewed-by: Nelio Laranjeiro -- Nélio Laranjeiro 6WIND