From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 61E0DA0C41; Wed, 17 Nov 2021 13:00:35 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3548E41144; Wed, 17 Nov 2021 13:00:35 +0100 (CET) Received: from mail-il1-f169.google.com (mail-il1-f169.google.com [209.85.166.169]) by mails.dpdk.org (Postfix) with ESMTP id E7784407FF for ; Wed, 17 Nov 2021 13:00:32 +0100 (CET) Received: by mail-il1-f169.google.com with SMTP id e8so2450176ilu.9 for ; Wed, 17 Nov 2021 04:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JAvt7n9h4w0D6/Qcg5qOWKJN6SCHPfFttNDFZ6e5f04=; b=HaQsBCEQvVkAVYz2fE2tjsp0LftHH0dr5VGZxp2BgaJy4Ji9nGz8fNKMoiBpZNIM4K qAVWhgWPpQL/IFFyud5qVqrvsWePKG17Hn55zkmu/6Nll4a+/SOgG56fdM/RVOOqIv/V 4CVhhLArhWs0LPjZtUBLzYxX+3ZUKAiYVnPiq4jc9QEITgQarVFbALWY8TDdYljot0IP 5lQ1di7YxccUCpURupF+FdN0pyMBKgL3LF2HLdsbMoj2HSiBY7aInJbmX8I9bsUHAFd9 ckq50XYcRwp8oJqVHkRPoRLFsYDXa9STyfzA+S3uhMwEupjtxRX/xxg8mBDSzAVppaCX aOog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JAvt7n9h4w0D6/Qcg5qOWKJN6SCHPfFttNDFZ6e5f04=; b=6nvKiylKstz62sqdJoej2u1H9RsI8XJYh57k/nJofh23JmLQeMyKbBFKLVZELa0N2y veSxLpzHNFSSDdzZEywYzMtjTY3KlI9Upz4bVQTOXROhSmAH3Wjw8PNj8jaK37QJjKox R3uNxFUyqkPpR4s/FH+ai8OBkjopBEPreUDWGvZ805j8mm81Us/8kICnc04EzZnRobuI 4LACRBBCb7xGk7RjeGAcehcA3Zc1wFB5D2qXqlOhD+jHFuW1vFUD9INRM8cQBTHVwZcq UH3uSsrbyoDdMDGQlTyzee7CEr4uH4Zp/8digkJCC+Y5VbLl+XK5NhaOIc8E9adlraH9 V2hA== X-Gm-Message-State: AOAM530WK5FZ0/WTEcSl+9CX8khbgiQ2IJkO0F7KjliQCgc3WT2KwmNm YeSgzJrPN+oV3zjbeu/qahHYqJfiOrVN887dBy8= X-Google-Smtp-Source: ABdhPJxNpuIePmnzlxQf4U/M020kP5FGMn4tXTON47xrJtrTR7FRpdDo4uWP5anvmTHfn74R40SVI3kylkMFRdEyIxI= X-Received: by 2002:a05:6e02:1bcb:: with SMTP id x11mr9083071ilv.94.1637150432254; Wed, 17 Nov 2021 04:00:32 -0800 (PST) MIME-Version: 1.0 References: <20210820082401.3778736-1-jerinj@marvell.com> In-Reply-To: From: Jerin Jacob Date: Wed, 17 Nov 2021 17:30:06 +0530 Message-ID: Subject: Re: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table features To: "Dumitrescu, Cristian" Cc: "jerinj@marvell.com" , Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko , "dev@dpdk.org" , "arybchenko@solarflare.com" , "lizh@nvidia.com" , "ajit.khaparde@broadcom.com" , "Singh, Jasvinder" , "matan@nvidia.com" , "ndabilpuram@marvell.com" , "skori@marvell.com" , "rkudurumalla@marvell.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Mon, Oct 11, 2021 at 8:53 PM Dumitrescu, Cristian wrote: > > Hi Jerin, Hi Cristian, > > > -----Original Message----- > > From: jerinj@marvell.com > > Sent: Friday, August 20, 2021 9:24 AM > > To: Dumitrescu, Cristian ; Thomas Monjal= on > > ; Yigit, Ferruh ; Andrew > > Rybchenko > > Cc: dev@dpdk.org; arybchenko@solarflare.com; lizh@nvidia.com; > > ajit.khaparde@broadcom.com; Singh, Jasvinder > > ; matan@nvidia.com; > > ndabilpuram@marvell.com; skori@marvell.com; rkudurumalla@marvell.com; > > Jerin Jacob > > Subject: [dpdk-dev] [RFC PATCH] ethdev: mtr: enhance input color table > > features > > > > From: Jerin Jacob > > > > Currently, meter object supports only DSCP based on input color table, > > The patch enhance that to support VLAN based input color table, > > color table based on inner field for the tunnel use case, and support > > for fallback color per meter if packet based on a different field. > > > > All of the above features are exposed through capability and added > > additional capability to specify the implementation supports > > more than one input color table per ethdev port. > > > > Signed-off-by: Jerin Jacob > > 2.33.0 > > Allowing the configuration of the packet input color based on multiple pr= otocols as opposed to just IP DSCP field makes sense to me. > Apologies for the delay in response. This was missed the 21.11 timeframe so I don't bother replying. Reviving back. > A few questions/suggestions: > > 1. How do we decide which field/protocol takes precedence to define the p= acket input color? You are enabling 2 possible options so far, i.e. VLAN ta= g PCP field and IP DSCP field, which one is to be set for the current meter= object? Using the capabilities to decide is confusing, as a specific mete= r object might be able to support multiple or even all the possible options= (e.g. the meter object is fine with either IP DSCP or VLAN PCP). Therefore= , we need a clear mechanism to unequivocally pick one; I think the user mu= st explicitly define which input color methodology is to be used by explici= tly setting a field (to be added) in the meter object parameter structure. Currently, in our HW, Each meter object needs to tell which pre-color scheme it is going to use(IP DSCP or VLAN PCP). This is OK in the overall scheme of things as the meter object is connected to rte_flow. So, rte_flow pattern can decide the steering to meter. Having said that, it is possible to have array for input color as you suggested. If choose that, path, We need to add capability tell implementation supports only one input color per meter object. Let me know if this is OK. > > 2. What if the defined input color methodology is not applicable to the c= urrent input packet? For example, the user selects VLAN PCP, but some or al= l of the input packets do not contain any VLAN labels? it picks the rte_mtr_params::fallback_input_color > > 3. How do we manage the many packet fields that could be used as the key = for the input color: outer IP DSCP, inner IP DSCP, VLAN 1st label, VLAN 2nd= label, MPLS QoS, etc? > - Approach A: Use an enumeration, like you propose, and we can add more i= n the future. Not ideal. > - Approach B: Point to a protocol-agnostic packet field by defining the o= ffset and mask of a 64-bit field. Advantage: we don't need to change the AP= I every time we add a new option. No strong opinion on doing Approach B. I think, it may be overkill for application and implementation to express. No strong opinion, If you have a strong opinion on that, I will change that to v1. Let me know. > > 4. I suggest we use a unified input color table as opposed to one per pro= tocol, i.e. rename the struct rte_mtr_params::dscp_table to color_in_table.= The size of this table could be implicitly defined by the packet field typ= e (in case of enum) or the field mask (in case of protocol-agnostic field o= ffset and mask), as described above. Will do that. I thought not to do that just because, I don't want to remove the existing dscp_table symbol. Make sense to enable your suggestion. Let me know your views on Questions 1 and 3. I will send the next version based on that. > > Regards, > Cristian