DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API
@ 2018-07-18 14:51 alangordondewar
  2018-07-23 12:33 ` Alan Robertson
  2018-07-23 16:52 ` Stephen Hemminger
  0 siblings, 2 replies; 7+ messages in thread
From: alangordondewar @ 2018-07-18 14:51 UTC (permalink / raw)
  To: cristian.dumitrescu; +Cc: dev, Alan Dewar

From: Alan Dewar <alan.dewar@att.com>

Add new APIs to retrieve counters in 64-bit wide fields.

Signed-off-by: Alan Dewar <alan.dewar@att.com>
---
 lib/librte_sched/rte_sched.c           | 72 ++++++++++++++++++++++++++++++++
 lib/librte_sched/rte_sched.h           | 76 ++++++++++++++++++++++++++++++++++
 lib/librte_sched/rte_sched_version.map |  2 +
 3 files changed, 150 insertions(+)

diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 9269e5c..4396366 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -1070,6 +1070,43 @@ rte_sched_subport_read_stats(struct rte_sched_port *port,
 	return 0;
 }
 
+int __rte_experimental
+rte_sched_subport_read_stats64(struct rte_sched_port *port,
+			       uint32_t subport_id,
+			       struct rte_sched_subport_stats64 *stats64,
+			       uint32_t *tc_ov)
+{
+	struct rte_sched_subport *s;
+	uint32_t tc;
+
+	/* Check user parameters */
+	if (port == NULL || subport_id >= port->n_subports_per_port ||
+	    stats64 == NULL || tc_ov == NULL)
+		return -1;
+
+	s = port->subport + subport_id;
+
+	/* Copy subport stats and clear */
+	for (tc = 0; tc < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; tc++) {
+		stats64->n_pkts_tc[tc] = s->stats.n_pkts_tc[tc];
+		stats64->n_pkts_tc_dropped[tc] =
+			s->stats.n_pkts_tc_dropped[tc];
+		stats64->n_bytes_tc[tc] = s->stats.n_bytes_tc[tc];
+		stats64->n_bytes_tc_dropped[tc] =
+			s->stats.n_bytes_tc_dropped[tc];
+#ifdef RTE_SCHED_RED
+		stats64->n_pkts_red_dropped[tc] =
+			s->stats.n_pkts_red_dropped[tc];
+#endif
+	}
+	memset(&s->stats, 0, sizeof(struct rte_sched_subport_stats));
+
+	/* Subport TC oversubscription status */
+	*tc_ov = s->tc_ov;
+
+	return 0;
+}
+
 int
 rte_sched_queue_read_stats(struct rte_sched_port *port,
 	uint32_t queue_id,
@@ -1099,6 +1136,41 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
 	return 0;
 }
 
+int __rte_experimental
+rte_sched_queue_read_stats64(struct rte_sched_port *port,
+	uint32_t queue_id,
+	struct rte_sched_queue_stats64 *stats64,
+	uint16_t *qlen)
+{
+	struct rte_sched_queue *q;
+	struct rte_sched_queue_extra *qe;
+
+	/* Check user parameters */
+	if ((port == NULL) ||
+	    (queue_id >= rte_sched_port_queues_per_port(port)) ||
+		(stats64 == NULL) ||
+		(qlen == NULL)) {
+		return -1;
+	}
+	q = port->queue + queue_id;
+	qe = port->queue_extra + queue_id;
+
+	/* Copy queue stats and clear */
+	stats64->n_pkts = qe->stats.n_pkts;
+	stats64->n_pkts_dropped = qe->stats.n_pkts_dropped;
+	stats64->n_bytes = qe->stats.n_bytes;
+	stats64->n_bytes_dropped = qe->stats.n_bytes_dropped;
+#ifdef RTE_SCHED_RED
+	stats64->n_pkts_red_dropped = qe->stats.n_pkts_red_dropped;
+#endif
+	memset(&qe->stats, 0, sizeof(struct rte_sched_queue_stats));
+
+	/* Queue length */
+	*qlen = q->qw - q->qr;
+
+	return 0;
+}
+
 static inline uint32_t
 rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport, uint32_t pipe, uint32_t traffic_class, uint32_t queue)
 {
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index 84fa896..f37a4d6 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -141,6 +141,25 @@ struct rte_sched_subport_stats {
 #endif
 };
 
+struct rte_sched_subport_stats64 {
+	/* Packets */
+	uint64_t n_pkts_tc[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
+	/**< Number of packets successfully written */
+	uint64_t n_pkts_tc_dropped[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
+	/**< Number of packets dropped */
+
+	/* Bytes */
+	uint64_t n_bytes_tc[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
+	/**< Number of bytes successfully written for each traffic class */
+	uint64_t n_bytes_tc_dropped[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
+	/**< Number of bytes dropped for each traffic class */
+
+#ifdef RTE_SCHED_RED
+	uint64_t n_pkts_red_dropped[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
+	/**< Number of packets dropped by red */
+#endif
+};
+
 /*
  * Pipe configuration parameters. The period and credits_per_period
  * parameters are measured in bytes, with one byte meaning the time
@@ -182,6 +201,19 @@ struct rte_sched_queue_stats {
 	uint32_t n_bytes_dropped;        /**< Bytes dropped */
 };
 
+struct rte_sched_queue_stats64 {
+	/* Packets */
+	uint64_t n_pkts;                 /**< Packets successfully written */
+	uint64_t n_pkts_dropped;         /**< Packets dropped */
+#ifdef RTE_SCHED_RED
+	uint64_t n_pkts_red_dropped;	 /**< Packets dropped by RED */
+#endif
+
+	/* Bytes */
+	uint64_t n_bytes;                /**< Bytes successfully written */
+	uint64_t n_bytes_dropped;        /**< Bytes dropped */
+};
+
 /** Port configuration parameters. */
 struct rte_sched_port_params {
 	const char *name;                /**< String to be associated */
@@ -330,6 +362,28 @@ rte_sched_subport_read_stats(struct rte_sched_port *port,
 	uint32_t *tc_ov);
 
 /**
+ * Hierarchical scheduler subport statistics 64-bit read
+ *
+ * @param port
+ *   Handle to port scheduler instance
+ * @param subport_id
+ *   Subport ID
+ * @param stats64
+ *   Pointer to pre-allocated subport statistics structure where the 64-bit
+ *   statistics counters should be stored
+ * @param tc_ov
+ *   Pointer to pre-allocated 4-entry array where the oversubscription status
+ *   for each of the 4 subport traffic classes should be stored.
+ * @return
+ *   0 upon success, error code otherwise
+ */
+int __rte_experimental
+rte_sched_subport_read_stats64(struct rte_sched_port *port,
+	uint32_t subport_id,
+	struct rte_sched_subport_stats64 *stats64,
+	uint32_t *tc_ov);
+
+/**
  * Hierarchical scheduler queue statistics read
  *
  * @param port
@@ -352,6 +406,28 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
 	uint16_t *qlen);
 
 /**
+ * Hierarchical scheduler queue statistics 64-bit read
+ *
+ * @param port
+ *   Handle to port scheduler instance
+ * @param queue_id
+ *   Queue ID within port scheduler
+ * @param stats
+ *   Pointer to pre-allocated subport statistics structure where the
+ *   64-bit statistics counters should be stored
+ * @param qlen
+ *   Pointer to pre-allocated variable where the current queue length
+ *   should be stored.
+ * @return
+ *   0 upon success, error code otherwise
+ */
+int __rte_experimental
+rte_sched_queue_read_stats64(struct rte_sched_port *port,
+	uint32_t queue_id,
+	struct rte_sched_queue_stats64 *stats64,
+	uint16_t *qlen);
+
+/**
  * Scheduler hierarchy path write to packet descriptor. Typically
  * called by the packet classification stage.
  *
diff --git a/lib/librte_sched/rte_sched_version.map b/lib/librte_sched/rte_sched_version.map
index 7295887..01bf71a 100644
--- a/lib/librte_sched/rte_sched_version.map
+++ b/lib/librte_sched/rte_sched_version.map
@@ -34,4 +34,6 @@ EXPERIMENTAL {
 	global:
 
 	rte_sched_port_pipe_profile_add;
+	rte_sched_subport_read_stats64;
+	rte_sched_queue_read_stats64;
 };
-- 
2.7.4

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API
  2018-07-18 14:51 [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API alangordondewar
@ 2018-07-23 12:33 ` Alan Robertson
  2018-07-23 16:52 ` Stephen Hemminger
  1 sibling, 0 replies; 7+ messages in thread
From: Alan Robertson @ 2018-07-23 12:33 UTC (permalink / raw)
  To: alangordondewar; +Cc: Dumitrescu, Cristian, dev, Alan Dewar

Looks good to me.

Alan.

On Wed, Jul 18, 2018 at 3:51 PM,  <alangordondewar@gmail.com> wrote:
> From: Alan Dewar <alan.dewar@att.com>
>
> Add new APIs to retrieve counters in 64-bit wide fields.
>
> Signed-off-by: Alan Dewar <alan.dewar@att.com>
> ---
>  lib/librte_sched/rte_sched.c           | 72 ++++++++++++++++++++++++++++++++
>  lib/librte_sched/rte_sched.h           | 76 ++++++++++++++++++++++++++++++++++
>  lib/librte_sched/rte_sched_version.map |  2 +
>  3 files changed, 150 insertions(+)
>
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index 9269e5c..4396366 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -1070,6 +1070,43 @@ rte_sched_subport_read_stats(struct rte_sched_port *port,
>         return 0;
>  }
>
> +int __rte_experimental
> +rte_sched_subport_read_stats64(struct rte_sched_port *port,
> +                              uint32_t subport_id,
> +                              struct rte_sched_subport_stats64 *stats64,
> +                              uint32_t *tc_ov)
> +{
> +       struct rte_sched_subport *s;
> +       uint32_t tc;
> +
> +       /* Check user parameters */
> +       if (port == NULL || subport_id >= port->n_subports_per_port ||
> +           stats64 == NULL || tc_ov == NULL)
> +               return -1;
> +
> +       s = port->subport + subport_id;
> +
> +       /* Copy subport stats and clear */
> +       for (tc = 0; tc < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; tc++) {
> +               stats64->n_pkts_tc[tc] = s->stats.n_pkts_tc[tc];
> +               stats64->n_pkts_tc_dropped[tc] =
> +                       s->stats.n_pkts_tc_dropped[tc];
> +               stats64->n_bytes_tc[tc] = s->stats.n_bytes_tc[tc];
> +               stats64->n_bytes_tc_dropped[tc] =
> +                       s->stats.n_bytes_tc_dropped[tc];
> +#ifdef RTE_SCHED_RED
> +               stats64->n_pkts_red_dropped[tc] =
> +                       s->stats.n_pkts_red_dropped[tc];
> +#endif
> +       }
> +       memset(&s->stats, 0, sizeof(struct rte_sched_subport_stats));
> +
> +       /* Subport TC oversubscription status */
> +       *tc_ov = s->tc_ov;
> +
> +       return 0;
> +}
> +
>  int
>  rte_sched_queue_read_stats(struct rte_sched_port *port,
>         uint32_t queue_id,
> @@ -1099,6 +1136,41 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
>         return 0;
>  }
>
> +int __rte_experimental
> +rte_sched_queue_read_stats64(struct rte_sched_port *port,
> +       uint32_t queue_id,
> +       struct rte_sched_queue_stats64 *stats64,
> +       uint16_t *qlen)
> +{
> +       struct rte_sched_queue *q;
> +       struct rte_sched_queue_extra *qe;
> +
> +       /* Check user parameters */
> +       if ((port == NULL) ||
> +           (queue_id >= rte_sched_port_queues_per_port(port)) ||
> +               (stats64 == NULL) ||
> +               (qlen == NULL)) {
> +               return -1;
> +       }
> +       q = port->queue + queue_id;
> +       qe = port->queue_extra + queue_id;
> +
> +       /* Copy queue stats and clear */
> +       stats64->n_pkts = qe->stats.n_pkts;
> +       stats64->n_pkts_dropped = qe->stats.n_pkts_dropped;
> +       stats64->n_bytes = qe->stats.n_bytes;
> +       stats64->n_bytes_dropped = qe->stats.n_bytes_dropped;
> +#ifdef RTE_SCHED_RED
> +       stats64->n_pkts_red_dropped = qe->stats.n_pkts_red_dropped;
> +#endif
> +       memset(&qe->stats, 0, sizeof(struct rte_sched_queue_stats));
> +
> +       /* Queue length */
> +       *qlen = q->qw - q->qr;
> +
> +       return 0;
> +}
> +
>  static inline uint32_t
>  rte_sched_port_qindex(struct rte_sched_port *port, uint32_t subport, uint32_t pipe, uint32_t traffic_class, uint32_t queue)
>  {
> diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
> index 84fa896..f37a4d6 100644
> --- a/lib/librte_sched/rte_sched.h
> +++ b/lib/librte_sched/rte_sched.h
> @@ -141,6 +141,25 @@ struct rte_sched_subport_stats {
>  #endif
>  };
>
> +struct rte_sched_subport_stats64 {
> +       /* Packets */
> +       uint64_t n_pkts_tc[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
> +       /**< Number of packets successfully written */
> +       uint64_t n_pkts_tc_dropped[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
> +       /**< Number of packets dropped */
> +
> +       /* Bytes */
> +       uint64_t n_bytes_tc[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
> +       /**< Number of bytes successfully written for each traffic class */
> +       uint64_t n_bytes_tc_dropped[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
> +       /**< Number of bytes dropped for each traffic class */
> +
> +#ifdef RTE_SCHED_RED
> +       uint64_t n_pkts_red_dropped[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
> +       /**< Number of packets dropped by red */
> +#endif
> +};
> +
>  /*
>   * Pipe configuration parameters. The period and credits_per_period
>   * parameters are measured in bytes, with one byte meaning the time
> @@ -182,6 +201,19 @@ struct rte_sched_queue_stats {
>         uint32_t n_bytes_dropped;        /**< Bytes dropped */
>  };
>
> +struct rte_sched_queue_stats64 {
> +       /* Packets */
> +       uint64_t n_pkts;                 /**< Packets successfully written */
> +       uint64_t n_pkts_dropped;         /**< Packets dropped */
> +#ifdef RTE_SCHED_RED
> +       uint64_t n_pkts_red_dropped;     /**< Packets dropped by RED */
> +#endif
> +
> +       /* Bytes */
> +       uint64_t n_bytes;                /**< Bytes successfully written */
> +       uint64_t n_bytes_dropped;        /**< Bytes dropped */
> +};
> +
>  /** Port configuration parameters. */
>  struct rte_sched_port_params {
>         const char *name;                /**< String to be associated */
> @@ -330,6 +362,28 @@ rte_sched_subport_read_stats(struct rte_sched_port *port,
>         uint32_t *tc_ov);
>
>  /**
> + * Hierarchical scheduler subport statistics 64-bit read
> + *
> + * @param port
> + *   Handle to port scheduler instance
> + * @param subport_id
> + *   Subport ID
> + * @param stats64
> + *   Pointer to pre-allocated subport statistics structure where the 64-bit
> + *   statistics counters should be stored
> + * @param tc_ov
> + *   Pointer to pre-allocated 4-entry array where the oversubscription status
> + *   for each of the 4 subport traffic classes should be stored.
> + * @return
> + *   0 upon success, error code otherwise
> + */
> +int __rte_experimental
> +rte_sched_subport_read_stats64(struct rte_sched_port *port,
> +       uint32_t subport_id,
> +       struct rte_sched_subport_stats64 *stats64,
> +       uint32_t *tc_ov);
> +
> +/**
>   * Hierarchical scheduler queue statistics read
>   *
>   * @param port
> @@ -352,6 +406,28 @@ rte_sched_queue_read_stats(struct rte_sched_port *port,
>         uint16_t *qlen);
>
>  /**
> + * Hierarchical scheduler queue statistics 64-bit read
> + *
> + * @param port
> + *   Handle to port scheduler instance
> + * @param queue_id
> + *   Queue ID within port scheduler
> + * @param stats
> + *   Pointer to pre-allocated subport statistics structure where the
> + *   64-bit statistics counters should be stored
> + * @param qlen
> + *   Pointer to pre-allocated variable where the current queue length
> + *   should be stored.
> + * @return
> + *   0 upon success, error code otherwise
> + */
> +int __rte_experimental
> +rte_sched_queue_read_stats64(struct rte_sched_port *port,
> +       uint32_t queue_id,
> +       struct rte_sched_queue_stats64 *stats64,
> +       uint16_t *qlen);
> +
> +/**
>   * Scheduler hierarchy path write to packet descriptor. Typically
>   * called by the packet classification stage.
>   *
> diff --git a/lib/librte_sched/rte_sched_version.map b/lib/librte_sched/rte_sched_version.map
> index 7295887..01bf71a 100644
> --- a/lib/librte_sched/rte_sched_version.map
> +++ b/lib/librte_sched/rte_sched_version.map
> @@ -34,4 +34,6 @@ EXPERIMENTAL {
>         global:
>
>         rte_sched_port_pipe_profile_add;
> +       rte_sched_subport_read_stats64;
> +       rte_sched_queue_read_stats64;
>  };
> --
> 2.7.4
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API
  2018-07-18 14:51 [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API alangordondewar
  2018-07-23 12:33 ` Alan Robertson
@ 2018-07-23 16:52 ` Stephen Hemminger
  2018-07-25  9:02   ` Alan Dewar
  1 sibling, 1 reply; 7+ messages in thread
From: Stephen Hemminger @ 2018-07-23 16:52 UTC (permalink / raw)
  To: alangordondewar; +Cc: cristian.dumitrescu, dev, Alan Dewar

On Wed, 18 Jul 2018 15:51:39 +0100
alangordondewar@gmail.com wrote:

> From: Alan Dewar <alan.dewar@att.com>
> 
> Add new APIs to retrieve counters in 64-bit wide fields.
> 
> Signed-off-by: Alan Dewar <alan.dewar@att.com>

Do you want to consider 64 bit counter roll over on 32 bit platform?
The problem is that incrementing an 64 bit value is not atomic on
32 bit cpu. The carry operation can race with reading.

The kernel has special case code to do restartable sequence for
accessing 64 bit counter on 32 bit CPU. These functions become
nop's on 64bit.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API
  2018-07-23 16:52 ` Stephen Hemminger
@ 2018-07-25  9:02   ` Alan Dewar
  2020-06-24 22:51     ` Thomas Monjalon
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Dewar @ 2018-07-25  9:02 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: cristian.dumitrescu, dev, Alan Dewar

Hi Stephen,

Sorry about the delay in responding to your comment.

Maybe I'm missing something but I don't consider 64-bit counter
rollover to be a problem.
The DPDK QoS stats are just 32-bits wide and are zeroed when read.  So
if we read them frequently enough the 32-bit counters won't wrap.

This new API is just a convenient way to read the 32-bit counters into
variables that are 64-bit wide which allows Vyatta to have a common
API slightly above the DPDK.

I'd hope that at some point in time the DPDK will move to 64-bit
counters, but there may be technical reasons why this can't happen
that I'm not aware of (support for 32-bit CPUs??)

Regards
Alan

On Mon, Jul 23, 2018 at 5:52 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> On Wed, 18 Jul 2018 15:51:39 +0100
> alangordondewar@gmail.com wrote:
>
>> From: Alan Dewar <alan.dewar@att.com>
>>
>> Add new APIs to retrieve counters in 64-bit wide fields.
>>
>> Signed-off-by: Alan Dewar <alan.dewar@att.com>
>
> Do you want to consider 64 bit counter roll over on 32 bit platform?
> The problem is that incrementing an 64 bit value is not atomic on
> 32 bit cpu. The carry operation can race with reading.
>
> The kernel has special case code to do restartable sequence for
> accessing 64 bit counter on 32 bit CPU. These functions become
> nop's on 64bit.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API
  2018-07-25  9:02   ` Alan Dewar
@ 2020-06-24 22:51     ` Thomas Monjalon
  2020-06-25  8:38       ` Singh, Jasvinder
  0 siblings, 1 reply; 7+ messages in thread
From: Thomas Monjalon @ 2020-06-24 22:51 UTC (permalink / raw)
  To: cristian.dumitrescu, Alan Dewar, jasvinder.singh
  Cc: Stephen Hemminger, dev, Alan Dewar

Is this old patch still relevant?


25/07/2018 11:02, Alan Dewar:
> Hi Stephen,
> 
> Sorry about the delay in responding to your comment.
> 
> Maybe I'm missing something but I don't consider 64-bit counter
> rollover to be a problem.
> The DPDK QoS stats are just 32-bits wide and are zeroed when read.  So
> if we read them frequently enough the 32-bit counters won't wrap.
> 
> This new API is just a convenient way to read the 32-bit counters into
> variables that are 64-bit wide which allows Vyatta to have a common
> API slightly above the DPDK.
> 
> I'd hope that at some point in time the DPDK will move to 64-bit
> counters, but there may be technical reasons why this can't happen
> that I'm not aware of (support for 32-bit CPUs??)
> 
> Regards
> Alan
> 
> On Mon, Jul 23, 2018 at 5:52 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Wed, 18 Jul 2018 15:51:39 +0100
> > alangordondewar@gmail.com wrote:
> >
> >> From: Alan Dewar <alan.dewar@att.com>
> >>
> >> Add new APIs to retrieve counters in 64-bit wide fields.
> >>
> >> Signed-off-by: Alan Dewar <alan.dewar@att.com>
> >
> > Do you want to consider 64 bit counter roll over on 32 bit platform?
> > The problem is that incrementing an 64 bit value is not atomic on
> > 32 bit cpu. The carry operation can race with reading.
> >
> > The kernel has special case code to do restartable sequence for
> > accessing 64 bit counter on 32 bit CPU. These functions become
> > nop's on 64bit.
> 






^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API
  2020-06-24 22:51     ` Thomas Monjalon
@ 2020-06-25  8:38       ` Singh, Jasvinder
  2020-06-25  9:16         ` Thomas Monjalon
  0 siblings, 1 reply; 7+ messages in thread
From: Singh, Jasvinder @ 2020-06-25  8:38 UTC (permalink / raw)
  To: Thomas Monjalon, Dumitrescu, Cristian, Alan Dewar
  Cc: Stephen Hemminger, dev, Alan Dewar



> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Wednesday, June 24, 2020 11:51 PM
> To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; Alan Dewar
> <alan.dewar@att.com>; Singh, Jasvinder <jasvinder.singh@intel.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>; dev@dpdk.org;
> Alan Dewar <alangordondewar@gmail.com>
> Subject: Re: [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API
> 
> Is this old patch still relevant?
> 
> 
> 25/07/2018 11:02, Alan Dewar:
> > Hi Stephen,
> >
> > Sorry about the delay in responding to your comment.
> >
> > Maybe I'm missing something but I don't consider 64-bit counter
> > rollover to be a problem.
> > The DPDK QoS stats are just 32-bits wide and are zeroed when read.  So
> > if we read them frequently enough the 32-bit counters won't wrap.
> >
> > This new API is just a convenient way to read the 32-bit counters into
> > variables that are 64-bit wide which allows Vyatta to have a common
> > API slightly above the DPDK.
> >
> > I'd hope that at some point in time the DPDK will move to 64-bit
> > counters, but there may be technical reasons why this can't happen
> > that I'm not aware of (support for 32-bit CPUs??)
> >
> > Regards
> > Alan
> >
> > On Mon, Jul 23, 2018 at 5:52 PM, Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> > > On Wed, 18 Jul 2018 15:51:39 +0100
> > > alangordondewar@gmail.com wrote:
> > >
> > >> From: Alan Dewar <alan.dewar@att.com>
> > >>
> > >> Add new APIs to retrieve counters in 64-bit wide fields.
> > >>
> > >> Signed-off-by: Alan Dewar <alan.dewar@att.com>
> > >
> > > Do you want to consider 64 bit counter roll over on 32 bit platform?
> > > The problem is that incrementing an 64 bit value is not atomic on
> > > 32 bit cpu. The carry operation can race with reading.
> > >
> > > The kernel has special case code to do restartable sequence for
> > > accessing 64 bit counter on 32 bit CPU. These functions become nop's
> > > on 64bit.
> >

The stats params have been converted into 64 bit values during library rework last year. Therefore, patch is not relevant anymore.

Thank you,
Jasvinder
 

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API
  2020-06-25  8:38       ` Singh, Jasvinder
@ 2020-06-25  9:16         ` Thomas Monjalon
  0 siblings, 0 replies; 7+ messages in thread
From: Thomas Monjalon @ 2020-06-25  9:16 UTC (permalink / raw)
  To: Singh, Jasvinder
  Cc: Dumitrescu, Cristian, Alan Dewar, Stephen Hemminger, dev, Alan Dewar

25/06/2020 10:38, Singh, Jasvinder:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 
> > Is this old patch still relevant?
> 
> The stats params have been converted into 64 bit values during library rework last year.
> Therefore, patch is not relevant anymore.

OK, this patch is marked as rejected then.
Thanks



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-06-25  9:16 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-18 14:51 [dpdk-dev] [PATCH] sched: add 64-bit counter retrieval API alangordondewar
2018-07-23 12:33 ` Alan Robertson
2018-07-23 16:52 ` Stephen Hemminger
2018-07-25  9:02   ` Alan Dewar
2020-06-24 22:51     ` Thomas Monjalon
2020-06-25  8:38       ` Singh, Jasvinder
2020-06-25  9:16         ` Thomas Monjalon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).