On 2018-12-17 10:41, Dumitrescu, Cristian wrote:
-----Original Message-----
From: Mattias Rönnblom [mailto:mattias.ronnb...@ericsson.com]
Sent: Saturday, December 15, 2018 2:16 PM
To: Ananyev, Konstantin <konstantin.anan...@intel.com>; Pattan, Reshma
<reshma.pat...@intel.com>; dev@dpdk.org; Dumitrescu, Cristian
<cristian.dumitre...@intel.com>; jerin.ja...@caviumnetworks.com; Singh,
Jasvinder <jasvinder.si...@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition
On 2018-12-15 00:35, Ananyev, Konstantin wrote:
Hi Reshma,
diff --git a/lib/librte_eal/common/include/rte_color.h
b/lib/librte_eal/common/include/rte_color.h
new file mode 100644
index 000000000..f4387071b
--- /dev/null
+++ b/lib/librte_eal/common/include/rte_color.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2018 Intel Corporation
+ */
+
+#ifndef _RTE_COLOR_H_
+#define _RTE_COLOR_H_
+
+/**
+ * Color
+ */
+enum rte_color {
+ RTE_COLOR_GREEN = 0, /**< Green */
+ RTE_COLOR_YELLOW, /**< Yellow */
+ RTE_COLOR_RED, /**< Red */
+ RTE_COLORS /**< Number of colors */
+};
Does it really belong to EAL?
Konstantin
If this is supposed to be a generic type, we definitely need
RTE_COLOR_BLACK as well, or RTE_COLOR_VERY_VERY_DARK_GREY.
/Batman
Hi Mattias,
The packet color values of (green, yellow, red) are not my invention, they are
part of the IETF DiffServ foundation and standardized by a long list of RFCs,
with just a few of them listed below:
RFC 2697 - srTCM
RFC 2698 - trTCM
RFC 4115 - trTCM
RFC 2597 - Assured Forwarding
It is also easy to check in the documentation from Cisco, Juniper and other
router vendors that the packet color values used for traffic metering and
policing are always (green, yellow, red).
So, bottom line:
1. This is a formal as well as a de facto standard, to me it makes no
sense for DPDK to do it differently. Why not align to the formal and de facto
industry standards?
2. DPDK already recognized this in a number of its APIs, such as:
rte_meter, ethdev rte_mtr, ethdev rte_tm, rte_sched. This patch is simply a
cosmetic consolidation of the packet color definition for easier integration of
all these API, it does not propose any API change. If you want to change any of
these APIs, please describe the motivation and send a separate patch for review.
It was a joke. Also, I'm not actually Batman. Sorry for the confusion.
