From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 86FBCA052A; Fri, 10 Jul 2020 01:47:36 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A397E1DDCF; Fri, 10 Jul 2020 01:47:35 +0200 (CEST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 5DB8A1DD8D for ; Fri, 10 Jul 2020 01:47:33 +0200 (CEST) IronPort-SDR: rmdfQuHnC1Lmupv7UwYqNVSSDxvchsgwG358uW3ZOaXLTdgspGr1o6be+9Z6BP7zHGDDVUQhyE 9UIZ21y5pF6A== X-IronPort-AV: E=McAfee;i="6000,8403,9677"; a="135589520" X-IronPort-AV: E=Sophos;i="5.75,332,1589266800"; d="scan'208";a="135589520" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jul 2020 16:47:32 -0700 IronPort-SDR: ZWxEAffhjeSiwbn1x1nZaIP25KAbdlyJqEMlH7fThnhI+U0i007KfVkxlmNjDrz7demBNB7IDs mwXkF0z90/Bg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,332,1589266800"; d="scan'208";a="428390487" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.213.206.164]) ([10.213.206.164]) by orsmga004.jf.intel.com with ESMTP; 09 Jul 2020 16:47:30 -0700 To: Viacheslav Ovsiienko , dev@dpdk.org Cc: matan@mellanox.com, rasland@mellanox.com, olivier.matz@6wind.com, bernard.iremonger@intel.com, thomas@monjalon.com, Andrew Rybchenko References: <1591771085-24959-1-git-send-email-viacheslavo@mellanox.com> <1594298216-3746-1-git-send-email-viacheslavo@mellanox.com> From: Ferruh Yigit Autocrypt: addr=ferruh.yigit@intel.com; prefer-encrypt=mutual; keydata= mQINBFXZCFABEADCujshBOAaqPZpwShdkzkyGpJ15lmxiSr3jVMqOtQS/sB3FYLT0/d3+bvy qbL9YnlbPyRvZfnP3pXiKwkRoR1RJwEo2BOf6hxdzTmLRtGtwWzI9MwrUPj6n/ldiD58VAGQ +iR1I/z9UBUN/ZMksElA2D7Jgg7vZ78iKwNnd+vLBD6I61kVrZ45Vjo3r+pPOByUBXOUlxp9 GWEKKIrJ4eogqkVNSixN16VYK7xR+5OUkBYUO+sE6etSxCr7BahMPKxH+XPlZZjKrxciaWQb +dElz3Ab4Opl+ZT/bK2huX+W+NJBEBVzjTkhjSTjcyRdxvS1gwWRuXqAml/sh+KQjPV1PPHF YK5LcqLkle+OKTCa82OvUb7cr+ALxATIZXQkgmn+zFT8UzSS3aiBBohg3BtbTIWy51jNlYdy ezUZ4UxKSsFuUTPt+JjHQBvF7WKbmNGS3fCid5Iag4tWOfZoqiCNzxApkVugltxoc6rG2TyX CmI2rP0mQ0GOsGXA3+3c1MCdQFzdIn/5tLBZyKy4F54UFo35eOX8/g7OaE+xrgY/4bZjpxC1 1pd66AAtKb3aNXpHvIfkVV6NYloo52H+FUE5ZDPNCGD0/btFGPWmWRmkPybzColTy7fmPaGz cBcEEqHK4T0aY4UJmE7Ylvg255Kz7s6wGZe6IR3N0cKNv++O7QARAQABtCVGZXJydWggWWln aXQgPGZlcnJ1aC55aWdpdEBpbnRlbC5jb20+iQJsBBMBCgBWAhsDAh4BAheABQsJCAcDBRUK CQgLBRYCAwEABQkKqZZ8FiEE0jZTh0IuwoTjmYHH+TPrQ98TYR8FAl6ha3sXGHZrczovL2tl eXMub3BlbnBncC5vcmcACgkQ+TPrQ98TYR8uLA//QwltuFliUWe60xwmu9sY38c1DXvX67wk UryQ1WijVdIoj4H8cf/s2KtyIBjc89R254KMEfJDao/LrXqJ69KyGKXFhFPlF3VmFLsN4XiT PSfxkx8s6kHVaB3O183p4xAqnnl/ql8nJ5ph9HuwdL8CyO5/7dC/MjZ/mc4NGq5O9zk3YRGO lvdZAp5HW9VKW4iynvy7rl3tKyEqaAE62MbGyfJDH3C/nV/4+mPc8Av5rRH2hV+DBQourwuC ci6noiDP6GCNQqTh1FHYvXaN4GPMHD9DX6LtT8Fc5mL/V9i9kEVikPohlI0WJqhE+vQHFzR2 1q5nznE+pweYsBi3LXIMYpmha9oJh03dJOdKAEhkfBr6n8BWkWQMMiwfdzg20JX0o7a/iF8H 4dshBs+dXdIKzPfJhMjHxLDFNPNH8zRQkB02JceY9ESEah3wAbzTwz+e/9qQ5OyDTQjKkVOo cxC2U7CqeNt0JZi0tmuzIWrfxjAUulVhBmnceqyMOzGpSCQIkvalb6+eXsC9V1DZ4zsHZ2Mx Hi+7pCksdraXUhKdg5bOVCt8XFmx1MX4AoV3GWy6mZ4eMMvJN2hjXcrreQgG25BdCdcxKgqp e9cMbCtF+RZax8U6LkAWueJJ1QXrav1Jk5SnG8/5xANQoBQKGz+yFiWcgEs9Tpxth15o2v59 gXK5Ag0EV9ZMvgEQAKc0Db17xNqtSwEvmfp4tkddwW9XA0tWWKtY4KUdd/jijYqc3fDD54ES YpV8QWj0xK4YM0dLxnDU2IYxjEshSB1TqAatVWz9WtBYvzalsyTqMKP3w34FciuL7orXP4Ai bPtrHuIXWQOBECcVZTTOdZYGAzaYzxiAONzF9eTiwIqe9/oaOjTwTLnOarHt16QApTYQSnxD UQljeNvKYt1lZE/gAUUxNLWsYyTT+22/vU0GDUahsJxs1+f1yEr+OGrFiEAmqrzpF0lCS3f/ 3HVTU6rS9cK3glVUeaTF4+1SK5ZNO35piVQCwphmxa+dwTG/DvvHYCtgOZorTJ+OHfvCnSVj sM4kcXGjJPy3JZmUtyL9UxEbYlrffGPQI3gLXIGD5AN5XdAXFCjjaID/KR1c9RHd7Oaw0Pdc q9UtMLgM1vdX8RlDuMGPrj5sQrRVbgYHfVU/TQCk1C9KhzOwg4Ap2T3tE1umY/DqrXQgsgH7 1PXFucVjOyHMYXXugLT8YQ0gcBPHy9mZqw5mgOI5lCl6d4uCcUT0l/OEtPG/rA1lxz8ctdFB VOQOxCvwRG2QCgcJ/UTn5vlivul+cThi6ERPvjqjblLncQtRg8izj2qgmwQkvfj+h7Ex88bI 8iWtu5+I3K3LmNz/UxHBSWEmUnkg4fJlRr7oItHsZ0ia6wWQ8lQnABEBAAGJAjwEGAEKACYC GwwWIQTSNlOHQi7ChOOZgcf5M+tD3xNhHwUCXqFrngUJCKxSYAAKCRD5M+tD3xNhH3YWD/9b cUiWaHJasX+OpiuZ1Li5GG3m9aw4lR/k2lET0UPRer2Jy1JsL+uqzdkxGvPqzFTBXgx/6Byz EMa2mt6R9BCyR286s3lxVS5Bgr5JGB3EkpPcoJT3A7QOYMV95jBiiJTy78Qdzi5LrIu4tW6H o0MWUjpjdbR01cnj6EagKrDx9kAsqQTfvz4ff5JIFyKSKEHQMaz1YGHyCWhsTwqONhs0G7V2 0taQS1bGiaWND0dIBJ/u0pU998XZhmMzn765H+/MqXsyDXwoHv1rcaX/kcZIcN3sLUVcbdxA WHXOktGTQemQfEpCNuf2jeeJlp8sHmAQmV3dLS1R49h0q7hH4qOPEIvXjQebJGs5W7s2vxbA 5u5nLujmMkkfg1XHsds0u7Zdp2n200VC4GQf8vsUp6CSMgjedHeF9zKv1W4lYXpHp576ZV7T GgsEsvveAE1xvHnpV9d7ZehPuZfYlP4qgo2iutA1c0AXZLn5LPcDBgZ+KQZTzm05RU1gkx7n gL9CdTzVrYFy7Y5R+TrE9HFUnsaXaGsJwOB/emByGPQEKrupz8CZFi9pkqPuAPwjN6Wonokv ChAewHXPUadcJmCTj78Oeg9uXR6yjpxyFjx3vdijQIYgi5TEGpeTQBymLANOYxYWYOjXk+ae dYuOYKR9nbPv+2zK9pwwQ2NXbUBystaGyQ== Message-ID: Date: Fri, 10 Jul 2020 00:47:29 +0100 MIME-Version: 1.0 In-Reply-To: <1594298216-3746-1-git-send-email-viacheslavo@mellanox.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v6 1/2] mbuf: introduce accurate packet Tx scheduling 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 7/9/2020 1:36 PM, Viacheslav Ovsiienko wrote: > There is the requirement on some networks for precise traffic timing > management. The ability to send (and, generally speaking, receive) > the packets at the very precisely specified moment of time provides > the opportunity to support the connections with Time Division > Multiplexing using the contemporary general purpose NIC without involving > an auxiliary hardware. For example, the supporting of O-RAN Fronthaul > interface is one of the promising features for potentially usage of the > precise time management for the egress packets. Is this a HW support, or is the scheduling planned to be done in the driver? > > The main objective of this RFC is to specify the way how applications It is no more RFC. > can provide the moment of time at what the packet transmission must be > started and to describe in preliminary the supporting this feature from > mlx5 PMD side. I was about the ask this, will there be a PMD counterpart implementation of the feature? It would be better to have it as part of this set. What is the plan for the PMD implementation? > > The new dynamic timestamp field is proposed, it provides some timing > information, the units and time references (initial phase) are not > explicitly defined but are maintained always the same for a given port. > Some devices allow to query rte_eth_read_clock() that will return > the current device timestamp. The dynamic timestamp flag tells whether > the field contains actual timestamp value. For the packets being sent > this value can be used by PMD to schedule packet sending. > > The device clock is opaque entity, the units and frequency are > vendor specific and might depend on hardware capabilities and > configurations. If might (or not) be synchronized with real time > via PTP, might (or not) be synchronous with CPU clock (for example > if NIC and CPU share the same clock source there might be no > any drift between the NIC and CPU clocks), etc. > > After PKT_RX_TIMESTAMP flag and fixed timestamp field deprecation > and obsoleting, these dynamic flag and field will be used to manage > the timestamps on receiving datapath as well. Having the dedicated > flags for Rx/Tx timestamps allows applications not to perform explicit > flags reset on forwarding and not to promote received timestamps > to the transmitting datapath by default. The static PKT_RX_TIMESTAMP > is considered as candidate to become the dynamic flag. Is there a deprecation notice for 'PKT_RX_TIMESTAMP'? Is this decided? > > When PMD sees the "rte_dynfield_timestamp" set on the packet being sent > it tries to synchronize the time of packet appearing on the wire with > the specified packet timestamp. If the specified one is in the past it > should be ignored, if one is in the distant future it should be capped > with some reasonable value (in range of seconds). These specific cases > ("too late" and "distant future") can be optionally reported via > device xstats to assist applications to detect the time-related > problems. > > There is no any packet reordering according timestamps is supposed, > neither within packet burst, nor between packets, it is an entirely > application responsibility to generate packets and its timestamps > in desired order. The timestamps can be put only in the first packet > in the burst providing the entire burst scheduling. > > PMD reports the ability to synchronize packet sending on timestamp > with new offload flag: > > This is palliative and is going to be replaced with new eth_dev API > about reporting/managing the supported dynamic flags and its related > features. This API would break ABI compatibility and can't be introduced > at the moment, so is postponed to 20.11. Good to hear that there will be a generic API to get supported dynamic flags. I was concerned about adding 'DEV_TX_OFFLOAD_SEND_ON_TIMESTAMP' flag, since not sure if there will be any other PMD that will want to use it. The trouble is it is hard to remove a public macro after it is introduced, in this release I think only single PMD (mlx) will support this feature, and in next release the plan is to remove the macro. In this case what do you think to not introduce the flag at all? > > For testing purposes it is proposed to update testpmd "txonly" > forwarding mode routine. With this update testpmd application generates > the packets and sets the dynamic timestamps according to specified time > pattern if it sees the "rte_dynfield_timestamp" is registered. > > The new testpmd command is proposed to configure sending pattern: > > set tx_times , > > - the delay between the packets within the burst > specified in the device clock units. The number > of packets in the burst is defined by txburst parameter > > - the delay between the bursts in the device clock units > > As the result the bursts of packet will be transmitted with specific > delays between the packets within the burst and specific delay between > the bursts. The rte_eth_get_clock is supposed to be engaged to get the 'rte_eth_read_clock()'? > current device clock value and provide the reference for the timestamps. > > Signed-off-by: Viacheslav Ovsiienko > Acked-by: Olivier Matz > > --- > v1->v4: > - dedicated dynamic Tx timestamp flag instead of shared with Rx > v4->v5: > - elaborated commit message > - more words about device clocks added, > - note about dedicated Rx/Tx timestamp flags added > v5->v6: > - release notes are updated > --- > doc/guides/rel_notes/release_20_08.rst | 6 ++++++ > lib/librte_ethdev/rte_ethdev.c | 1 + > lib/librte_ethdev/rte_ethdev.h | 4 ++++ > lib/librte_mbuf/rte_mbuf_dyn.h | 31 +++++++++++++++++++++++++++++++ > 4 files changed, 42 insertions(+) > > diff --git a/doc/guides/rel_notes/release_20_08.rst b/doc/guides/rel_notes/release_20_08.rst > index 988474c..5527bab 100644 > --- a/doc/guides/rel_notes/release_20_08.rst > +++ b/doc/guides/rel_notes/release_20_08.rst > @@ -200,6 +200,12 @@ New Features > See the :doc:`../sample_app_ug/l2_forward_real_virtual` for more > details of this parameter usage. > > +* **Introduced send packet scheduling on the timestamps.** > + > + Added the new mbuf dynamic field and flag to provide timestamp on what packet > + transmitting can be synchronized. The device Tx offload flag is added to > + indicate the PMD supports send scheduling. > + This is a core library change, can go up in the section, please check the section comment for the ordering details. > > Removed Items > ------------- > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c > index 7022bd7..c48ca2a 100644 > --- a/lib/librte_ethdev/rte_ethdev.c > +++ b/lib/librte_ethdev/rte_ethdev.c > @@ -160,6 +160,7 @@ struct rte_eth_xstats_name_off { > RTE_TX_OFFLOAD_BIT2STR(UDP_TNL_TSO), > RTE_TX_OFFLOAD_BIT2STR(IP_TNL_TSO), > RTE_TX_OFFLOAD_BIT2STR(OUTER_UDP_CKSUM), > + RTE_TX_OFFLOAD_BIT2STR(SEND_ON_TIMESTAMP), > }; > > #undef RTE_TX_OFFLOAD_BIT2STR > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h > index 631b146..97313a0 100644 > --- a/lib/librte_ethdev/rte_ethdev.h > +++ b/lib/librte_ethdev/rte_ethdev.h > @@ -1178,6 +1178,10 @@ struct rte_eth_conf { > /** Device supports outer UDP checksum */ > #define DEV_TX_OFFLOAD_OUTER_UDP_CKSUM 0x00100000 > > +/** Device supports send on timestamp */ > +#define DEV_TX_OFFLOAD_SEND_ON_TIMESTAMP 0x00200000 Please cc the ethdev maintainers. As mentioned above my concern is if this is generic enough or are we adding a flag to a specific PMD? And since commit log says this is temporary solution for just this release, I repeat my question if we can remove the flag completely?