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 3A102A0509; Tue, 5 Apr 2022 10:59:08 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1A6F940F35; Tue, 5 Apr 2022 10:59:07 +0200 (CEST) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) by mails.dpdk.org (Postfix) with ESMTP id 2AF8940685; Tue, 5 Apr 2022 10:59:05 +0200 (CEST) Received: by mail-io1-f54.google.com with SMTP id k25so14342515iok.8; Tue, 05 Apr 2022 01:59:05 -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=cAv30OZsTohF3deuMRrqflLXEc7twlTndnwnx3GBC8w=; b=F/PkY90f/WeYZ7FPDM3blhkp/ggNqHzsTaUOuDr0HaFV5Itsy5zfXfDQlTYBoHXgb8 q3ZlMpPmxdF3WTSUupKazFEcs2r/gxvDu4gclisX3VyZQgwitARiU/0/mFHsrDgCHu9B i7IvwIgJtKxt0400153c1ztFBlat0oVw6nOaGxgtiM5GDJjRNpbxNLZi0+FK0KgDX9Z2 Nqn7simEM26hYmDCz6l124emd+aHF6zUgp72CXGWgg4zKioNXRJVgW8fAisetQUSnezj +7DLDWGZY5kUolYlZQW1glxvXt8vGSBhwq8bJuhuDvDpZNqIeUUWYlJlWhPrSoxZbHDt AaFw== 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=cAv30OZsTohF3deuMRrqflLXEc7twlTndnwnx3GBC8w=; b=ctCHiAEEQUT38itlvOXS6M7c1cGmAfrj7rwwT+kv3Eo0xn6fRqAWC2745H9mopysfB tl5Uhh7eRlTdycX+laWoQjGeHvh7hdX6W3fksKzO3fiVzezWs9BoYiA5DDU/Lenzwodl ywn+WPr4BpyfN/mIJOfnau3xZwgB/nUc8F/3mhbce4FiAYV62OrcMOiJ6qUPIQRah7sZ 1fBbgCnAJjjY0DE3AEx44IajQ5MlGmDfjd9TSfPO7hkkuH7zgMYZFOho0pQZHgyuAkJz pV+X2cZnPe/tC7DDvtPF2IwZwNLDXEmlpRMPaJ8AJHbmkg4yoUaO/2+YfpjTivskvCpQ XU/w== X-Gm-Message-State: AOAM531oSrG31GNzXnpdxEhS1RhONPwDAOBBCU4VgxvwS6oJcEU1HJTB so1hdhH/kneFzIBV/bgcRCpV3fRhRE6y2lP4jiE= X-Google-Smtp-Source: ABdhPJwy12oF01spziirPl9T9FqZIgxhAbS4+vGJPevdI8iYzBgwZdpgVObXsN/i4omN/eXY+wHm/VByzmP+aA20AOE= X-Received: by 2002:a05:6602:2cca:b0:646:3d03:a6da with SMTP id j10-20020a0566022cca00b006463d03a6damr1171914iow.121.1649149144518; Tue, 05 Apr 2022 01:59:04 -0700 (PDT) MIME-Version: 1.0 References: <20220401032232.1267376-1-spiked@nvidia.com> In-Reply-To: <20220401032232.1267376-1-spiked@nvidia.com> From: Jerin Jacob Date: Tue, 5 Apr 2022 14:28:38 +0530 Message-ID: Subject: Re: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper To: Spike Du , Andrew Rybchenko , Cristian Dumitrescu , Ferruh Yigit , techboard@dpdk.org Cc: Matan Azrad , Viacheslav Ovsiienko , Ori Kam , Thomas Monjalon , dpdk-dev , Raslan Darawsheh 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 Fri, Apr 1, 2022 at 8:53 AM Spike Du wrote: > > LWM(limit watermark) is per RX queue attribute, when RX queue fullness reach > the LWM limit, HW sends an event to dpdk application. > Host shaper can configure shaper rate and lwm-triggered for a host port. > The shaper limits the rate of traffic from host port to wire port. > If lwm-triggered is enabled, a 100Mbps shaper is enabled automatically > when one of the host port's Rx queues receives LWM event. > > These two features can combine to control traffic from host port to wire port. > The work flow is configure LWM to RX queue and enable lwm-triggered flag in > host shaper, after receiving LWM event, delay a while until RX queue is empty > , then disable the shaper. We recycle this work flow to reduce RX queue drops. > > Spike Du (6): > net/mlx5: add LWM support for Rxq > common/mlx5: share interrupt management > net/mlx5: add LWM event handling support > net/mlx5: add private API to configure Rxq LWM > net/mlx5: add private API to config host port shaper > app/testpmd: add LWM and Host Shaper command + @Andrew Rybchenko @Ferruh Yigit cristian.dumitrescu@intel.com I think, case one, can be easily abstracted via adding new rte_eth_event_type event and case two can be abstracted via the existing Rx meter framework in ethdev. Also, Updating generic testpmd to support PMD specific API should be avoided, I know there is existing stuff in testpmd, I think, we should have the policy to add PMD specific commands to testpmd. There are around 56PMDs in ethdev now, If PMDs try to add PMD specific API in testpmd it will be bloated or at minimum, it should a separate file in testpmd if we choose to take that path. + @techboard@dpdk.org