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 9DF0FA0503; Thu, 19 May 2022 15:56:16 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4240440222; Thu, 19 May 2022 15:56:16 +0200 (CEST) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by mails.dpdk.org (Postfix) with ESMTP id 6D51040156 for ; Thu, 19 May 2022 15:56:15 +0200 (CEST) Received: by mail-io1-f49.google.com with SMTP id e194so5799403iof.11 for ; Thu, 19 May 2022 06:56:15 -0700 (PDT) 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; bh=Ffz6XpyHdZjnNKY4MAId1Y9lfAIT2gWX8uQ2xc071/o=; b=AkgmFwDmU0axywPPReiJOrzV9IJjuLhoIUPladxfiZyjw6Z1k9ha3ON7vOSgQ/RM0i /LgtyIcdWERcz428DW5GUhtyKbYgFSE7BvtCpEtVplegqybP/c/EC8fLVrsmy+seGJeU 3nEzR+7ysIO+wwJmjjZcJsP6IU2Ptr0MNfF5PNI6TRvZ71q8wxK1SXCmGfWMBuSNlG3i SB2/WAx0EBp0oczoPWZpnOCQwtmAWCsV4T7dFPA5pUZxH6RrYUsnHTOu1jeZD8uOuQVw MTEisg5sa2yKKmEQy9cJFH/G/2B8qy/OkmO/EKqgoiL6odLe5zY37Z0AKVefLVrDL6lc 4LAQ== 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; bh=Ffz6XpyHdZjnNKY4MAId1Y9lfAIT2gWX8uQ2xc071/o=; b=Es8B8ySABgNYj3qs98LEggs4P4FRt56p8x70Nh/wH5/1vCJ/pDPfTwGSlTyhe0JADZ ZrZmGyivnWm30TtDKeq6xHnkzBQcMrDhPTuAEbXpBpH9A9jeFiZqVVaKagMMs4WwUM9k fmL5blz7ntCH7NKg/4lnp5F7Rk+FUYU+1Ryt3/wwz9j4EGb/W68eIbjhHCfqF0ss1myo gneXbKSyBMcKE03HQBi2G0TZFm+MPknB6fG+0l9zmqQKUxdj/zIU/dcfzIqZMeedpwMg dhN4VydUzb8qNPJgmO/eHdE9bbXEW1sjGzESrWpIKwznRIPInTd9bFHUyxl3NKW9viUB fBKA== X-Gm-Message-State: AOAM531E7Hz2fIqEwY0dR+xaqzrF+DwyKooz9ps5g/kaqsznshLXGXLa 8puModEEaIzbBzfbWKawKuaeKAvTxC4V316IpKk= X-Google-Smtp-Source: ABdhPJwpQXWEgezLDhFwAkx13UKHmWGLahusG2iNwE5n5NSVVJ9EQoq79oNq4jN+nhmFwU2QSOiIXOmMDkwNMrnF0Jg= X-Received: by 2002:a05:6638:468e:b0:32b:fe24:906a with SMTP id bq14-20020a056638468e00b0032bfe24906amr2742952jab.123.1652968574777; Thu, 19 May 2022 06:56:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jerin Jacob Date: Thu, 19 May 2022 19:25:48 +0530 Message-ID: Subject: Re: [RFC] ethdev: datapath-focused meter actions, continue To: Alexander Kozyrev Cc: Ori Kam , Jerin Jacob , Cristian Dumitrescu , "NBU-Contact-Thomas Monjalon (EXTERNAL)" , Andrew Rybchenko , "Vipin.Varghese@amd.com" , Ajit Khaparde , Ferruh Yigit , Ray Kinsella , Sunil Kumar Kori , Ivan Malov , "Awal, Mohammad Abdul" , "Zhang, Qi Z" , "Richardson, Bruce" , Konstantin Ananyev , "Singh, Jasvinder" , "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" 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, May 16, 2022 at 11:45 PM Alexander Kozyrev wrote: > > Agenda: continue discussion about proposed improvements to Flow API in regards to Meter handling (slides attached). I think, primary difference between the old and new methods are where the meter HW objects are available. In the old method, it is more in NIC HW and in the new method it is more in flow processor HW. Also, I think, new method is more aligned with p4 (https://p4.org/p4-spec/docs/PSA.html#sec-meter) where things are done using a flow processor kind of HW. Emulating each approach is costly. So I don't see any harm in keeping a new method(without removing the old method) for a specific set of HWs that has such features. But looking at the API specification it is not easy to understand how to enable this example use case as it is complicated. Could you share pseudo code from application perspective for the following use case. 1) Meter0 has profile of srtcm_rfc2697 of RFC 2697 with packet based metering 2) Meter1 has profile of trtcm_rfc2698 of RFC 2698 with byte based metering 3) Meter2 has profile of trtcm_rfc4115 of RFC 4115 with packet based metering 4)If VLAN ID is X then do Meter1 , - if output color is RED then drop the packet - if output color is YELLOW then do Meter0 --If the out color for Meter 0 is not RED then forward to Queue 0 else drop the packet. 5)If VLAN ID is Y then do Meter2 and define the input color from VLAN PCP field(000-means Green, Remaining means Yellow) --If the output color is Green and packet is IPV4 and forward the packet Queue 0 --If the output color is Green and packet is IPV6 and forward the packet Queue 1 - If the output color is not Green then drop the packet. Listed above use case to just test API specification to be sure that we have not missed anything so that new approach we can address all metering requirements. Thanks, Jerin.