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 68D85A034F; Tue, 7 Dec 2021 10:55:41 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 01C2941152; Tue, 7 Dec 2021 10:55:41 +0100 (CET) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) by mails.dpdk.org (Postfix) with ESMTP id 3C3984114F for ; Tue, 7 Dec 2021 10:55:39 +0100 (CET) Received: by mail-il1-f172.google.com with SMTP id j21so13194016ila.5 for ; Tue, 07 Dec 2021 01:55:39 -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=hEvxGkyMJjnTlQBaV23kiAaOxTEPrGKCmyiWNncf3WE=; b=AfHpKS/6vzyGRp0GqjsTWVJaFduj4VnGnft6IHxmaCgksmubfcEeeGzMXt0wu+9zz7 /MRuqKhUxZdTLEfVKH/o/NZQQbr0OWmiD91u7JhbYrR0yKytmRNBrqP+UZBBJkr0ivpp vy0MxWKRWYtnLkqm2B5JZtQSRdSOB0zJr9oSR05az4I4GdJtN9MArb8dtdhUVeRqytjO NqAnYBWTcvwhYiZdKH7vi7E6VemOhJ2FI6P/2wKZpNHEy8gNc+WmHwBx9tz+6WbRPKrR juMssJhkWiaCVfjJBEJzjLnA664I/JnV7I+3s5ZPEVLWGfO1j2mUWffpIn0hqNArgZK/ Nc3A== 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=hEvxGkyMJjnTlQBaV23kiAaOxTEPrGKCmyiWNncf3WE=; b=eFHCFzfuX7KfUBrkDoSg5Yh8f5AhXdIWR4SM6IO01gZSSaYjNnZ38SwQFz2L+HQcNm sD4KCX09tIL7mK+DPcAz0o5D/XSq0AKYhYAYab98wdA7TtXTnFQOUQHhPZHCMv2K+tsK ZnY6UcEqskqPgnx2TOP39QxK2qvCWARNtjz0FCgX0VHPrwl7mXKtXvr5tlMPlsog5YKv MIq83aCnnEkaWaL9AD/gfFjo/0lCGwEEl79qGq5g3j8CZ0cFmGgnOQC5yvE8+PI2Ngy1 qCmnnIIiNIcf5iTySWdhWpsrDh3/0S5QaD1qh/pmgIzqajWkTLQtFhRSuVMjIhMVOwRZ nQhw== X-Gm-Message-State: AOAM531R05YkHN7cTf2g6F98kiyh/RtP4wmAddHl4Vs56Qb/WOZG1ZfI DnooU00xcdNbVYDqwC1wLulp6Q1FRsbYO8hQWT0= X-Google-Smtp-Source: ABdhPJzoOMxWMZsDYfgcJRtJEOl6hPRMmdLQH8atbZ9/R7onyWS4yUTsGYLG+O2pkXKiyNmYaMJpFeB1SivVUHC2bUo= X-Received: by 2002:a05:6e02:1b01:: with SMTP id i1mr33916565ilv.94.1638870938529; Tue, 07 Dec 2021 01:55:38 -0800 (PST) MIME-Version: 1.0 References: <20210820082401.3778736-1-jerinj@marvell.com> In-Reply-To: From: Jerin Jacob Date: Tue, 7 Dec 2021 15:25:12 +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 Wed, Nov 17, 2021 at 5:30 PM Jerin Jacob wrote: > > On Mon, Oct 11, 2021 at 8:53 PM Dumitrescu, Cristian > wrote: > > > > Hi Jerin, > Hi Cristian, Could you share your feedback so that I can send the v1? > > > > > > > -----Original Message----- > > > From: jerinj@marvell.com > > > Sent: Friday, August 20, 2021 9:24 AM > > > To: Dumitrescu, Cristian ; Thomas Monj= alon > > > ; 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 tabl= e > > > 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 suppor= t > > > 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 = protocols 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= packet input color? You are enabling 2 possible options so far, i.e. VLAN = tag PCP field and IP DSCP field, which one is to be set for the current met= er object? Using the capabilities to decide is confusing, as a specific me= ter object might be able to support multiple or even all the possible optio= ns (e.g. the meter object is fine with either IP DSCP or VLAN PCP). Therefo= re, we need a clear mechanism to unequivocally pick one; I think the user = must explicitly define which input color methodology is to be used by expli= citly 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= current input packet? For example, the user selects VLAN PCP, but some or = all 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 ke= y for the input color: outer IP DSCP, inner IP DSCP, VLAN 1st label, VLAN 2= nd label, MPLS QoS, etc? > > - Approach A: Use an enumeration, like you propose, and we can add more= in the future. Not ideal. > > - Approach B: Point to a protocol-agnostic packet field by defining the= offset and mask of a 64-bit field. Advantage: we don't need to change the = API 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 p= rotocol, i.e. rename the struct rte_mtr_params::dscp_table to color_in_tabl= e. The size of this table could be implicitly defined by the packet field t= ype (in case of enum) or the field mask (in case of protocol-agnostic field= offset 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