Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

> -----Original Message-----
> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com]
> Sent: Saturday, December 15, 2018 2:16 PM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Pattan, Reshma
> <reshma.pattan@intel.com>; dev@dpdk.org; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; jerin.jacob@caviumnetworks.com; Singh,
> Jasvinder <jasvinder.singh@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.

Regards,
Cristian