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 B03B9A0A0F; Sat, 27 Mar 2021 14:15:24 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 42E3640692; Sat, 27 Mar 2021 14:15:24 +0100 (CET) Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by mails.dpdk.org (Postfix) with ESMTP id 5DF4A40686 for ; Sat, 27 Mar 2021 14:15:23 +0100 (CET) Received: by mail-io1-f49.google.com with SMTP id k25so8216611iob.6 for ; Sat, 27 Mar 2021 06:15:23 -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=j3oxwXGr/+h2ZblKcC9QoyIlu/GJQ1TZ6kvtnuWopfI=; b=Mr70Cmg9Z/abH2ymD0Ab+VUR9AHGWVqq1GQ4S0KAyKlIGSdZ8KDUGLt0YGzUydoWnl KeObgFNfPXegcdYrcqJyqtSlA/BQYsV+ctQ5n/7UfjBX66hMrrxySbEs7SL62T4rI+Nn j8oQ1SbqKHbOyPClbQy2FFAigL+jSPM/b3FebLuGhlby3DLrqnP0kqAZp4RuP5ps0gJC XQ8fa3hAvUWmBFeiJggVGbqu1G9280lna2rEnO2r5qVQIeggDobv6YulTc85zj6JNDQX Qeq5vrbR5xUn/Cl1XfglZcbKGiWcIzs47SmmSJBtCx3FaO9XsM4S/fFngR5cSSk/H7iu qmqw== 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=j3oxwXGr/+h2ZblKcC9QoyIlu/GJQ1TZ6kvtnuWopfI=; b=iWgHtyFoOZ3xmV4Jrd9Vdg+SlJd2ix8YYkDk5ALNCdFXPYQM2beZb5I2Nm4T77sdZo cj3+FrKt+ZdagRpJSPskVZVcGQm2BGDUdSvQhXDmNaTecvsx8sejrxaKzf921ZQj2gBv 1OmCH66by3PDDbaZhGlJ4WZcaOxxtYpF97A6MwOotbDBggz+MwgLBm9oaf607Iuot1B5 tbaIOipNxXWUorjc4ok/YJf+i6ahz9wHZicPjd0u+4pNl+ahN5i9sW270jVJmmniD64d 76Q5iF3NkTc9PVqSoVV1vaSF+VZcCisfbk7jv7Nhj5kARybKZEynJmzoJFIHM0dNktJa YHqg== X-Gm-Message-State: AOAM533n+6aFXnguKCzZDzR/I5aXn80nPcpjcpLFNMT7HICMt5FRiFa7 DgRbanmdvj8w3VXNxtdOV5FhdWzZF7Ts5woyr8g= X-Google-Smtp-Source: ABdhPJzw1tSDJqx/achW4R64aEX6tNi20YimGVphJJ3rH5wAFBhj4jWc1ipl0t3H386kv1pys9n1BGcGuQY+6vojzAc= X-Received: by 2002:a05:6602:2d95:: with SMTP id k21mr13942746iow.123.1616850922584; Sat, 27 Mar 2021 06:15:22 -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: Sat, 27 Mar 2021 18:45:06 +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 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. 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? > > Thanks