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 0AFDAA034F; Wed, 31 Mar 2021 12:23:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 88DBD140E50; Wed, 31 Mar 2021 12:23:11 +0200 (CEST) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by mails.dpdk.org (Postfix) with ESMTP id 2A66E406A3 for ; Wed, 31 Mar 2021 12:23:10 +0200 (CEST) Received: by mail-io1-f44.google.com with SMTP id x17so19567493iog.2 for ; Wed, 31 Mar 2021 03:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jCVxQdehjWRRa5jB9/Rb3+xONAK+bvcIeFgTQ9h55sU=; b=Q+lGSseHsqI7WNzFXnAcGWHF/BEcCp/2hz3ba88ek8EAnfpvdmcwsg1oc3XbO1c2pn UsiNMm+G1a3tJhs/9JqV9KOSZfOvld3nKwJQ2JfgM70pj8w4Q2GstP+vpZevv2Aerkan kduaRMzRIxKAvBjhX2sytzmQYKZehzNgPlV+E4r/X7dK29Muxt5BIiH/Ytsvo9ctdH0u m0HWauQL9/MUcPdMN1jF7433mKIxuO7HzFjk59/d1kp16nE3Tzi7U8PHTN/NcD4VZCSX J0ox3T0C0bwuZYm4xCCepjF+ULdM/qhsLMXJRhHkbcWPP37ptzYjOIJ/2pgjOoNgMZ4M ldLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jCVxQdehjWRRa5jB9/Rb3+xONAK+bvcIeFgTQ9h55sU=; b=JhtTMdMGR80gxx9RSgVhw6cD+wdlpc2tbK8tlO1+0c5Ayb1vihMgECRh8Urs4CCyVW hRF9EUB5FuSlVZBQtfGjgFTDzGn6wtZtC00xVLPx+2E9EDv4VkmPYR/1SVV4dK7KbWlg DzFq1Uem5ixm8wdB3TIncIUl9gEMHBcPO1ZxLSqjNeTAy2fhKNtiqvlvkOlqu6tMhnUZ pHL+VIWb1auqqpY3Ia/TBwiCGKISZ+3fGzhTRTS0ekre2N/zhLgbanV5b/1V9oefKfQ5 jHnvF8Ro4IdHQQTOdcaX4Ii1Xc9BRAYtW8iu2LSxPQFPwVH22RElzMsx4vkIP+UlyJUM WVqg== X-Gm-Message-State: AOAM532efP1gy1Ifb6RBf2/j8EP4fbtwPfYgD+NeXZ3CRlf7RNF44NIM I2iQTkKfxg0VfTR2oLJVlPADiUpo6qA5CjqFnAo= X-Google-Smtp-Source: ABdhPJxtzBihagoVW/0T0DnfXbpxLorDxhueNjw5Unu9DdG8ORKxT+7S1oqWib40cwbpCMfqAm9Zllg/AoYa0VoFCEQ= X-Received: by 2002:a05:6638:381c:: with SMTP id i28mr2291542jav.60.1617186189559; Wed, 31 Mar 2021 03:23:09 -0700 (PDT) MIME-Version: 1.0 References: <20210318085815.804896-1-lizh@nvidia.com> <20210318085815.804896-2-lizh@nvidia.com> In-Reply-To: From: Jerin Jacob Date: Wed, 31 Mar 2021 15:52:53 +0530 Message-ID: To: Matan Azrad Cc: "Dumitrescu, Cristian" , Li Zhang , Dekel Peled , Ori Kam , Slava Ovsiienko , Shahaf Shuler , "lironh@marvell.com" , "Singh, Jasvinder" , NBU-Contact-Thomas Monjalon , "Yigit, Ferruh" , Andrew Rybchenko , Hemant Agrawal , Ajit Khaparde , "Richardson, Bruce" , "Doherty, Declan" , "dev@dpdk.org" , Raslan Darawsheh , Roni Bar Yanai Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 2/2] [RFC]: ethdev: manage meter API object handles by the drivers 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 Sender: "dev" On Tue, Mar 30, 2021 at 1:40 AM Matan Azrad wrote: > > Hi Jerin Hi Matan > > Thanks for the review. > PSB > > From: Jerin Jacob > > On Thu, Mar 25, 2021 at 1:51 PM Matan Azrad wrote: > > > > > > Hi Cristian > > > > > > From: Dumitrescu, Cristian > > > > Hi Li and Matan, > > > > > > > > > -----Original Message----- > > > > > From: Li Zhang > > > > > Sent: Thursday, March 18, 2021 8:58 AM > > > > > To: dekelp@nvidia.com; orika@nvidia.com; viacheslavo@nvidia.com; > > > > > matan@nvidia.com; shahafs@nvidia.com; lironh@marvell.com; Singh, > > > > > Jasvinder ; Thomas Monjalon > > > > > ; Yigit, Ferruh ; > > > > > Andrew Rybchenko ; Dumitrescu, > > > > > Cristian > > > > > Cc: dev@dpdk.org; rasland@nvidia.com; roniba@nvidia.com > > > > > Subject: [PATCH 2/2] [RFC]: ethdev: manage meter API object > > > > > handles by the drivers > > > > > > > > > > > > > Yes, it changes all API, but very small part in each, will be very easy to align > > all the current dpdk components to use this concept. > > > > > > > If you guys insist with this proposal, I would like to get more > > > > opinions from other vendors and contributors from within our DPDK > > community. > > > > > > > > > Yes, more opinions are very welcomed. > > > > This point was discussed to the core in the initial meter RFC. > > > > IMO, IDs helps in managing meter objects more clean way with lookup cost. > > Although it is not the main topic here I ask: > What is the difference between pointer to ID for the cost topic? Both are unique IDs actually.... Once is defined by app and another one by implemention. > > > especially, If a non DPDK application, managing the meter ID via some sort of > > IPC. > > > > Considering existing APIs and drivers are implemented with ID scheme, I think, > > it would be better to give some performance data for changing the scheme. > > > > I was under impression that, Typical number of MAX meter HW objects could > > be around 16k something and the number of meter objects created and > > destroyed per second will be very low. (In the order to 16k ops per second) > > Could you share the practical number of meter HW objects in MLX SoCs and > > the number of operations are you are envisioning? > > We are talking about 4M HW meters in the next version of mlx5 driver. > The rate of flows(with meter action) creation\deletion can arrive to 200K-300K per second and we are working hard to improve it more. > > Can you please give also your opinion about the owner of the ID\pointer? Just to clarify, When you have 4M HW meters, At least, you have will 4M registers or 4M context memory kind of an interface between HW<->SW set/get meter-specific objects. Or Is it some kind of emulation over SW? If it 4M HW meters then ID scheme makes sense. > The main goal of this patch is to move the owner from the application to the driver.... > > > > > > > > > > > Thanks