On 12/17/2018 7:36 PM, Mattias Rönnblom wrote: > 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.
This is hilarious :), although I am a bit disappointed to not have RTE_COLOR_VERY_VERY_DARK_GREY
