From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id A38D5A04AA for ; Tue, 8 Sep 2020 17:43:59 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E48F34C99; Tue, 8 Sep 2020 17:43:58 +0200 (CEST) Received: from mail-pf1-f194.google.com (mail-pf1-f194.google.com [209.85.210.194]) by dpdk.org (Postfix) with ESMTP id 99721A3 for ; Tue, 8 Sep 2020 17:43:57 +0200 (CEST) Received: by mail-pf1-f194.google.com with SMTP id n14so3333434pff.6 for ; Tue, 08 Sep 2020 08:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=0FrfB+nKjFPukM1eZ1YlEbZqGWmZ1rwiX9NUE0m9/YY=; b=EVOqf2vrRX55hWcd2FLrVmzJ/1fBP0W63JcR8UQJxSzPysZcCChQk844FBAPoz4wVO AD9vXHD10vtigNXuJiAEPbaZSmIkS8EDRLBHSwPGTDVyOp4EDHKJF0jqfUeBvbS2B283 /9a/LvUwx8R62bHD5dFbflitPr+D1Ln+a6KKu6ulFqqXmQPhULG/lBuWgx4fhSmBW/fz lCs6ZuWXw09ZNrcTjvbuKwhqd8k3eAc82ICAh56J0cX12N0dPBj1W28rJqos+V1xhhFh N8SXak6d2TJeL6JX/OYgPMI6TGrDfxwW91shpyXwCXYbVCRuKGaOzSR3NnkdX3luPmFt sJEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=0FrfB+nKjFPukM1eZ1YlEbZqGWmZ1rwiX9NUE0m9/YY=; b=rqvjXHvz9OqX9P25T6UMDimusvEFQBhs4sdfyEneAHVuw78/C0kSkW4D/aU3JmEbBV PJTAZtr5kUTwaDxE8YuvGUKy7l+joicMm5jwh88byX5eMO8plBU48pgOpj++z05kY47v R6NJ7L+jOXJ5CRC+kVPSSxDtYhDQmdg4UE578a/9tJwyHGgPqAkU7pKqAw/N0t277XOc SYyZZB98lcI32jVANkdEeBPXUXagashF2aAa8mC37GBfkwpB/gKqaA6yP20obI7ZQKKY FLXkKAbTcEcRJKihIxWjFbNlsSCK1bQiVBRCY5kmQYSyzrd8jakLtQfu9nPbi68Xpo9q quFA== X-Gm-Message-State: AOAM533GbsUc9qFhV8PahKbBOLS+h5xvBlF9Scbwk4EWRubrZPouQGJT RM6EF7ZpIVJ0Tl4sLMM7CpEpQw== X-Google-Smtp-Source: ABdhPJyOt3w4ldQAdtSAbA1Qp/ilar4sSV2fp9qfiGglYyrbzZWpAuKZlxQHyLrdywkMtl+aSczzHw== X-Received: by 2002:a62:52ce:0:b029:13e:50c8:499b with SMTP id g197-20020a6252ce0000b029013e50c8499bmr11285857pfb.14.1599579836474; Tue, 08 Sep 2020 08:43:56 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id n11sm15861405pgd.2.2020.09.08.08.43.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Sep 2020 08:43:56 -0700 (PDT) Date: Tue, 8 Sep 2020 08:43:48 -0700 From: Stephen Hemminger To: "=?UTF-8?B?5bmz5bKhIOWGoOS6jA==?=" Cc: "users@dpdk.org" Message-ID: <20200908084348.1e8fccd5@hermes.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-users] how can i know the reason why the rx_nombuf couner increase? X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Sender: "users" On Tue, 8 Sep 2020 07:40:58 +0000 "=E5=B9=B3=E5=B2=A1 =E5=86=A0=E4=BA=8C" wrote: > Hi All, >=20 > This is my first post here. I've an issue, and I would like your help. >=20 > HW Environment: > HP DL360 Gen10 (Xeon Silver 4208 @ 2.1GHz) > HPE Ethernet 10Gb 2Port NIC 562T (Intel X550T, driver=3D5.1.0-k-rh7.6, f= irmware=3D10.51.3) >=20 > SW Environment: > DPDK 20.08 > Red Hat Enterprise Linux Server release 7.6 (Maipo) > Number of mbuf is 1024 * 1024 (plenty!) >=20 > I create the packet capture with DPDK 20.08 and received 1.2Gbps(1Mfps) p= ackets on my=20 > server described above, but, rarely(about once per 100 hours) encountered= the packet loss > problem. >=20 > To find the reason, I use the rte_eth_stats_get() and found imissed and r= x_nombuf counter=20 > was increased when packet loss was happened. >=20 > Is this means that the CPU power was insufficient? or my application rare= ly slow down? or > none of them? Does anyone know how can I know that? The counter imissed means the application can not keep up with the packet r= ate. The counter rx_nombuf means the mbuf pool was not big enough (or your appli= cation is leaking mbufs). > on a side note... >=20 > When I wrote the captured packet to SSD drive, rarely packet loss was hap= pen, but,=20 > when I wrote them to SAS HDD drive (it is slower than SSD) the packet los= s was not=20 > occurred(at least one week). it was very mysterious... Not at all surprising, packet capture is limited by speed of writing to fil= e.