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 66CB9A0527; Wed, 8 Jul 2020 18:05:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 59AF21E49D; Wed, 8 Jul 2020 18:05:56 +0200 (CEST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2045.outbound.protection.outlook.com [40.107.22.45]) by dpdk.org (Postfix) with ESMTP id 10E851E496 for ; Wed, 8 Jul 2020 18:05:55 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LZlqWAkxMJS2ZEYkhiT00m0/1MnSjf68T3CH88nOeBgD6znSNshty2z7saC/2KyZ0n8FXm/EpUQKYxhRS9rB0e6jCh8rPq95JRSSfLyg1xRBAvqPmKw33rDXegifDS9pq5dFGji9UGdyRjwfa5w1PGKgdHd2pJ+LU6+zPyMEFUz2THAKKyUL0mRxD3GQVzEu9xF0E8BS/j2r8gcVi8kKx0JrdebJ1yp30m6+40PsMGOBmKXQThXxZf48QYdjM1MaRuMWguR0JscbjarTTelL2XCROFkMq4rH4OU4dRw0mD4d9lzzCcb310stN+p6aDm7GLrfQBCbHXyRLKa5pxVrkA== 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=0spsSM+52/WtGZZW3M+oI4+ESjbuoKdzgYbWp4Qsk38=; b=ftK8Dfk2Cu0rnK43MfBm0VD/JDHOZQldoO7xWjNO/vnEYQ+j5x/sdvEBwxusYv8GzBSoeeTrqz7SRHEPAYTAMqc9PVdFlBM8vSkDU8LIfxqNrhqS6W5ni1xt7MaWpOVA39oG62JDpg0z8X6NxTgGmnC6TK17A/O6vkDEtca6LBatXrEFAttrwknIzNawlcngW2toUi6sJ+xY6KVwsV+LIN9WT1Sm5RimkorVVaAOhcHCTd7cK4sQdaL2nzx4XU9taxrwGK2ZnaFn5XAK5TSgiGwJ5PyyDfzEqLBURWzQUTVnA0eRGGTeHCrSpC18aKPnZdhx1Trc6c8YZHrmyopm9A== 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=0spsSM+52/WtGZZW3M+oI4+ESjbuoKdzgYbWp4Qsk38=; b=TKIKUsrMFoMf5OI4fr0xXLD7RJKxGpTp5YeNLRcqR3M6RLYfAazVmfhwGy1LjGIy/da6pa1nkSxsrQuDTOXlvDLa+yh57pgaNNZKrTp6aQpWTMr1+RuqgGLxOqD0Kyu/Q8NzrCNAuTwu8BpDh5q6i79cNCm2yvUEO3E04QkcQqg= Received: from AM4PR05MB3265.eurprd05.prod.outlook.com (2603:10a6:205:8::26) by AM4PR05MB3459.eurprd05.prod.outlook.com (2603:10a6:205:8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.29; Wed, 8 Jul 2020 16:05:53 +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; Wed, 8 Jul 2020 16:05:53 +0000 From: Slava Ovsiienko To: Slava Ovsiienko , "dev@dpdk.org" CC: Matan Azrad , Raslan Darawsheh , "olivier.matz@6wind.com" , "bernard.iremonger@intel.com" , "thomas@monjalon.com" , "mb@smartsharesystems.com" Thread-Topic: [dpdk-dev] [PATCH v5 1/2] mbuf: introduce accurate packet Tx scheduling Thread-Index: AQHWVT8dwFwzQaT460KpoxUNys741qj92Fbg Date: Wed, 8 Jul 2020 16:05:53 +0000 Message-ID: References: <1591771085-24959-1-git-send-email-viacheslavo@mellanox.com> <1594223249-24629-1-git-send-email-viacheslavo@mellanox.com> In-Reply-To: <1594223249-24629-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: 8d190d5f-d587-47be-dada-08d82358ca66 x-ms-traffictypediagnostic: AM4PR05MB3459: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtFwd x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04583CED1A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 96wQOYvohXToFZexr2EZ3tEseqyqtrk+i0BqxeQgKJQO1cVY+E1rILDNbnSiO2Li3djyoQ29pi7dsvdMrbVPqMBWN04a5MRPonB+GBtgcMf4yLQezdcqdcvVUakGaI3xR7EZ7mKJniHBygcfWTTTGW1Ged4UE0jIb9v5RozXXBwS0Qi13rsTlLUZiYL3DMonGInCucpSauBrFH1mARc0fD2jQsEiEYs9GvuNeMdHVTTwpTLRyMjQ9gVx8UjZpPot1unx3pMIT0xlFMsFqWUWElK1SUJ5HWFbHW7Q/IZ9+AZh6AzOB4WhJ6//Z4qMZUTxzFwkyQ2nAlJkSpE22UqKCQ== 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)(39860400002)(136003)(366004)(376002)(396003)(346002)(8936002)(83380400001)(110136005)(316002)(53546011)(6506007)(186003)(52536014)(4326008)(33656002)(5660300002)(26005)(2906002)(71200400001)(54906003)(66946007)(86362001)(478600001)(9686003)(64756008)(66476007)(66446008)(7696005)(55016002)(66556008)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: /oIbLqMyFVzQRWfcmYIkV2gvAgvz44TubQeahp4BwJ6Lg5EIHuCmo+0Im5aU5GYPvixejP97E5JphwhzrN25lrIR7nOBESkP9FgXiFPKwqPxmCys8aXip1Z0956WmrPFn8zs3QH7A29u+t5Emgr4/72mFz3pk3qILdJEMOUWgXuv47abX8UkDe//oHDm4SgZMypHvCXCFghndpytqK2q6adrsCrGnhnZdaq1m5yGTAVX60pkeN8j60bSzv6gCptoPid5kPNvV02utuNWWmXWsSFqiKqOlj1NQgcQgfMW8b+00M1zhTTGDvKToKam8dEl6yhykBVNdvOsexwC/a8FreO/aA9LJnD0uduWyEHhWWW6TdQJeCQ3ykUQ+NzM+scW2sgysKYdz8dE/jXcj0B/VTLh2hllM4VrMjlT8bbB3OprFsKT6tuORONeOFn17gRtD2BG6ld8kiJbUyOrgssI/L88kXg/olSt0yyIQ82cnjY= 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: 8d190d5f-d587-47be-dada-08d82358ca66 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2020 16:05:53.1238 (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: 2hXUTh1cx2aNsamTYKB/M2ccHmeZH67xKFhFvR00RHoZrL3Sxwq2xa65ACnQkWLQzUIdlrjgdg4LT7g2Ewe00v7Wh8eLg/FhxFpGxJ2eJ5A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR05MB3459 Subject: Re: [dpdk-dev] [PATCH v5 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" > promote Acked-bt from previous patch version to maintain patchwork status= accordingly Acked-by: Olivier Matz > -----Original Message----- > From: dev On Behalf Of Viacheslav Ovsiienko > Sent: Wednesday, July 8, 2020 18:47 > To: dev@dpdk.org > Cc: Matan Azrad ; Raslan Darawsheh > ; olivier.matz@6wind.com; > bernard.iremonger@intel.com; thomas@monjalon.com; > mb@smartsharesystems.com > Subject: [dpdk-dev] [PATCH v5 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 RFC is to specify the way how applications can > provide the moment of time at what the packet transmission must be starte= d > and to describe in preliminary the supporting this feature from > mlx5 PMD side. >=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 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. >=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 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. >=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_get_clock is supposed to be engaged to get the current device > clock value and provide the reference for the timestamps. >=20 > Signed-off-by: Viacheslav Ovsiienko >=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 >=20 > --- > lib/librte_ethdev/rte_ethdev.c | 1 + > lib/librte_ethdev/rte_ethdev.h | 4 ++++ lib/librte_mbuf/rte_mbuf_dyn.h= | > 31 +++++++++++++++++++++++++++++++ > 3 files changed, 36 insertions(+) >=20 > diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethde= v.c > index 8e10a6f..02157d5 100644 > --- a/lib/librte_ethdev/rte_ethdev.c > +++ b/lib/librte_ethdev/rte_ethdev.c > @@ -162,6 +162,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), > }; >=20 > #undef RTE_TX_OFFLOAD_BIT2STR > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethde= v.h > index a49242b..6f6454c 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 >=20 > +/** Device supports send on timestamp */ #define > +DEV_TX_OFFLOAD_SEND_ON_TIMESTAMP 0x00200000 > + > + > #define RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP 0x00000001 > /**< Device supports Rx queue setup after device started*/ #define > RTE_ETH_DEV_CAPA_RUNTIME_TX_QUEUE_SETUP 0x00000002 diff --git > a/lib/librte_mbuf/rte_mbuf_dyn.h b/lib/librte_mbuf/rte_mbuf_dyn.h index > 96c3631..8407230 100644 > --- a/lib/librte_mbuf/rte_mbuf_dyn.h > +++ b/lib/librte_mbuf/rte_mbuf_dyn.h > @@ -250,4 +250,35 @@ int rte_mbuf_dynflag_lookup(const char *name, > #define RTE_MBUF_DYNFIELD_METADATA_NAME > "rte_flow_dynfield_metadata" > #define RTE_MBUF_DYNFLAG_METADATA_NAME > "rte_flow_dynflag_metadata" >=20 > +/** > + * The timestamp dynamic field 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 Tx 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. > + * > + * After PKT_RX_TIMESTAMP flag and fixed timestamp field deprecation > + * and obsoleting, the dedicated Rx timestamp flag is supposed to be > + * introduced and the shared dynamic timestamp field will be used > + * to handle the timestamps on receiving datapath as well. > + */ > +#define RTE_MBUF_DYNFIELD_TIMESTAMP_NAME > "rte_dynfield_timestamp" > + > +/** > + * When PMD sees the RTE_MBUF_DYNFLAG_TX_TIMESTAMP_NAME flag > 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). > + * > + * There is no any packet reordering according to timestamps is > +supposed, > + * neither for packet within the burst, nor for the whole bursts, it is > + * an entirely application responsibility to generate packets and its > + * timestamps in desired order. The timestamps might be put only in > + * the first packet in the burst providing the entire burst scheduling. > + */ > +#define RTE_MBUF_DYNFLAG_TX_TIMESTAMP_NAME > "rte_dynflag_tx_timestamp" > + > #endif > -- > 1.8.3.1