From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 9CBCC1B8FE for ; Mon, 17 Dec 2018 20:37:00 +0100 (CET) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 1A22740025 for ; Mon, 17 Dec 2018 20:37:00 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 087C04000A; Mon, 17 Dec 2018 20:36:59 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.1 X-Spam-Score: -0.9 Received: from [192.168.1.59] (host-90-232-140-56.mobileonline.telia.com [90.232.140.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 9DE3D40002; Mon, 17 Dec 2018 20:36:57 +0100 (CET) To: "Dumitrescu, Cristian" , "Ananyev, Konstantin" , "Pattan, Reshma" , "dev@dpdk.org" , "jerin.jacob@caviumnetworks.com" , "Singh, Jasvinder" References: <20181123165423.134922-1-jasvinder.singh@intel.com> <1544193116-7058-2-git-send-email-reshma.pattan@intel.com> <2601191342CEEE43887BDE71AB977258010D8BA5F8@IRSMSX106.ger.corp.intel.com> <128d5503-af19-c9bb-d59c-43b71471f9c4@ericsson.com> <3EB4FA525960D640B5BDFFD6A3D891268E815AFE@IRSMSX108.ger.corp.intel.com> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: Date: Mon, 17 Dec 2018 20:36:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891268E815AFE@IRSMSX108.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [dpdk-dev] [PATCH v2 2/3] eal: add new rte color definition X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 19:37:01 -0000 On 2018-12-17 10:41, Dumitrescu, Cristian wrote: > > >> -----Original Message----- >> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com] >> Sent: Saturday, December 15, 2018 2:16 PM >> To: Ananyev, Konstantin ; Pattan, Reshma >> ; dev@dpdk.org; Dumitrescu, Cristian >> ; jerin.jacob@caviumnetworks.com; Singh, >> Jasvinder >> 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.