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 69D94A052A; Sat, 11 Jul 2020 00:08:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 450981DBA9; Sat, 11 Jul 2020 00:08:02 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id DF8541D995 for ; Sat, 11 Jul 2020 00:07:59 +0200 (CEST) IronPort-SDR: SnNoZEFneu/vSaDrD2ii+pb9td45zZwUzER3D+InSeGc6S71DVGE5jdJRFPPC0lkkT81x0PK2L AXQWkJrS7QyA== X-IronPort-AV: E=McAfee;i="6000,8403,9678"; a="149781007" X-IronPort-AV: E=Sophos;i="5.75,336,1589266800"; d="scan'208";a="149781007" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2020 15:07:58 -0700 IronPort-SDR: u192UybVhUUui9Xs3FQvMPt0bwjiT4z2xwdNF58JGgiPMZX3Uidc3pbZYPKcjuaYy3h2ssjBjJ S8tooifIHRpg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,336,1589266800"; d="scan'208";a="280782329" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.213.217.176]) ([10.213.217.176]) by orsmga003.jf.intel.com with ESMTP; 10 Jul 2020 15:07:57 -0700 To: Slava Ovsiienko , "dev@dpdk.org" Cc: Matan Azrad , Raslan Darawsheh , "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , Thomas Monjalon References: <1591771085-24959-1-git-send-email-viacheslavo@mellanox.com> <1594384782-17799-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: <3cab6bb5-d5d4-11e3-a60d-7e843e4de4d5@intel.com> Date: Fri, 10 Jul 2020 23:07:56 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v7 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/10/2020 4:46 PM, Slava Ovsiienko wrote: > > >> -----Original Message----- >> From: dev On Behalf Of Viacheslav Ovsiienko >> Sent: Friday, July 10, 2020 15:40 >> To: dev@dpdk.org >> Cc: Matan Azrad ; Raslan Darawsheh >> ; olivier.matz@6wind.com; >> arybchenko@solarflare.com; Thomas Monjalon ; >> ferruh.yigit@intel.com >> Subject: [dpdk-dev] [PATCH v7 1/2] mbuf: introduce accurate packet Tx >> scheduling >> >> 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. >> >> The main objective of this patchset is to specify the way how applications >> 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 [1]. >> >> 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 supposed >> deprecation and obsoleting, these dynamic flag and field might 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 and this move should be discussed. >> >> 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 might 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. >> >> 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_read_clock is supposed to be engaged to get the current device >> clock value and provide the reference for the timestamps. >> >> [1] >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatche >> s.dpdk.org%2Fpatch%2F73714%2F&data=02%7C01%7Cviacheslavo%40 >> mellanox.com%7C810609c61c3b466e8f5a08d824ce57f8%7Ca652971c7d2e4 >> d9ba6a4d149256f461b%7C0%7C0%7C637299815958194092&sdata=H >> D7efBGOLuYxHd5KLJYJj7RSbiLRVBNm5jdq%2FJv%2FXfk%3D&reserved= >> 0 >> >> Signed-off-by: Viacheslav Ovsiienko > > promote Acked-bt from previous patch version to maintain patchwork > status accordingly > > Acked-by: Olivier Matz > For series, Reviewed-by: Ferruh Yigit Applied to dpdk-next-net/master, thanks.