On 7/10/2020 4:46 PM, Slava Ovsiienko wrote: > > >> -----Original Message----- >> From: dev <[email protected]> On Behalf Of Viacheslav Ovsiienko >> Sent: Friday, July 10, 2020 15:40 >> To: [email protected] >> Cc: Matan Azrad <[email protected]>; Raslan Darawsheh >> <[email protected]>; [email protected]; >> [email protected]; Thomas Monjalon <[email protected]>; >> [email protected] >> 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 <burst_gap>,<intra_gap> >> >> <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 >> >> <burst_gap> - 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 <[email protected]> > > promote Acked-bt from previous patch version to maintain patchwork > status accordingly > > Acked-by: Olivier Matz <[email protected]> >
For series, Reviewed-by: Ferruh Yigit <[email protected]> Applied to dpdk-next-net/master, thanks.
