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

[Mattias Rönnblom]

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