Message ID | 20220401032232.1267376-1-spiked@nvidia.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 075FEA0503; Fri, 1 Apr 2022 05:22:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A374F4067E; Fri, 1 Apr 2022 05:22:58 +0200 (CEST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2045.outbound.protection.outlook.com [40.107.220.45]) by mails.dpdk.org (Postfix) with ESMTP id 33C494014F for <dev@dpdk.org>; Fri, 1 Apr 2022 05:22:57 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UrIeiqZ8ABvtJZGqGlrM9HoEhb24ENUpZUNT4iHx4yxwWHNLBEqL8Wa2pdXDvFjzKuHKQaAlkJ20c5Ksa0PulCbrOocdnpXKXB9HnGLLrjPFC/34tD2EglBFhuJ9bGSLqxtVXYvyn0+btBiR/aVRgBOJNuaOaaTEFTlJzAzu8bYNTWKGLhvV3tVa7KLvH8RAAld2KYmVs30wtHl1cV2HJCVi8PDNz3uHehhAn2p0eEuYSIf+nCI5gPBi7/SbPdGQSnziFaOq3oZjjaLlUaA47sptik+HDdNPudI1jYdSN7Al3b0y4zaBf7EQTjiUKzlr4tF2gKlYgfS6/mJoR1Ni0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=W2oURiV1rdH+Vi5rAcvqseK1NeY6TD0Z45nCSMW3eZ8=; b=FKA21imSvrjShIGmnlQ59y3NQS4oqSMBGIYp/83IGgXvvIFagL5CKIi4k3SZA8LVSpUCCC60RGSqqHpBt4cOiHuFMnzaHRDiCQtTR26vf/QcVnrowsby4Vv/UzxWF/RxSvohydWMr3dwhF6okf3erZaEJM/r6Zq+dBE6117rgCsap5Pgr7oJPVzG1nJq+mcpBUJPzXmbjlOZt8w0k71XWOGVIyWIMh+DF0QysEFMcUwzrrGjmAEjMnI3iBJLkKH9j2hrxNDZRRWY1lay75/xYerKT+Khr0otgv6GxDWl941oqR8p9A3ktAIjsTSw7cMe7tpDI/fPiWASXr5q2xw5Gw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 12.22.5.235) smtp.rcpttodomain=dpdk.org smtp.mailfrom=nvidia.com; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nvidia.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W2oURiV1rdH+Vi5rAcvqseK1NeY6TD0Z45nCSMW3eZ8=; b=SBObLpFjYYf17Qvas1VbByV0WXeH2M5G9fK/l8B9RpbOiEcYusa21URB31W+CIndDoGZgBIGD0tIj1thcLF2ZuvMEaYrmnxMM7SQC5EaHz3XpH/Xtl9HLAPdpH+5+uYltnKw1M5EE+cvgdo/kUk3KRLRt2wap5YABAfQ2NxNtuMtPISFkEuUWSdYnd0ecN87ruJp/oYspnCHfUFwacQFIUEY0BFQbkMCwcdgWNz0/P5InFF0tMPfuz3VNPTac54CzHpUokC9mlhTanjgwSigwUxrogu9r9tJXSqY1hddrZeSxXLYo10ulFjSKnzy2p/utBQkCRamBG/Bjn9RuUnKfg== Received: from MW2PR16CA0018.namprd16.prod.outlook.com (2603:10b6:907::31) by BN7PR12MB2803.namprd12.prod.outlook.com (2603:10b6:408:32::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.21; Fri, 1 Apr 2022 03:22:54 +0000 Received: from CO1NAM11FT040.eop-nam11.prod.protection.outlook.com (2603:10b6:907:0:cafe::4c) by MW2PR16CA0018.outlook.office365.com (2603:10b6:907::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5123.25 via Frontend Transport; Fri, 1 Apr 2022 03:22:54 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 12.22.5.235) smtp.mailfrom=nvidia.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=nvidia.com; Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates 12.22.5.235 as permitted sender) receiver=protection.outlook.com; client-ip=12.22.5.235; helo=mail.nvidia.com; Received: from mail.nvidia.com (12.22.5.235) by CO1NAM11FT040.mail.protection.outlook.com (10.13.174.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.5123.19 via Frontend Transport; Fri, 1 Apr 2022 03:22:53 +0000 Received: from rnnvmail201.nvidia.com (10.129.68.8) by DRHQMAIL107.nvidia.com (10.27.9.16) with Microsoft SMTP Server (TLS) id 15.0.1497.32; Fri, 1 Apr 2022 03:22:52 +0000 Received: from nvidia.com (10.126.230.35) by rnnvmail201.nvidia.com (10.129.68.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.22; Thu, 31 Mar 2022 20:22:50 -0700 From: Spike Du <spiked@nvidia.com> To: <matan@nvidia.com>, <viacheslavo@nvidia.com>, <orika@nvidia.com>, <thomas@monjalon.net> CC: <dev@dpdk.org>, <rasland@nvidia.com> Subject: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper Date: Fri, 1 Apr 2022 06:22:26 +0300 Message-ID: <20220401032232.1267376-1-spiked@nvidia.com> X-Mailer: git-send-email 2.27.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.126.230.35] X-ClientProxiedBy: rnnvmail202.nvidia.com (10.129.68.7) To rnnvmail201.nvidia.com (10.129.68.8) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 66dd79b0-53cd-4079-5811-08da138ee8e3 X-MS-TrafficTypeDiagnostic: BN7PR12MB2803:EE_ X-LD-Processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr X-Microsoft-Antispam-PRVS: <BN7PR12MB2803A63501C8855F87288B89A8E09@BN7PR12MB2803.namprd12.prod.outlook.com> X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: S1BmzHUsOKkc0/iboE+EXzAR82vLxt1ktby1K6XsdZFcdwmm1sBVRiFFG4ADGT+abq2S1jVsDJoxG+lalirxGGUhWOezE5TrFajNdGOgRztjgjdW7+Us6p4oEYp3tMNThI5D/kTLIU33nH4qwjcHoQfiVkzOrIBr1yHYxqqtYUfUpX6j0pOsEGlEvF86TW0HO4u3KntdHxyrbm/GForuZ9vP6Ktnzhws+e/LEzBv086ebbyGPnPoGrEhUjfBfUW8Jz4aW+1mdPxNu0sm2tT9aJuMdtK1zDspCbuPQn1DtiDSnMEfYhitkAZNHY8l2oCt+Wsz7fx15Uiih7xoavUPWKoQN2mcgbcgE8Z1Y9z1YigPtESWiGpOa4LBqfks+fCpthWDSyrMxvBFHLULd+Idpk6U6Kyt6sX1WWJ2UtvfBQL20oA1ceZlgmVho94wJgMmsZm+NngO5HDCqY8snc4ewLrhs/xuCFTzxceagpBc6Tdvt8fTO5RJ9Jah0gGhVGZioc+zv8qZoskp4I8KE/Qw3SyYi3+glTaqpxGELBijuK6krmI2IhUQNR9HmsKA+X/CD5Cp7CSI0rE12ArXfIC4oElFczCIkGr3o/f4oXotqbmy9FQFLmONFD/F9REOqXbrR/Rz3FfsnQXF/VbIIWSCkI9o/BY4tzniZqXmy88BYP0+dG9CYIpYvnp/fgpPjWZGqnGp+aNmNNI3ZavMW0jsDw== X-Forefront-Antispam-Report: CIP:12.22.5.235; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:mail.nvidia.com; PTR:InfoNoRecords; CAT:NONE; SFS:(13230001)(4636009)(40470700004)(46966006)(36840700001)(316002)(70586007)(70206006)(110136005)(36860700001)(54906003)(40460700003)(4326008)(8676002)(86362001)(8936002)(55016003)(5660300002)(36756003)(508600001)(16526019)(26005)(83380400001)(82310400004)(336012)(426003)(6666004)(6286002)(107886003)(1076003)(2616005)(356005)(81166007)(186003)(7696005)(2906002)(47076005)(36900700001); DIR:OUT; SFP:1101; X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Apr 2022 03:22:53.8749 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 66dd79b0-53cd-4079-5811-08da138ee8e3 X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a; Ip=[12.22.5.235]; Helo=[mail.nvidia.com] X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT040.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR12MB2803 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org |
Series |
net/mlx5: introduce limit watermark and host shaper
|
|
Message
Spike Du
April 1, 2022, 3:22 a.m. UTC
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 app/test-pmd/cmdline.c | 149 ++++++++++++++++++ app/test-pmd/config.c | 122 +++++++++++++++ app/test-pmd/meson.build | 3 + app/test-pmd/testpmd.c | 3 + app/test-pmd/testpmd.h | 5 + doc/guides/nics/mlx5.rst | 87 +++++++++++ doc/guides/rel_notes/release_22_03.rst | 7 + drivers/common/mlx5/linux/meson.build | 21 ++- drivers/common/mlx5/linux/mlx5_common_os.c | 131 ++++++++++++++++ drivers/common/mlx5/linux/mlx5_common_os.h | 11 ++ drivers/common/mlx5/mlx5_prm.h | 26 ++++ drivers/common/mlx5/version.map | 3 +- drivers/common/mlx5/windows/mlx5_common_os.h | 24 +++ drivers/net/mlx5/linux/mlx5_ethdev_os.c | 71 --------- drivers/net/mlx5/linux/mlx5_os.c | 132 ++++------------ drivers/net/mlx5/linux/mlx5_socket.c | 53 +------ drivers/net/mlx5/mlx5.c | 61 ++++++++ drivers/net/mlx5/mlx5.h | 12 +- drivers/net/mlx5/mlx5_devx.c | 57 ++++++- drivers/net/mlx5/mlx5_devx.h | 1 + drivers/net/mlx5/mlx5_rx.c | 221 ++++++++++++++++++++++++++- drivers/net/mlx5/mlx5_rx.h | 9 ++ drivers/net/mlx5/mlx5_txpp.c | 28 +--- drivers/net/mlx5/rte_pmd_mlx5.h | 62 ++++++++ drivers/net/mlx5/version.map | 2 + drivers/net/mlx5/windows/mlx5_ethdev_os.c | 22 --- drivers/vdpa/mlx5/mlx5_vdpa_virtq.c | 52 +------ 27 files changed, 1057 insertions(+), 318 deletions(-)
Comments
On Fri, Apr 1, 2022 at 8:53 AM Spike Du <spiked@nvidia.com> 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
Hi Jerin, Thanks for your comments and sorry for the late response. For case one, I think I can refine the design and add LWM(limit watermark) in rte_eth_rxconf, and add a new rte_eth_event_type event. For case two(host shaper), I think we can't use RX meter, because it's actually TX shaper on a remote system. It's quite specific to Mellanox/Nvidia BlueField 2(BF2 for short) NIC. The NIC contains an ARM system. We have two terms here: Host-system stands for the system the BF2 NIC is inserted; ARM-system stands for the embedded ARM in BF2. ARM-system is doing the forwarding. This is the way host shaper works: we configure the register on ARM-system, but it affects Host-system's TX shaper, which means the shaper is working on the remote port, it's not a RX meter concept, hence we can't use DPDK RX meter framework. I'd suggest to still use private API. For testpmd part, I understand your concern. Because we need one private API for host shaper, and we need testpmd's forwarding code to show how it works to user, we need to call the private API in testpmd. If current patch is not acceptable, what's the correct way to do it? Any framework to isolate the PMD private logic from testpmd common code, but still give a chance to call private APIs in testpmd? Regards, Spike. > -----Original Message----- > From: Jerin Jacob <jerinjacobk@gmail.com> > Sent: Tuesday, April 5, 2022 4:59 PM > To: Spike Du <spiked@nvidia.com>; Andrew Rybchenko > <andrew.rybchenko@oktetlabs.ru>; Cristian Dumitrescu > <cristian.dumitrescu@intel.com>; Ferruh Yigit <ferruh.yigit@intel.com>; > techboard@dpdk.org > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact- > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; dpdk-dev > <dev@dpdk.org>; Raslan Darawsheh <rasland@nvidia.com> > Subject: Re: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper > > External email: Use caution opening links or attachments > > > On Fri, Apr 1, 2022 at 8:53 AM Spike Du <spiked@nvidia.com> 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
Hi Jerin, Thanks for your comments and sorry for the late response. For case one, I think I can refine the design and add LWM(limit watermark) in rte_eth_rxconf, and add a new rte_eth_event_type event. For case two(host shaper), I think we can't use RX meter, because it's actually TX shaper on a remote system. It's quite specific to Mellanox/Nvidia BlueField 2(BF2 for short) NIC. The NIC contains an ARM system. We have two terms here: Host-system stands for the system the BF2 NIC is inserted; ARM-system stands for the embedded ARM in BF2. ARM-system is doing the forwarding. This is the way host shaper works: we configure the register on ARM-system, but it affects Host-system's TX shaper, which means the shaper is working on the remote port, it's not a RX meter concept, hence we can't use DPDK RX meter framework. I'd suggest to still use private API. For testpmd part, I understand your concern. Because we need one private API for host shaper, and we need testpmd's forwarding code to show how it works to user, we need to call the private API in testpmd. If current patch is not acceptable, what's the correct way to do it? Any framework to isolate the PMD private logic from testpmd common code, but still give a chance to call private APIs in testpmd? Regards, Spike. > -----Original Message----- > From: Jerin Jacob <jerinjacobk@gmail.com> > Sent: Tuesday, April 5, 2022 4:59 PM > To: Spike Du <spiked@nvidia.com>; Andrew Rybchenko > <andrew.rybchenko@oktetlabs.ru>; Cristian Dumitrescu > <cristian.dumitrescu@intel.com>; Ferruh Yigit <ferruh.yigit@intel.com>; > techboard@dpdk.org > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact- > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; dpdk-dev > <dev@dpdk.org>; Raslan Darawsheh <rasland@nvidia.com> > Subject: Re: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper > > External email: Use caution opening links or attachments > > > On Fri, Apr 1, 2022 at 8:53 AM Spike Du <spiked@nvidia.com> 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
On Tue, Apr 26, 2022 at 8:12 AM Spike Du <spiked@nvidia.com> wrote: > > Hi Jerin, Hi Spike, > Thanks for your comments and sorry for the late response. > > For case one, I think I can refine the design and add LWM(limit watermark) in rte_eth_rxconf, and add a new rte_eth_event_type event. OK. > > For case two(host shaper), I think we can't use RX meter, because it's actually TX shaper on a remote system. It's quite specific to Mellanox/Nvidia BlueField 2(BF2 for short) NIC. The NIC contains an ARM system. We have two terms here: Host-system stands for the system the BF2 NIC is inserted; ARM-system stands for the embedded ARM in BF2. ARM-system is doing the forwarding. This is the way host shaper works: we configure the register on ARM-system, but it affects Host-system's TX shaper, which means the shaper is working on the remote port, it's not a RX meter concept, hence we can't use DPDK RX meter framework. I'd suggest to still use private API. OK. If the host is using the DPDK application then rte_tm can be used on the egress side to enable the same. If it is not DPDK, then yes, we need private APIs. > > For testpmd part, I understand your concern. Because we need one private API for host shaper, and we need testpmd's forwarding code to show how it works to user, we need to call the private API in testpmd. If current patch is not acceptable, what's the correct way to do it? Any framework to isolate the PMD private logic from testpmd common code, but still give a chance to call private APIs in testpmd? Please check "PMD API" item in http://mails.dpdk.org/archives/dev/2022-April/239191.html > > > Regards, > Spike. > > > > > -----Original Message----- > > From: Jerin Jacob <jerinjacobk@gmail.com> > > Sent: Tuesday, April 5, 2022 4:59 PM > > To: Spike Du <spiked@nvidia.com>; Andrew Rybchenko > > <andrew.rybchenko@oktetlabs.ru>; Cristian Dumitrescu > > <cristian.dumitrescu@intel.com>; Ferruh Yigit <ferruh.yigit@intel.com>; > > techboard@dpdk.org > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact- > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; dpdk-dev > > <dev@dpdk.org>; Raslan Darawsheh <rasland@nvidia.com> > > Subject: Re: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper > > > > External email: Use caution opening links or attachments > > > > > > On Fri, Apr 1, 2022 at 8:53 AM Spike Du <spiked@nvidia.com> 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
Hi Jerin, > > For case two(host shaper), I think we can't use RX meter, because it's > actually TX shaper on a remote system. It's quite specific to Mellanox/Nvidia > BlueField 2(BF2 for short) NIC. The NIC contains an ARM system. We have > two terms here: Host-system stands for the system the BF2 NIC is inserted; > ARM-system stands for the embedded ARM in BF2. ARM-system is doing the > forwarding. This is the way host shaper works: we configure the register on > ARM-system, but it affects Host-system's TX shaper, which means the > shaper is working on the remote port, it's not a RX meter concept, hence we > can't use DPDK RX meter framework. I'd suggest to still use private API. > > OK. If the host is using the DPDK application then rte_tm can be used on the > egress side to enable the same. If it is not DPDK, then yes, we need private > APIs. I see your point. The RX drop happens on ARM-system, it'll be too late to notify Host-system to reduce traffic rate. To achieve dropless, MLX developed this feature to configure host shaper on remote port. The Host-system is flexible, it may use DPDK or not. Regards, Spike. > -----Original Message----- > From: Jerin Jacob <jerinjacobk@gmail.com> > Sent: Sunday, May 1, 2022 8:51 PM > To: Spike Du <spiked@nvidia.com> > Cc: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; Cristian > Dumitrescu <cristian.dumitrescu@intel.com>; Ferruh Yigit > <ferruh.yigit@intel.com>; techboard@dpdk.org; Matan Azrad > <matan@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>; Ori Kam > <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL) > <thomas@monjalon.net>; dpdk-dev <dev@dpdk.org>; Raslan Darawsheh > <rasland@nvidia.com> > Subject: Re: [RFC 0/6] net/mlx5: introduce limit watermark and host shaper > > External email: Use caution opening links or attachments > > > On Tue, Apr 26, 2022 at 8:12 AM Spike Du <spiked@nvidia.com> wrote: > > > > Hi Jerin, > > Hi Spike, > > > Thanks for your comments and sorry for the late response. > > > > For case one, I think I can refine the design and add LWM(limit > watermark) in rte_eth_rxconf, and add a new rte_eth_event_type event. > > OK. > > > > > For case two(host shaper), I think we can't use RX meter, because it's > actually TX shaper on a remote system. It's quite specific to Mellanox/Nvidia > BlueField 2(BF2 for short) NIC. The NIC contains an ARM system. We have > two terms here: Host-system stands for the system the BF2 NIC is inserted; > ARM-system stands for the embedded ARM in BF2. ARM-system is doing the > forwarding. This is the way host shaper works: we configure the register on > ARM-system, but it affects Host-system's TX shaper, which means the > shaper is working on the remote port, it's not a RX meter concept, hence we > can't use DPDK RX meter framework. I'd suggest to still use private API. > > OK. If the host is using the DPDK application then rte_tm can be used on the > egress side to enable the same. If it is not DPDK, then yes, we need private > APIs. > > > > > For testpmd part, I understand your concern. Because we need one > private API for host shaper, and we need testpmd's forwarding code to show > how it works to user, we need to call the private API in testpmd. If current > patch is not acceptable, what's the correct way to do it? Any framework to > isolate the PMD private logic from testpmd common code, but still give a > chance to call private APIs in testpmd? > > Please check "PMD API" item in > http://mails.dpdk.org/archives/dev/2022-April/239191.html > > > > > > > Regards, > > Spike. > > > > > > > > > -----Original Message----- > > > From: Jerin Jacob <jerinjacobk@gmail.com> > > > Sent: Tuesday, April 5, 2022 4:59 PM > > > To: Spike Du <spiked@nvidia.com>; Andrew Rybchenko > > > <andrew.rybchenko@oktetlabs.ru>; Cristian Dumitrescu > > > <cristian.dumitrescu@intel.com>; Ferruh Yigit > > > <ferruh.yigit@intel.com>; techboard@dpdk.org > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact- > > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; dpdk-dev > > > <dev@dpdk.org>; Raslan Darawsheh <rasland@nvidia.com> > > > Subject: Re: [RFC 0/6] net/mlx5: introduce limit watermark and host > > > shaper > > > > > > External email: Use caution opening links or attachments > > > > > > > > > On Fri, Apr 1, 2022 at 8:53 AM Spike Du <spiked@nvidia.com> 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