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 65395A052A; Fri, 10 Jul 2020 17:46:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B74C71DABC; Fri, 10 Jul 2020 17:46:20 +0200 (CEST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50056.outbound.protection.outlook.com [40.107.5.56]) by dpdk.org (Postfix) with ESMTP id 125EF1DAAE for ; Fri, 10 Jul 2020 17:46:19 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZLgIEUEReBKxlu/oXd+eaUxkAnuFsRaVg5CKnqwYbJ4EOJSA8kPwJpsfhoQmwzKfbtqp4xdbs8iNnY+gVvth5/sh7jwDzSeW4lLBP2q6bvkUs/rsdxkQJVbd6ufr3LOBcmJJguiY271nBlJDVoNhCO3ndnz/haqwAK/Pb2UVS22onLxPJFrz2IjSp2fLjF1tbTEeoZ4cMSrggVSA+zoP6dr3NMW8kB3tZxl6sN27kvh1Uq0B+3oLK0ArQyb+3XA/P6eksDyVvOnxY61JslAnVeGS7PO0+FEpabY44W3CGuQczMIBLCYP7bn4LwJx5vW+k+G88zHuQcjJO2G2BrkF2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mYoxDO6GrbEYEdshKRvA7nRHfd2dN7YS6mmHjpKY2lQ=; b=U9iAK2gBvOdKYiSl+q9H/Xk9EKdVqnGERt4C9/DRTaldAD27mPtTcDx4rZ6r/g06xjL/LfISlsHLfk+oHCK9SjCvocVwKL53HZSOhsNXGi35dvLzMr+WNUTQJ4guOJ93v0u9l4J5WKh6SY3+Q4Ayy5GmF5cmFOFNpOzgyygln1vJhWkPC5ITE71A2XmERXurQRK3Pj0j1hojWRgLmZE4pQHbrfekuxvod5SbJHVCuf+tQjIQ0i1Hxm4r6GlHAyvtF9p8RxqRECbQwFXX/3KZDk6UEq/87CObffM6f3dcRQh6mpBm7pE5wLau7N44ZMsgGcFsevYksIgijCf3TEpfzA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mellanox.com; dmarc=pass action=none header.from=mellanox.com; dkim=pass header.d=mellanox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mYoxDO6GrbEYEdshKRvA7nRHfd2dN7YS6mmHjpKY2lQ=; b=PfaBhkABWPx49VR622Mvaog0OUWoycHMyKCMyTwrF+Ejz+MrvbwBA1cY+nMR+duLA0govcbPqQYlVelk+oX8P0diPGHrffIwKB1aOn/SiH26/XeUUFeF1cOjuvBtWfGXomJjT4xLiTCwHSg0eS9msdPQe+UWGsUz9AO0JaLF+ak= Received: from AM4PR05MB3265.eurprd05.prod.outlook.com (2603:10a6:205:8::26) by AM0PR05MB4595.eurprd05.prod.outlook.com (2603:10a6:208:ae::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Fri, 10 Jul 2020 15:46:17 +0000 Received: from AM4PR05MB3265.eurprd05.prod.outlook.com ([fe80::194e:dc46:7543:50ed]) by AM4PR05MB3265.eurprd05.prod.outlook.com ([fe80::194e:dc46:7543:50ed%2]) with mapi id 15.20.3174.022; Fri, 10 Jul 2020 15:46:17 +0000 From: Slava Ovsiienko To: Slava Ovsiienko , "dev@dpdk.org" CC: Matan Azrad , Raslan Darawsheh , "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , Thomas Monjalon , "ferruh.yigit@intel.com" Thread-Topic: [dpdk-dev] [PATCH v7 1/2] mbuf: introduce accurate packet Tx scheduling Thread-Index: AQHWVrc3pzV3ZS8l7ESo1GeDiSeItakA9PuQ Date: Fri, 10 Jul 2020 15:46:17 +0000 Message-ID: References: <1591771085-24959-1-git-send-email-viacheslavo@mellanox.com> <1594384782-17799-1-git-send-email-viacheslavo@mellanox.com> In-Reply-To: <1594384782-17799-1-git-send-email-viacheslavo@mellanox.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mellanox.com; dkim=none (message not signed) header.d=none;mellanox.com; dmarc=none action=none header.from=mellanox.com; x-originating-ip: [95.164.10.10] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 37edc213-aa9f-4ca4-27a6-08d824e86281 x-ms-traffictypediagnostic: AM0PR05MB4595: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr,ExtFwd x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aarbAnJIWnhzxd+2K6bKZrGrAWCn9jhfXmvK8oeU+i/wV6glUldBtXfuorlyDwPAYU3XqzMfjw5fB5rZ4GsK2R9epD9pG9VbmHXJPEPJR+Yt1hhn4YxMeP5HC2JMqNExeGNifGokQNCAD/6VKDM2utrEBG5tIzsjvIrR7uCBfaJpVuii4eTtji9fygMyA4teT3QwFTcXzPJpmPVcaIevOtq1SKjjlasejJQvHIScTruIM00zNrDvOLoOUk/29wmQPYm5KRtsu0DR67xdPYZm4j9fj7+lOK7x3W0yKmJSSPFdR81ZBApkcfxu0N8Qgt50uaqvClQESa/X5A/Rwc9zkiC3ynb+fYTWe7yiwXYGE3KGgSSnujsKJQs3S8zEHhd5X1uPYkRi2Uef4QY+kEyCMg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM4PR05MB3265.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(346002)(376002)(136003)(396003)(6506007)(53546011)(33656002)(7696005)(66476007)(71200400001)(5660300002)(45080400002)(52536014)(966005)(4326008)(478600001)(2906002)(26005)(9686003)(8936002)(83380400001)(86362001)(186003)(316002)(76116006)(110136005)(55016002)(66946007)(66446008)(54906003)(64756008)(66556008)(83080400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: hXQ0nuk1TNNSpCaEION7AF+Ndq8whPGO0I8Gl/3MFLbUcLqvD9rIhhFlAvpqbtrhVJe9lA4saGvWYVs8He2FuCMQgAYu6SlMTr1touLqu0LI9n9nWE5EzrFRFLDj+H8EeiMbTSQO5GU486cSJlPyAe2XPGC30dKdZgxr4MDoGGwCozM1nN4MT1pdxt2UkBdG6VFl3r0P+Z8dnWVzB1b2FiSdHIU50clGTYMyyN0dVvQczk8cKkiFpKNhg2OMGFb/NoyHiyQ1ijL/uIHim/UdoeWDCI4a1gmBaNfCRR6cWfGO83nLCxCHGnyxs3jiEgL7AifqWjAjIZlDdXoNSkaEdJWKvoh8saguslaAjWt1VjeChPCBbePQZyhXO4DEkSwl2uTBD+opi7BsBNwtkuDZTY+0UUG0MbWXvGYWmuDfVODxtMdDeE9FnmaaM67pelH4BvIqg+ei+2wvSOC5HY7yLcww3JyO1kBqFMdncxvv+X8= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM4PR05MB3265.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 37edc213-aa9f-4ca4-27a6-08d824e86281 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2020 15:46:17.5429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RrH9kFch+lzMNaci4EeiALan9UPD7Ct5Cw2PV/Sufk+Uj0f2IGfUNNTCkzqocBKIUl3fAZJ92RYjBqCHPBPCoeURxFqcmhObJ2dscn4Lkm8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR05MB4595 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" > -----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 >=20 > 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 us= ing > 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. >=20 > The main objective of this patchset is to specify the way how application= s > can provide the moment of time at what the packet transmission must be > started and to describe in preliminary the supporting this feature from m= lx5 > PMD side [1]. >=20 > The new dynamic timestamp field is proposed, it provides some timing > information, the units and time references (initial phase) are not explic= itly > defined but are maintained always the same for a given port. > Some devices allow to query rte_eth_read_clock() that will return the cur= rent > device timestamp. The dynamic timestamp flag tells whether the field > contains actual timestamp value. For the packets being sent this value ca= n be > used by PMD to schedule packet sending. >=20 > The device clock is opaque entity, the units and frequency are vendor spe= cific > and might depend on hardware capabilities and configurations. If might (o= r > not) be synchronized with real time via PTP, might (or not) be synchronou= s > 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. >=20 > 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 fl= ags > 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. >=20 > When PMD sees the "rte_dynfield_timestamp" set on the packet being sent i= t > 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. >=20 > There is no any packet reordering according timestamps is supposed, neith= er > within packet burst, nor between packets, it is an entirely application > responsibility to generate packets and its timestamps in desired order. T= he > timestamps can be put only in the first packet in the burst providing the > entire burst scheduling. >=20 > PMD reports the ability to synchronize packet sending on timestamp with > new offload flag: >=20 > 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. >=20 > 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. >=20 > The new testpmd command is proposed to configure sending pattern: >=20 > set tx_times , >=20 > - 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 >=20 > - the delay between the bursts in the device clock units >=20 > As the result the bursts of packet will be transmitted with specific dela= ys > between the packets within the burst and specific delay between the burst= s. > The rte_eth_read_clock is supposed to be engaged to get the current devic= e > clock value and provide the reference for the timestamps. >=20 > [1] > https://eur03.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fpatche > s.dpdk.org%2Fpatch%2F73714%2F&data=3D02%7C01%7Cviacheslavo%40 > mellanox.com%7C810609c61c3b466e8f5a08d824ce57f8%7Ca652971c7d2e4 > d9ba6a4d149256f461b%7C0%7C0%7C637299815958194092&sdata=3DH > D7efBGOLuYxHd5KLJYJj7RSbiLRVBNm5jdq%2FJv%2FXfk%3D&reserved=3D > 0 >=20 > Signed-off-by: Viacheslav Ovsiienko promote Acked-bt from previous patch version to maintain patchwork=20 status accordingly Acked-by: Olivier Matz >=20 > --- > 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 > v6->v7: > - commit message is updated > - testpmd checks the supported offloads before registering > dynamic timestamp flag/field > --- > doc/guides/rel_notes/release_20_08.rst | 7 +++++++ > 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, 43 insertions(+) >=20