[dpdk-dev] [PATCH v2 1/1] ethdev: distinguish between drop and error stats

[dpdk-dev] [PATCH v2 1/1] ethdev: distinguish between drop and error stats

[Maryam Tahhan]

Make a distniction between dropped packets and error statistics to allow
a higher level fault management entity to interact with DPDK and take
appropriate measures when errors are detected. It will also provide
valuable information for any applications that collects/extracts DPDK
stats, such applications include Open vSwitch.
After this patch the distinction is:
ierrors = Total number of packets dropped by hardware (malformed
packets, ...) Where the # of drops can ONLY be <=  the packets received
(without overlap between registers).
ipkterrors = Total number of erroneous received packets. Where the #
of errors can be >= the packets received (without overlap between
registers), this is because there may be multiple errors associated with
a packet.

v2:
 - Added detailed descriptions for ierrors and ipkterrors.

Signed-off-by: Maryam Tahhan <maryam.tahhan@intel.com>
---
 lib/librte_ether/rte_ethdev.h | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 8a8c82b..e27ba31 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -200,8 +200,18 @@ struct rte_eth_stats {
 	/**< Deprecated; Total of RX packets with CRC error. */
 	uint64_t ibadlen;
 	/**< Deprecated; Total of RX packets with bad length. */
-	uint64_t ierrors;   /**< Total number of erroneous received packets. */
+	uint64_t ierrors;
+	/**< Total number of packets dropped by hardware (malformed packets...)
+	 * Where the # of drops can ONLY be <=  the packets received (without
+	 * overlap between registers).
+	 */
 	uint64_t oerrors;   /**< Total number of failed transmitted packets. */
+	uint64_t ipkterrors;
+	/**< Total number of erroneous received packets. Where the number of
+	 * errors can be >= the packets received (without overlap between
+	 * registers), this is because there may be multiple errors associated with
+	 * a packet.
+	 */
 	uint64_t imcasts;
 	/**< Deprecated; Total number of multicast received packets. */
 	uint64_t rx_nombuf; /**< Total number of RX mbuf allocation failures. */
-- 
2.4.3

Re: [dpdk-dev] [PATCH v2 1/1] ethdev: distinguish between drop and error stats

[Thomas Monjalon]

2015-10-19 13:20, Maryam Tahhan:
> Make a distniction between dropped packets and error statistics to allow
> a higher level fault management entity to interact with DPDK and take
> appropriate measures when errors are detected. It will also provide
> valuable information for any applications that collects/extracts DPDK
> stats, such applications include Open vSwitch.
> After this patch the distinction is:
> ierrors = Total number of packets dropped by hardware (malformed
> packets, ...) Where the # of drops can ONLY be <=  the packets received
> (without overlap between registers).
> ipkterrors = Total number of erroneous received packets. Where the #
> of errors can be >= the packets received (without overlap between
> registers), this is because there may be multiple errors associated with
> a packet.
[...]
> -	uint64_t ierrors;   /**< Total number of erroneous received packets. */
> +	uint64_t ierrors;
> +	/**< Total number of packets dropped by hardware (malformed packets...)
> +	 * Where the # of drops can ONLY be <=  the packets received (without
> +	 * overlap between registers).
> +	 */
>  	uint64_t oerrors;   /**< Total number of failed transmitted packets. */
> +	uint64_t ipkterrors;
> +	/**< Total number of erroneous received packets. Where the number of
> +	 * errors can be >= the packets received (without overlap between
> +	 * registers), this is because there may be multiple errors associated with
> +	 * a packet.
> +	 */

There was not a lot of comments on this proposal.
If the idea is well received, it needs to be implemented in drivers, at least
few of them.

Re: [dpdk-dev] [PATCH v2 1/1] ethdev: distinguish between drop and error stats

[Tahhan, Maryam]

> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Monday, November 2, 2015 11:47 PM
> To: Tahhan, Maryam <maryam.tahhan@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/1] ethdev: distinguish between drop and
> error stats
> 
> 2015-10-19 13:20, Maryam Tahhan:
> > Make a distniction between dropped packets and error statistics to
> > allow a higher level fault management entity to interact with DPDK and
> > take appropriate measures when errors are detected. It will also
> > provide valuable information for any applications that
> > collects/extracts DPDK stats, such applications include Open vSwitch.
> > After this patch the distinction is:
> > ierrors = Total number of packets dropped by hardware (malformed
> > packets, ...) Where the # of drops can ONLY be <=  the packets
> > received (without overlap between registers).
> > ipkterrors = Total number of erroneous received packets. Where the #
> > of errors can be >= the packets received (without overlap between
> > registers), this is because there may be multiple errors associated
> > with a packet.
> [...]
> > -	uint64_t ierrors;   /**< Total number of erroneous received packets.
> */
> > +	uint64_t ierrors;
> > +	/**< Total number of packets dropped by hardware (malformed
> packets...)
> > +	 * Where the # of drops can ONLY be <=  the packets received
> (without
> > +	 * overlap between registers).
> > +	 */
> >  	uint64_t oerrors;   /**< Total number of failed transmitted packets. */
> > +	uint64_t ipkterrors;
> > +	/**< Total number of erroneous received packets. Where the
> number of
> > +	 * errors can be >= the packets received (without overlap between
> > +	 * registers), this is because there may be multiple errors associated
> with
> > +	 * a packet.
> > +	 */
> 
> There was not a lot of comments on this proposal.
> If the idea is well received, it needs to be implemented in drivers, at least few
> of them.

Hi Thomas
I was waiting to implement it across the drivers when I knew it was going to be merged to master. It shouldn't break anything that's currently using ethdev stats and should be relatively straight forward to implement for the drivers. Does it makes sense to add it into drivers now or wait for the next open DPDK window?

Thanks
Maryam 

Re: [dpdk-dev] [PATCH v2 1/1] ethdev: distinguish between drop and error stats

[Thomas Monjalon]

2015-11-03 13:14, Tahhan, Maryam:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > There was not a lot of comments on this proposal.
> > If the idea is well received, it needs to be implemented in drivers, at least few
> > of them.
> 
> Hi Thomas
> I was waiting to implement it across the drivers when I knew it was going to be merged to master. It shouldn't break anything that's currently using ethdev stats and should be relatively straight forward to implement for the drivers. Does it makes sense to add it into drivers now or wait for the next open DPDK window?

It's better to change API only when it is used by some drivers.
We can wait the release 2.3 to integrate it.

Re: [dpdk-dev] [PATCH v2 1/1] ethdev: distinguish between drop and error stats

[Tahhan, Maryam]

> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, November 3, 2015 1:56 PM
> To: Tahhan, Maryam <maryam.tahhan@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/1] ethdev: distinguish between drop and
> error stats
> 
> 2015-11-03 13:14, Tahhan, Maryam:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > There was not a lot of comments on this proposal.
> > > If the idea is well received, it needs to be implemented in drivers,
> > > at least few of them.
> >
> > Hi Thomas
> > I was waiting to implement it across the drivers when I knew it was going to
> be merged to master. It shouldn't break anything that's currently using ethdev
> stats and should be relatively straight forward to implement for the drivers.
> Does it makes sense to add it into drivers now or wait for the next open DPDK
> window?
> 
> It's better to change API only when it is used by some drivers.
> We can wait the release 2.3 to integrate it.

Ok, I will wait for 2.3 and integrate it with the drivers. Thanks.