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 679B8A0503; Fri, 6 May 2022 13:09:39 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0C31040395; Fri, 6 May 2022 13:09:39 +0200 (CEST) Received: from stargate.chelsio.com (stargate.chelsio.com [12.32.117.8]) by mails.dpdk.org (Postfix) with ESMTP id 8D6514014F for ; Fri, 6 May 2022 13:09:37 +0200 (CEST) Received: from localhost (sreekanth.asicdesigners.com [10.193.177.149] (may be forged)) by stargate.chelsio.com (8.14.7/8.14.7) with ESMTP id 246B9YEY019001; Fri, 6 May 2022 04:09:35 -0700 Date: Fri, 6 May 2022 16:39:33 +0530 From: Rahul Lakkireddy To: Ferruh Yigit Cc: dev@dpdk.org Subject: Re: [PATCH 4/5] net/cxgbe: track packets dropped by TP due to congestion Message-ID: References: <323a4fe735f784ec49c6c93b18a2b21cde1d05c3.1650297776.git.rahul.lakkireddy@chelsio.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thursday, May 05/05/22, 2022 at 17:28:55 +0100, Ferruh Yigit wrote: > On 4/18/2022 11:24 PM, Rahul Lakkireddy wrote: > > Rx packets can get dropped at TP due to congestion and this info > > will not get propagated to MPS. Track these Rx dropped packets > > in imissed counter. Also add xstats for these counters. > > > > Signed-off-by: Rahul Lakkireddy > > What 'TP' stands for? As far as I understand it is a kind of FW (TP > Microcode) but I didn't able to find any reference to it. Transport Processor (TP) on the NIC delivers the incoming packets from the wire to NIC's DMA engine to place the packets in Rx buffers. TP sends signal towards the Multi-Port Switch (MPS) near the MAC when the Rxqs run out of Rx buffers posted by driver. These MPS buffer drop stats are already accounted for in imissed counters. However, if a large number of Rxqs run out of Rx buffers simultaneously, then the TP can start dropping packets by itself without informing to the MPS if there is heavy congestion on the channel. These packets dropped by TP that could not be informed to MPS are now being accounted for in imissed counters in this patch. Thanks, Rahul