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 3B5F3A051F; Wed, 10 Jun 2020 15:33:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 90D2A31FC; Wed, 10 Jun 2020 15:33:55 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by dpdk.org (Postfix) with ESMTP id 69E102BE9 for ; Wed, 10 Jun 2020 15:33:54 +0200 (CEST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 05ADQOZg010179; Wed, 10 Jun 2020 06:33:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : mime-version; s=pfpt0818; bh=LIvG/UHmMMmcQAHhED35436afEwUvLuN3NrNOCAjsrU=; b=hiRRaWAaRhAEXerXYS9kaQ5kiw/s/fnBWUXMsXS2cSOvpP2NBPiMlQxb+2FGaeatWQ9I 5QlSmBwLlLhdwKQM1hoguN579cYRDZfFOkGJEerEVJSfw6ucDsAsvHlQpSDVfPLTgAPc xJxQFZQjYonsuMfGFRPSMb41fqSTyQbZN3Cj96gzOL3HxY4li6/Bi3yJ5ZfCO0kSHHoK YxTVhdFM+TTpIrHUIdoHly1WP248b7IWYUchgabvh77cdIiqomv2mkBs0I4VhKT7UQva u9FJXnN3Vu8lVzMD6qoe4Nmar6jtsp25Wjb5EkFDFwMblDS7PITuUYwf4wORdxyttTg/ Bw== Received: from sc-exch04.marvell.com ([199.233.58.184]) by mx0b-0016f401.pphosted.com with ESMTP id 31ganndu6v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 10 Jun 2020 06:33:53 -0700 Received: from DC5-EXCH02.marvell.com (10.69.176.39) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 10 Jun 2020 06:33:51 -0700 Received: from SC-EXCH02.marvell.com (10.93.176.82) by DC5-EXCH02.marvell.com (10.69.176.39) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 10 Jun 2020 06:33:51 -0700 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.54) by SC-EXCH02.marvell.com (10.93.176.82) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 10 Jun 2020 06:33:51 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NpXFo2Gz63Oe92JE9ZpOY08ofUDYX4xl9ObehGnWUx8A012p6jSzbIk2bL7qXc/xLREVSY+2qCfi0IcfvN9lsQoMRoRR6f3LE4mDu53liBEa5c8XkHHLWKYjubxD5itZ91g8gK9aUJg9AIFvSIoySDS9DrlRo3Dvmhi/A+hAXvnWl6AAHFTwZEg7HF7mCQMbdPHi2OI13HAkHoXCikIqoJZhn6Tq6VI74iSNm14cBunjJWzqfO5n+iFP4Jtobx137jNX6QzMhY8m0Rlhq6Zf8slqZGBx4Oa6yr+iwHE7EeRdkDnGbFrJVPG2Yy46vXDOutKYgoGusFQZRHlGQ+K65Q== 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=LIvG/UHmMMmcQAHhED35436afEwUvLuN3NrNOCAjsrU=; b=Ypxy+2EVi67etwuN4/nMae7VWoJ3fORDLCtATQNe7Q/m9QpWraJhC7MVfO2p+Jts/ReqLhK3gIdm1jIiGIZMB8VbbGD38QI93SV6UDNLAjJW4jwe4X6lrq3WptcpyADvJmGhVNJmqhbprmWrrerPPJ9ufaARbWqMs60fRzLsmnbOZHFugWGXopf/lyvajZIvo+N3WgZZ7DiMM+9HzYlu3ZnQPfNy6EIiozztwUrJhyed02DV4ZGml40oOlTM2MvCOe9CVCvxYfQwvCjOUw4ILmFcOVf7Ks9gbMKY3pk/VW3Hid2JIa7d8oUcPQRawg3MnLnmErFiKHPzA2Dqmuv2Iw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LIvG/UHmMMmcQAHhED35436afEwUvLuN3NrNOCAjsrU=; b=c5VUtWqAsmkaaxZaaH64Ujg7FyUHu33jkEH7tv3T4O845C9ZfJg0cks5sruZzuQpRGp6QDmn6iRlSeN28L0xFA3RPo4GP/WHF6DN1j//jiBKVQVJQS3nZAjg4sYA7kVn4b1XarRZjOjSNQpSTUdoFrjT84x5ZQbF/bxMPirK/No= Authentication-Results: mellanox.com; dkim=none (message not signed) header.d=none;mellanox.com; dmarc=none action=none header.from=marvell.com; Received: from MN2PR18MB2848.namprd18.prod.outlook.com (2603:10b6:208:38::19) by MN2PR18MB2413.namprd18.prod.outlook.com (2603:10b6:208:105::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Wed, 10 Jun 2020 13:33:49 +0000 Received: from MN2PR18MB2848.namprd18.prod.outlook.com ([fe80::f4fb:5e32:18dc:fb93]) by MN2PR18MB2848.namprd18.prod.outlook.com ([fe80::f4fb:5e32:18dc:fb93%7]) with mapi id 15.20.3066.023; Wed, 10 Jun 2020 13:33:49 +0000 Date: Wed, 10 Jun 2020 19:03:34 +0530 From: Harman Kalra To: Viacheslav Ovsiienko CC: , , , , , , Message-ID: <20200610133332.GA54613@outlook.office365.com> References: <1591771085-24959-1-git-send-email-viacheslavo@mellanox.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1591771085-24959-1-git-send-email-viacheslavo@mellanox.com> User-Agent: Mutt/1.10.0 (2018-05-17) X-ClientProxiedBy: PN1PR01CA0098.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c00::14) To MN2PR18MB2848.namprd18.prod.outlook.com (2603:10b6:208:38::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from outlook.office365.com (115.113.156.2) by PN1PR01CA0098.INDPRD01.PROD.OUTLOOK.COM (2603:1096:c00::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19 via Frontend Transport; Wed, 10 Jun 2020 13:33:46 +0000 X-Originating-IP: [115.113.156.2] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b5199b3d-2899-497e-c5e1-08d80d42e832 X-MS-TrafficTypeDiagnostic: MN2PR18MB2413: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0430FA5CB7 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: de2FFP1jVRftltVyigyLtp+01T9Zmv87Loi8DgY55hzkutLxTJFKqPpTu/0whznJAABw4+obqENxLZ2rSQc/lVFFdPBjwc3iWHo0U0pzc3SpskVERgQ+nJcXHCAUkOhjkLolG8XQk0vBiOpi7Fgig7aXQVEHf5qQtQiGeRx9vC9P/X0iU4OpuEhr89W3MrhxDcpiGAtwuOXkXBiswEAzqXmZxu56vtoALUZDF3icIBdEm7Y2trJF2utH85a4KBrsAEQmnwJOp3HfRDkoHuuBCclK5T4dVfBLqi5KlTSxfVeZ8/viqfmhBwreswAEV/4r0SChIGcohAHihI3wAT7X0w== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR18MB2848.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(376002)(136003)(346002)(39860400002)(8936002)(33656002)(66476007)(6916009)(956004)(66946007)(66556008)(9686003)(6666004)(7696005)(55016002)(52116002)(316002)(1076003)(55236004)(5660300002)(26005)(16526019)(6506007)(83380400001)(86362001)(8676002)(186003)(4326008)(478600001)(2906002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: mefv3H8rIi5sWI2hzh47NdgIXwSATpH4fCuuU31wP10IIErl8tdRfDdtRMgAOKfbNFhQbtL102fQq+1LiiNy2BKoCr8D2ATBNEjjNL7mpL47IOLKjWf2M+IMq+RBx5iE+jVBUNMn+2fbXZ6BlJNfn6xK7zUxkHPcXRzc9UItMs3x2bJbiLgqTDyc1o5QCNHuKkGarNWrPquy30ptcwjXyQoJz7Nz7/A9iInrNCyuLlyVON4BkMi4RXwyblHQ+NTfte7HNrfr5q9lUqkOGVc+IDv0X+egIXRopzqhx3HXyYZN+66MfHBTQtuhqxH7pbcv2ZrTaeyNJe+sH5F4ENy64ZkxpuiRVx35WikeuOnQ2T9BAwvmhdiNEMRw7Zl8zFQlazjaa8FSCSi4v1riT1dZByly+fegyE8Vss/LHjs4ya6Z+A8oU35cAXU0kkKH7hahr4mt5s3G440Tr8Ta6ZW+naiiFlu0VXLYlc4vIwYS2rc= X-MS-Exchange-CrossTenant-Network-Message-Id: b5199b3d-2899-497e-c5e1-08d80d42e832 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2020 13:33:49.1557 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9cwiloF8vrApu/qGC2g09FF7GjOifS4TgEV2XDG3SvqMWM3y5E0uH/zOYQE8rsXWxiHbjR25Npm/x17ZBP5pKQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR18MB2413 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-10_08:2020-06-10, 2020-06-10 signatures=0 Subject: Re: [dpdk-dev] [RFC] mbuf: 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 Wed, Jun 10, 2020 at 06:38:05AM +0000, Viacheslav Ovsiienko wrote: Hi Viacheslav, I have some queries below: > 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 RFC 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. > > 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. > > 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. > > 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. It 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. Since its applicaiton responsibility to care of packet reordering and many other parameters, so why cant application itself take the responsibility of packet scheduling, i.e. applicaton can hold for the required time before calling tx-burst? Why are we even offloading this job to PMD? > > 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. > > 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. So what I am understanding here is "rte_dynfield_timestamp" will provide information about three parameters: - timestamp at which TX should start - intra packet gap - intra burst gap. If its about "intra packet gap" then PMD can take care, but if it is about intra burst gap, application can take care of it. > > 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 I think here you mean "rte_eth_read_clock". Thanks Harman > current device clock value and provide the reference for the timestamps. > > Signed-off-by: Viacheslav Ovsiienko > --- > lib/librte_ethdev/rte_ethdev.h | 4 ++++ > lib/librte_mbuf/rte_mbuf_dyn.h | 16 ++++++++++++++++ > 2 files changed, 20 insertions(+) > > diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.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 > > +/** 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..fb5477c 100644 > --- a/lib/librte_mbuf/rte_mbuf_dyn.h > +++ b/lib/librte_mbuf/rte_mbuf_dyn.h > @@ -250,4 +250,20 @@ 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" > > +/* > + * 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 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, these dynamic flag and field will be used to manage > + * the timestamps on receiving datapath as well. > + */ > +#define RTE_MBUF_DYNFIELD_TIMESTAMP_NAME "rte_dynfield_timestamp" > +#define RTE_MBUF_DYNFLAG_TIMESTAMP_NAME "rte_dynflag_timestamp" > + > #endif > -- > 1.8.3.1 >