[dpdk-dev] API feature check _HAS_

[Vlad Zolotarov]

On 11/26/15 22:35, Thomas Monjalon wrote:
> When introducing LRO, Vlad has defined the macro RTE_ETHDEV_HAS_LRO_SUPPORT:
> http://dpdk.org/browse/dpdk/commit/lib/librte_ether/rte_ethdev.h?id=8eecb329
>
> It allows to use the feature without version check (before the release or
> after a backport).
> Do you think it is useful?
> Should we define other macros RTE_[API]_HAS_[FEATURE] for each new feature
> or API change?

The main purpose of the above macro was to identify the presence of the 
new field in the rte_eth_rxmode during the
period of time when there was no other way to know it. Once this may be 
concluded based on the release version I see no
reason to keep it.

> It's time to fix it before releasing the 2.2 version.

[dpdk-dev] API feature check _HAS_

[Gleb Natapov]

On Sun, Nov 29, 2015 at 11:07:44AM +0200, Vlad Zolotarov wrote:
> 
> 
> On 11/26/15 22:35, Thomas Monjalon wrote:
> >When introducing LRO, Vlad has defined the macro RTE_ETHDEV_HAS_LRO_SUPPORT:
> >http://dpdk.org/browse/dpdk/commit/lib/librte_ether/rte_ethdev.h?id=8eecb329
> >
> >It allows to use the feature without version check (before the release or
> >after a backport).
> >Do you think it is useful?
> >Should we define other macros RTE_[API]_HAS_[FEATURE] for each new feature
> >or API change?
> 
> The main purpose of the above macro was to identify the presence of the new
> field in the rte_eth_rxmode during the
> period of time when there was no other way to know it. Once this may be
> concluded based on the release version I see no
> reason to keep it.
> 
Concluding things based on release version does not work so well for
back ports.

> >It's time to fix it before releasing the 2.2 version.
> 

--
Gleb.

[dpdk-dev] API feature check _HAS_

[Vlad Zolotarov]

On 11/29/15 11:10, Gleb Natapov wrote:
> On Sun, Nov 29, 2015 at 11:07:44AM +0200, Vlad Zolotarov wrote:
>>
>> On 11/26/15 22:35, Thomas Monjalon wrote:
>>> When introducing LRO, Vlad has defined the macro RTE_ETHDEV_HAS_LRO_SUPPORT:
>>> http://dpdk.org/browse/dpdk/commit/lib/librte_ether/rte_ethdev.h?id=8eecb329
>>>
>>> It allows to use the feature without version check (before the release or
>>> after a backport).
>>> Do you think it is useful?
>>> Should we define other macros RTE_[API]_HAS_[FEATURE] for each new feature
>>> or API change?
>> The main purpose of the above macro was to identify the presence of the new
>> field in the rte_eth_rxmode during the
>> period of time when there was no other way to know it. Once this may be
>> concluded based on the release version I see no
>> reason to keep it.
>>
> Concluding things based on release version does not work so well for
> back ports.

In that case the existing applications won't be able to enjoy the 
feature with the older releases with the backport - that's true.
Having this flag has it's benefits (e.g. the corresponding ifdefs are 
much more readable), however to be consistent we'd rather define this 
type of flags
for other features too like Thomas wrote above. I'm not against this 
approach too...

>
>>> It's time to fix it before releasing the 2.2 version.
> --
>   Gleb.

[dpdk-dev] [PATCH v3 2/2] config: disable CONFIG_RTE_SCHED_VECTOR for arm

[Jianbo Liu]

On Fri, Nov 27, 2015 at 07:04:28PM +0530, Jerin Jacob wrote:
> Commit 42ec27a0178a causes compiling error on arm, as RTE_SCHED_VECTOR
> does support only SSE intrinsic, so disable it till we have neon support.
> 
> Fixes: 42ec27a0178a ("sched: enable SSE optimizations in config")
> 
> Signed-off-by: Jerin Jacob 
> ---
>  config/common_arm64  | 1 +
>  config/defconfig_arm-armv7a-linuxapp-gcc | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/config/common_arm64 b/config/common_arm64
> index 5e5e303..d6a9cb9 100644
> --- a/config/common_arm64
> +++ b/config/common_arm64
> @@ -46,3 +46,4 @@ CONFIG_RTE_LIBRTE_I40E_PMD=n
>  CONFIG_RTE_LIBRTE_LPM=n
>  CONFIG_RTE_LIBRTE_TABLE=n
>  CONFIG_RTE_LIBRTE_PIPELINE=n
> +CONFIG_RTE_SCHED_VECTOR=n
> diff --git a/config/defconfig_arm-armv7a-linuxapp-gcc 
> b/config/defconfig_arm-armv7a-linuxapp-gcc
> index 82143af..9924ff9 100644
> --- a/config/defconfig_arm-armv7a-linuxapp-gcc
> +++ b/config/defconfig_arm-armv7a-linuxapp-gcc
> @@ -57,6 +57,7 @@ CONFIG_RTE_LIBRTE_ACL=n
>  CONFIG_RTE_LIBRTE_LPM=n
>  CONFIG_RTE_LIBRTE_TABLE=n
>  CONFIG_RTE_LIBRTE_PIPELINE=n
> +CONFIG_RTE_SCHED_VECTOR=n
>  
>  # cannot use those on ARM
>  CONFIG_RTE_KNI_KMOD=n
> -- 
> 2.1.0
> 

Hi Jerin,
In this way, we still have to modify two files each time a new feature
is added but not verified on ARM architectures.
Since disabling those drivers and libs are common for both armv7 and
armv8, can you put them in one config file, for example: common_arm? 
It is not like common_arm64, which is solely for armv8 platform.
Actually, the arm64 common config is defconfig_arm64-armv8a-linuxapp-gcc
you can include it in the thunderx or xgene1 config files respectively,
and overriding some special config if needed.

On the other hand, If we support the features in the future by
replacing SSE intrinsic with NEON, we just need to remove the lines in one 
place.

Regards,
Jianbo

[dpdk-dev] [PATCH 0/3] sched: patches for 2.2

[Stephen Hemminger]

This is the last round of sched updates for 2.2. It is based
on code changes (extensively) tested by QA and used in the vRouter.

Stephen Hemminger (3):
  rte_sched: keep track of RED drops
  rte_sched: introduce reciprocal divide
  rte_sched: eliminate floating point in calculating byte clock

 lib/librte_sched/Makefile |  6 ++--
 lib/librte_sched/rte_reciprocal.c | 72 +++
 lib/librte_sched/rte_reciprocal.h | 39 +
 lib/librte_sched/rte_sched.c  | 43 ++-
 lib/librte_sched/rte_sched.h  |  8 +
 5 files changed, 157 insertions(+), 11 deletions(-)
 create mode 100644 lib/librte_sched/rte_reciprocal.c
 create mode 100644 lib/librte_sched/rte_reciprocal.h

-- 
2.1.4

[dpdk-dev] [PATCH 1/3] rte_sched: keep track of RED drops

[Stephen Hemminger]

Add new statistic to keep track of drops due to RED.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_sched/rte_sched.c | 20 
 lib/librte_sched/rte_sched.h |  8 
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index d47cfc2..16acd6b 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -1071,7 +1071,9 @@ rte_sched_port_update_subport_stats(struct rte_sched_port 
*port, uint32_t qindex
 }

 static inline void
-rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port, 
uint32_t qindex, struct rte_mbuf *pkt)
+rte_sched_port_update_subport_stats_on_drop(struct rte_sched_port *port,
+   uint32_t qindex,
+   struct rte_mbuf *pkt, uint32_t red)
 {
struct rte_sched_subport *s = port->subport + (qindex / 
rte_sched_port_queues_per_subport(port));
uint32_t tc_index = (qindex >> 2) & 0x3;
@@ -1079,6 +1081,9 @@ rte_sched_port_update_subport_stats_on_drop(struct 
rte_sched_port *port, uint32_

s->stats.n_pkts_tc_dropped[tc_index] += 1;
s->stats.n_bytes_tc_dropped[tc_index] += pkt_len;
+#ifdef RTE_SCHED_RED
+   s->stats.n_pkts_red_dropped[tc_index] += red;
+#endif
 }

 static inline void
@@ -1092,13 +1097,18 @@ rte_sched_port_update_queue_stats(struct rte_sched_port 
*port, uint32_t qindex,
 }

 static inline void
-rte_sched_port_update_queue_stats_on_drop(struct rte_sched_port *port, 
uint32_t qindex, struct rte_mbuf *pkt)
+rte_sched_port_update_queue_stats_on_drop(struct rte_sched_port *port,
+ uint32_t qindex,
+ struct rte_mbuf *pkt, uint32_t red)
 {
struct rte_sched_queue_extra *qe = port->queue_extra + qindex;
uint32_t pkt_len = pkt->pkt_len;

qe->stats.n_pkts_dropped += 1;
qe->stats.n_bytes_dropped += pkt_len;
+#ifdef RTE_SCHED_RED
+   qe->stats.n_pkts_red_dropped += red;
+#endif
 }

 #endif /* RTE_SCHED_COLLECT_STATS */
@@ -1229,8 +1239,10 @@ rte_sched_port_enqueue_qwa(struct rte_sched_port *port, 
uint32_t qindex,
 (qlen >= qsize))) {
rte_pktmbuf_free(pkt);
 #ifdef RTE_SCHED_COLLECT_STATS
-   rte_sched_port_update_subport_stats_on_drop(port, qindex, pkt);
-   rte_sched_port_update_queue_stats_on_drop(port, qindex, pkt);
+   rte_sched_port_update_subport_stats_on_drop(port, qindex, pkt,
+   qlen < qsize);
+   rte_sched_port_update_queue_stats_on_drop(port, qindex, pkt,
+ qlen < qsize);
 #endif
return 0;
}
diff --git a/lib/librte_sched/rte_sched.h b/lib/librte_sched/rte_sched.h
index c0f4ad3..e9c2817 100644
--- a/lib/librte_sched/rte_sched.h
+++ b/lib/librte_sched/rte_sched.h
@@ -162,6 +162,11 @@ struct rte_sched_subport_stats {
/**< Number of bytes successfully written for each traffic class */
uint32_t n_bytes_tc_dropped[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
/**< Number of bytes dropped for each traffic class */
+
+#ifdef RTE_SCHED_RED
+   uint32_t n_pkts_red_dropped[RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE];
+   /**< Number of packets dropped by red */
+#endif
 };

 /*
@@ -196,6 +201,9 @@ struct rte_sched_queue_stats {
/* Packets */
uint32_t n_pkts; /**< Packets successfully written */
uint32_t n_pkts_dropped; /**< Packets dropped */
+#ifdef RTE_SCHED_RED
+   uint32_t n_pkts_red_dropped; /**< Packets dropped by RED */
+#endif

/* Bytes */
uint32_t n_bytes;/**< Bytes successfully written */
-- 
2.1.4

[dpdk-dev] [PATCH 2/3] rte_sched: introduce reciprocal divide

[Stephen Hemminger]

This adds (with permission of the original author)
reciprocal divide based on algorithm in Linux.

Signed-off-by: Stephen Hemminger 
Signed-off-by: Hannes Frederic Sowa 
---
 lib/librte_sched/Makefile |  6 ++--
 lib/librte_sched/rte_reciprocal.c | 72 +++
 lib/librte_sched/rte_reciprocal.h | 39 +
 3 files changed, 115 insertions(+), 2 deletions(-)
 create mode 100644 lib/librte_sched/rte_reciprocal.c
 create mode 100644 lib/librte_sched/rte_reciprocal.h

diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile
index b1cb285..e0a2c6d 100644
--- a/lib/librte_sched/Makefile
+++ b/lib/librte_sched/Makefile
@@ -48,10 +48,12 @@ LIBABIVER := 1
 #
 # all source are stored in SRCS-y
 #
-SRCS-$(CONFIG_RTE_LIBRTE_SCHED) += rte_sched.c rte_red.c rte_approx.c
+SRCS-$(CONFIG_RTE_LIBRTE_SCHED) += rte_sched.c rte_red.c rte_approx.c \
+   rte_reciprocal.c

 # install includes
-SYMLINK-$(CONFIG_RTE_LIBRTE_SCHED)-include := rte_sched.h rte_bitmap.h 
rte_sched_common.h rte_red.h rte_approx.h
+SYMLINK-$(CONFIG_RTE_LIBRTE_SCHED)-include := rte_sched.h rte_bitmap.h \
+   rte_sched_common.h rte_red.h rte_approx.h rte_reciprocal.h

 # this lib depends upon:
 DEPDIRS-$(CONFIG_RTE_LIBRTE_SCHED) += lib/librte_mempool lib/librte_mbuf
diff --git a/lib/librte_sched/rte_reciprocal.c 
b/lib/librte_sched/rte_reciprocal.c
new file mode 100644
index 000..652f023
--- /dev/null
+++ b/lib/librte_sched/rte_reciprocal.c
@@ -0,0 +1,72 @@
+/*-
+ *   BSD LICENSE
+ *
+ *   Copyright(c) Hannes Frederic Sowa
+ *   All rights reserved.
+ *
+ *   Redistribution and use in source and binary forms, with or without
+ *   modification, are permitted provided that the following conditions
+ *   are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ *   notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ *   notice, this list of conditions and the following disclaimer in
+ *   the documentation and/or other materials provided with the
+ *   distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ *   contributors may be used to endorse or promote products derived
+ *   from this software without specific prior written permission.
+ *
+ *   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ *   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "rte_reciprocal.h"
+
+/* find largest set bit.
+ * portable and slow but does not matter for this usage.
+ */
+static inline int fls(uint32_t x)
+{
+   int b;
+
+   for (b = 31; b >= 0; --b) {
+   if (x & (1u << b))
+   return b + 1;
+   }
+
+   return 0;
+}
+
+struct rte_reciprocal rte_reciprocal_value(uint32_t d)
+{
+   struct rte_reciprocal R;
+   uint64_t m;
+   int l;
+
+   l = fls(d - 1);
+   m = ((1ULL << 32) * ((1ULL << l) - d));
+   m /= d;
+
+   ++m;
+   R.m = m;
+   R.sh1 = RTE_MIN(l, 1);
+   R.sh2 = RTE_MAX(l - 1, 0);
+
+   return R;
+}
diff --git a/lib/librte_sched/rte_reciprocal.h 
b/lib/librte_sched/rte_reciprocal.h
new file mode 100644
index 000..abd1525
--- /dev/null
+++ b/lib/librte_sched/rte_reciprocal.h
@@ -0,0 +1,39 @@
+/*
+ * Reciprocal divide
+ *
+ * Used with permission from original authors
+ *  Hannes Frederic Sowa and Daniel Borkmann
+ *
+ * This algorithm is based on the paper "Division by Invariant
+ * Integers Using Multiplication" by Torbj??rn Granlund and Peter
+ * L. Montgomery.
+ *
+ * The assembler implementation from Agner Fog, which this code is
+ * based on, can be found here:
+ * http://www.agner.org/optimize/asmlib.zip
+ *
+ * This optimization for A/B is helpful if the divisor B is mostly
+ * runtime invariant. The reciprocal of B is calculated in the
+ * slow-path with reciprocal_value(). The fast-path can then just use
+ * a much faster multiplication operation with a variable dividend A
+ * to calculate the division A/B.
+ */
+
+#ifndef _RTE_RECIPROCAL_H_
+#define _RTE_RECIPROCAL_H_
+
+struct rte_reciprocal {
+   uint32_t m;
+   uint8_t sh1, sh2;
+};
+
+static inline uint32_

[dpdk-dev] [PATCH 3/3] rte_sched: eliminate floating point in calculating byte clock

[Stephen Hemminger]

The old code was doing a floating point divide for each rte_dequeue()
which is very expensive. Change to using fixed point scaled inverse
multiply. To maintain equivalent precision, scaled math is used.
The application ABI is the same.

This improved performance from 5Gbit/sec to 10 Gbit/sec when configured
for 10 Gbit/sec rate.

There was some feedback from Cristian that he wanted a better
solution and was going to give one, but none was provided.
For 2.2 this is a better solution than existing code, if someone
has a better version I would love to see it.

Signed-off-by: Stephen Hemminger 
---
 lib/librte_sched/rte_sched.c | 23 ++-
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 16acd6b..cfae136 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -47,6 +47,7 @@
 #include "rte_bitmap.h"
 #include "rte_sched_common.h"
 #include "rte_approx.h"
+#include "rte_reciprocal.h"

 #ifdef __INTEL_COMPILER
 #pragma warning(disable:2259) /* conversion may lose significant bits */
@@ -62,6 +63,11 @@
 #define RTE_SCHED_PIPE_INVALIDUINT32_MAX
 #define RTE_SCHED_BMP_POS_INVALID UINT32_MAX

+/* Scaling for cycles_per_byte calculation
+ * Chosen so that minimum rate is 480 bit/sec
+ */
+#define RTE_SCHED_TIME_SHIFT 8
+
 struct rte_sched_subport {
/* Token bucket (TB) */
uint64_t tb_time; /* time of last update */
@@ -215,7 +221,7 @@ struct rte_sched_port {
uint64_t time_cpu_cycles; /* Current CPU time measured in CPU cyles 
*/
uint64_t time_cpu_bytes;  /* Current CPU time measured in bytes */
uint64_t time;/* Current NIC TX time measured in bytes 
*/
-   double cycles_per_byte;   /* CPU cycles per byte */
+   struct rte_reciprocal inv_cycles_per_byte; /* CPU cycles per byte */

/* Scheduling loop detection */
uint32_t pipe_loop;
@@ -610,7 +616,7 @@ struct rte_sched_port *
 rte_sched_port_config(struct rte_sched_port_params *params)
 {
struct rte_sched_port *port = NULL;
-   uint32_t mem_size, bmp_mem_size, n_queues_per_port, i;
+   uint32_t mem_size, bmp_mem_size, n_queues_per_port, i, cycles_per_byte;

/* Check user parameters. Determine the amount of memory to allocate */
mem_size = rte_sched_port_get_memory_footprint(params);
@@ -661,7 +667,10 @@ rte_sched_port_config(struct rte_sched_port_params *params)
port->time_cpu_cycles = rte_get_tsc_cycles();
port->time_cpu_bytes = 0;
port->time = 0;
-   port->cycles_per_byte = ((double) rte_get_tsc_hz()) / ((double) 
params->rate);
+
+   cycles_per_byte = (rte_get_tsc_hz() << RTE_SCHED_TIME_SHIFT)
+   / params->rate;
+   port->inv_cycles_per_byte = rte_reciprocal_value(cycles_per_byte);

/* Scheduling loop detection */
port->pipe_loop = RTE_SCHED_PIPE_INVALID;
@@ -2088,11 +2097,15 @@ rte_sched_port_time_resync(struct rte_sched_port *port)
 {
uint64_t cycles = rte_get_tsc_cycles();
uint64_t cycles_diff = cycles - port->time_cpu_cycles;
-   double bytes_diff = ((double) cycles_diff) / port->cycles_per_byte;
+   uint64_t bytes_diff;
+
+   /* Compute elapsed time in bytes */
+   bytes_diff = rte_reciprocal_divide(cycles_diff << RTE_SCHED_TIME_SHIFT,
+  port->inv_cycles_per_byte);

/* Advance port time */
port->time_cpu_cycles = cycles;
-   port->time_cpu_bytes += (uint64_t) bytes_diff;
+   port->time_cpu_bytes += bytes_diff;
if (port->time < port->time_cpu_bytes)
port->time = port->time_cpu_bytes;

-- 
2.1.4

[dpdk-dev] Fwd: port-queue-process

[De Lara Guarch, Pablo]

Hi,



> From: Nishant Verma [mailto:vnish11 at gmail.com]

> Sent: Saturday, November 28, 2015 7:28 PM

> To: De Lara Guarch, Pablo

> Cc: dev at dpdk.org

> Subject: Re: [dpdk-dev] Fwd: port-queue-process

>

> Thanks for the reply.

> Got your point. It means, suppose DPDK app is getting packet from 10

> different source. On very first packet from any source, we first check source

> MAC address and then search what queue we have used last time, and

> placed in the same else choose the queue based on some factors.?



What do you mean with sources? Are you getting all packets in the same port, 
right?

If so, you can identify the sources by the differences between packets, such as 
the L2, L3? headers.

It looks like you want to add rules dynamically, so at first you don?t know 
what your sources are,

but as you get packets from different sources, you can assign them to different 
cores.

In that case, yes, you could see what queues you used so far, and assign it to 
a queue that is not being used,

but that depends on what the core is going to do with that flow (from a source).

I mean, if you are going to run the same code for all packets, but in different 
cores,

then probably something like RSS can work for you, but if the code is going to 
be different

depending on the source, then you need to know in advance these sources

and program flow director accordingly.



> One more thing, suppose if DPDK app is getting packet from one single

> source and that source is handling 10 different source? In that case how we

> make diffenence?



In this case, I guess your worry is that you would have same L2 header for all 
sources?

As long as you can identify your source in any field of the packet (probably L3 
header),

it doesn?t matter if you are in the first scenario or this one.



Pablo



> Thanks.

>

> On Sat, Nov 28, 2015 at 2:12 PM, De Lara Guarch, Pablo

> mailto:pablo.de.lara.guarch at intel.com>> 
> wrote:

> Hi Nishant,

>

> > -Original Message-

> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nishant Verma

> > Sent: Saturday, November 28, 2015 5:42 AM

> > To: dev at dpdk.org

> > Subject: [dpdk-dev] Fwd: port-queue-process

> >

> > Hi All,

> >

> > I have one doubt about dpdk.

> >

> > Question. Suppose on 8 core machine DPDK process is running on all

> cores,

> > all process has its own Rx & Tx queue. My question is, let we have a

> packet

> > from some network for DPDK application running on 2nd core, how it will

> > reach to 2nd core and not to some other core.

> >

> > Any clue and reference will be appreciated. It might seems to little doubt

> > but as i don't know, its big for me.

>

> I think what you are looking for is packet filtering and queue assignment,

> specifically, Flow Director. I assume you have one port and several queues

> in that port:

> you will need assign each queue to a different core, and program the device

> in a way that

> packets with a particular source MAC address or IP address will go to a

> specified queue,

> so the desired core can poll the packets from that queue.

>

> Let me know if you have any more questions,

>

> Pablo

>

> >

> > ?thanks.

> >

> > --

> > Rgds,

> >

> > NV?

>

>

>

> --

> Rgds,

> ?NV

[dpdk-dev] [PATCH 1/3] rte_sched: keep track of RED drops

[Thomas Monjalon]

2015-11-29 10:46, Stephen Hemminger:
> Add new statistic to keep track of drops due to RED.
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  lib/librte_sched/rte_sched.c | 20 
>  lib/librte_sched/rte_sched.h |  8 
>  2 files changed, 24 insertions(+), 4 deletions(-)

You should update doc/guides/rel_notes/deprecation.rst at the same time
to remove the related deprecation notice.
Thanks