[RFC] mbuf: accurate packet Tx scheduling
Checks
Commit Message
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.
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.
The new testpmd command is proposed to configure sending pattern:
set tx_times <intra_gap>,<burst_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_get_clock is supposed to be engaged to get the
current device clock value and provide the reference for the timestamps.
Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
---
lib/librte_ethdev/rte_ethdev.h | 4 ++++
lib/librte_mbuf/rte_mbuf_dyn.h | 16 ++++++++++++++++
2 files changed, 20 insertions(+)
Comments
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 <intra_gap>,<burst_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_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 <viacheslavo@mellanox.com>
> ---
> 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
>
Hi, Harman
> -----Original Message-----
> From: Harman Kalra <hkalra@marvell.com>
> Sent: Wednesday, June 10, 2020 16:34
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>; Matan
> Azrad <matan@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>; Ori Kam <orika@mellanox.com>;
> olivier.matz@6wind.com; Shahaf Shuler <shahafs@mellanox.com>
> Subject: Re: [dpdk-dev] [RFC] mbuf: accurate packet Tx scheduling
>
> 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?
>
- The scheduling is required to be very precise. Within handred(s) of nanoseconds.
- It saves CPU cycles. Application just should prepare the packets, put the desired timestamps
and call tx_burst(). "Shut-n-forget" approach.
SW approach is potentially possible, application can hold the time and schedule packets itself.
But... Can we guarantee the stable delay between tx_burst call and data on the wire?
Should we waste CPU cycles to wait the desired moment of time? Can we guarantee
stable interrupt latency if we choose to schedule on interrupts approach?
This RFC splits the responsibility - application should prepare the data and specify
when it desires to send, the rest is on 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.
Not sure - the intra-burst gap might be pretty small.
It is supposed to handle intra-burst in the same way - by specifying
the timestamps. Waiting is supposed to be implemented on tx_burst() retry.
Prepare the packets with timestamps, tx_burst - if not all packets are sent -
it means queue is waiting for the schedult, retry with the remaining packets.
As option - we can implement intra-burst wait basing rte_eth_read_clock().
> > The new testpmd command is proposed to configure sending pattern:
> >
> > set tx_times <intra_gap>,<burst_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_get_clock is supposed to be engaged to get the
>
> I think here you mean "rte_eth_read_clock".
Yes, exactly. Thank you for the correction.
With best regards, Slava
>
>
> Thanks
> Harman
>
> > current device clock value and provide the reference for the timestamps.
> >
> > Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> > ---
> > 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
> >
On Wed, Jun 10, 2020 at 03:16:12PM +0000, Slava Ovsiienko wrote:
> External Email
>
> ----------------------------------------------------------------------
> Hi, Harman
>
> > -----Original Message-----
> > From: Harman Kalra <hkalra@marvell.com>
> > Sent: Wednesday, June 10, 2020 16:34
> > To: Slava Ovsiienko <viacheslavo@mellanox.com>
> > Cc: dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>; Matan
> > Azrad <matan@mellanox.com>; Raslan Darawsheh
> > <rasland@mellanox.com>; Ori Kam <orika@mellanox.com>;
> > olivier.matz@6wind.com; Shahaf Shuler <shahafs@mellanox.com>
> > Subject: Re: [dpdk-dev] [RFC] mbuf: accurate packet Tx scheduling
> >
> > 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?
> >
> - The scheduling is required to be very precise. Within handred(s) of nanoseconds.
> - It saves CPU cycles. Application just should prepare the packets, put the desired timestamps
> and call tx_burst(). "Shut-n-forget" approach.
>
> SW approach is potentially possible, application can hold the time and schedule packets itself.
> But... Can we guarantee the stable delay between tx_burst call and data on the wire?
> Should we waste CPU cycles to wait the desired moment of time? Can we guarantee
> stable interrupt latency if we choose to schedule on interrupts approach?
>
> This RFC splits the responsibility - application should prepare the data and specify
> when it desires to send, the rest is on PMD.
I agree with the fact that we cannot guarantee the delay between tx
burst call and data on wire, hence PMD should take care of it.
Even if PMD is holding, it is wastage of CPU cycles or if we setup
an alarm then also interrupt latency might be a concern to achieve
precise timming. So how are you planning to address both of above
issue in 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.
>
> Not sure - the intra-burst gap might be pretty small.
> It is supposed to handle intra-burst in the same way - by specifying
> the timestamps. Waiting is supposed to be implemented on tx_burst() retry.
> Prepare the packets with timestamps, tx_burst - if not all packets are sent -
> it means queue is waiting for the schedult, retry with the remaining packets.
> As option - we can implement intra-burst wait basing rte_eth_read_clock().
Yeah, I think app can make use of rte_eth_read_clock() to implement
intra-burst gap.
But my actual doubt was, what all information will app provide as
part of "rte_dynfield_timestamp" - one I understand will be timestamp
at which packets should be sent out. What else? intra-packet gap ?
Thanks
Harman
>
> > > The new testpmd command is proposed to configure sending pattern:
> > >
> > > set tx_times <intra_gap>,<burst_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_get_clock is supposed to be engaged to get the
> >
> > I think here you mean "rte_eth_read_clock".
> Yes, exactly. Thank you for the correction.
>
> With best regards, Slava
>
> >
> >
> > Thanks
> > Harman
> >
> > > current device clock value and provide the reference for the timestamps.
> > >
> > > Signed-off-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
> > > ---
> > > 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
> > >
> -----Original Message-----
> From: Harman Kalra <hkalra@marvell.com>
> Sent: Wednesday, June 17, 2020 18:58
> To: Slava Ovsiienko <viacheslavo@mellanox.com>
> Cc: dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>; Matan
> Azrad <matan@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>; Ori Kam <orika@mellanox.com>;
> olivier.matz@6wind.com; Shahaf Shuler <shahafs@mellanox.com>
> Subject: Re: [EXT] RE: [dpdk-dev] [RFC] mbuf: accurate packet Tx scheduling
>
> On Wed, Jun 10, 2020 at 03:16:12PM +0000, Slava Ovsiienko wrote:
>
> > External Email
> >
> > ----------------------------------------------------------------------
Hi, Harman
Sorry for delay - missed your reply.
[..skip..]
> > Should we waste CPU cycles to wait the desired moment of time? Can we
> > guarantee stable interrupt latency if we choose to schedule on interrupts
> approach?
> >
> > This RFC splits the responsibility - application should prepare the
> > data and specify when it desires to send, the rest is on PMD.
>
> I agree with the fact that we cannot guarantee the delay between tx burst
> call and data on wire, hence PMD should take care of it.
> Even if PMD is holding, it is wastage of CPU cycles or if we setup an alarm
> then also interrupt latency might be a concern to achieve precise timming. So
> how are you planning to address both of above issue in PMD.
It is promoted to HW. The special WAIT descriptor with timestamp
is pushed to the queue and hardware just waits for the appropriate moment.
It is exactly the task for PMD - convert the timestamp in hardware related
entities and perform requested operation on hardware. Thus we should not
wait on CPU in any way - loop/interrupts, etc. Let NIC do it for us.
> >
> > > >
> > > > 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.
> >
> > Not sure - the intra-burst gap might be pretty small.
> > It is supposed to handle intra-burst in the same way - by specifying
> > the timestamps. Waiting is supposed to be implemented on tx_burst() retry.
> > Prepare the packets with timestamps, tx_burst - if not all packets are
> > sent - it means queue is waiting for the schedult, retry with the remaining
> packets.
> > As option - we can implement intra-burst wait basing rte_eth_read_clock().
>
> Yeah, I think app can make use of rte_eth_read_clock() to implement intra-
> burst gap.
> But my actual doubt was, what all information will app provide as part of
> "rte_dynfield_timestamp" - one I understand will be timestamp at which
> packets should be sent out. What else? intra-packet gap ?
Intra-packet gap is just the parameter of testpmd to provide some
preliminary feature testing. If intra-gap is too small even hardware might
not support. In mlx5 we are going to support the scheduling with minimal
granularity 250 nanoseconds, so minimal gap supported is 250ns,
on 100Gbps line speed it means at least two 1500B packets.
With best regards, Slava
@@ -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
@@ -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