From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <viacheslavo@mellanox.com>
To: Slava Ovsiienko <viacheslavo@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>
CC: Matan Azrad <matan@mellanox.com>, Raslan Darawsheh <rasland@mellanox.com>,
"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"bernard.iremonger@intel.com" <bernard.iremonger@intel.com>,
"thomas@monjalon.com" <thomas@monjalon.com>, "mb@smartsharesystems.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: <AM4PR05MB3265B90AE9045358E1009C6FD2670@AM4PR05MB3265.eurprd05.prod.outlook.com>
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: <AM4PR05MB345905E110FA440076B092D3D2670@AM4PR05MB3459.eurprd05.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
> promote Acked-bt from previous patch version to maintain patchwork status=
accordingly
Acked-by: Olivier Matz <olivier.matz@6wind.com>
> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Viacheslav Ovsiienko
> Sent: Wednesday, July 8, 2020 18:47
> To: dev@dpdk.org
> Cc: Matan Azrad <matan@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>; 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 <burst_gap>,<intra_gap>
>=20
> <intra_gap> - 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
> <burst_gap> - 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 <viacheslavo@mellanox.com>
>=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