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 C319BA09E4 for ; Thu, 4 Feb 2021 17:04:10 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ABEEB24069F; Thu, 4 Feb 2021 17:04:10 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mails.dpdk.org (Postfix) with ESMTP id 92755240671; Thu, 4 Feb 2021 17:04:07 +0100 (CET) IronPort-SDR: ODzDpzIpaepo7eVh+sWW+m0Lq5R1bmgrj2+8238Ly6kj+row1kAqgpuz77wMSdapT+I0ygQlpL 93QjamUbq23Q== X-IronPort-AV: E=McAfee;i="6000,8403,9885"; a="177762859" X-IronPort-AV: E=Sophos;i="5.79,401,1602572400"; d="scan'208";a="177762859" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Feb 2021 08:04:04 -0800 IronPort-SDR: WM+p8G1/058Mg7hTopa2dJfVOdBvn+Xz7ZIXXeDntKedILsxcReONbuCZVCp3fWfgp7gTcceD4 TimZpYj6d8FA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.79,401,1602572400"; d="scan'208";a="357234116" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga003.jf.intel.com with ESMTP; 04 Feb 2021 08:04:04 -0800 Received: from fmsmsx607.amr.corp.intel.com (10.18.126.87) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 4 Feb 2021 08:04:04 -0800 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx607.amr.corp.intel.com (10.18.126.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 4 Feb 2021 08:04:03 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2 via Frontend Transport; Thu, 4 Feb 2021 08:04:03 -0800 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.104) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Thu, 4 Feb 2021 08:04:01 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H5y0SahX+K+gfShjzYM8X8Se28tFavaEBAVFzrDLKL/sF9ZKby+FyEYF+DRVkiVyJo6npZ/5WSsQgB2NMPUt6qbfgIVdOIGBoo2J8iZuHZ7HwAWSbFutYbJUhIRavQNfENN7t/lh86g4Zxm7JRcAGZCHlFdLqjuVgNLCvU2m7Zvt22IhkLHaChhW143zor3vehs4PePgJIk8Xdae6OqTKz8eeQkiogXQPmdoxrwKry3awBZ0kV7ymDWzAdxMsQMUk+Ayjaqv81j//MgcAYNUqnIYCBii0lwIclDeNjqyjRqeMT8KrBd5X53u0Y6eJ+yFVhNSJKoJByS8RGr3SP20JQ== 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-SenderADCheck; bh=Pl+j6QMe7q8eNiAPSq986BkkR6iMfJIOnwLv/QlLgrc=; b=TB9hqNDiGzOZ+SGxrHoUHOXtQOGq1zQgImzE+TjGc1Wtiddurz5dPitHU05UnqO6iqJTZGV4ERUKZpursjX5iHA3MpJtcvjWuuZRBTXfYo8Y9QSGQxwYDo8GOtCbmjp2wozQ1hgWBrbB9tQEfQtA/BXopHnCMDaX2UpvUjkI2RIfLAAXls5NMI6Yf1Pak7z//RozvYJZWHeWjrqNn55RyCccFQpVK1/T1w+oIEnp2zwXOygSuMD2PhA+IRpTyeoww/dadlZkQUDpKKQpkjDjAJBS/qfqSrqMSw+m+sAJ0uGgoAkBtCj9m2KED4ETKowixRRF9JNekgnzeW89kP0wPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pl+j6QMe7q8eNiAPSq986BkkR6iMfJIOnwLv/QlLgrc=; b=Qtg28r19BbT/jZn41u/JkHr277accl6I5JI5IhS55s44bGiYIRIV11g/pZ8e7SICZf8uIhRZ7jOFDQNS8zjXafcPzHgEXKIJ9oKVjfgWpBSKKLMxEoNwvu+m8chpw3dul2WoRxcB/tcYYpUTU/VQneDK8TxsRV0WKhjxCxhkv/g= Received: from BYAPR11MB3751.namprd11.prod.outlook.com (2603:10b6:a03:f8::31) by SJ0PR11MB5103.namprd11.prod.outlook.com (2603:10b6:a03:2d3::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.20; Thu, 4 Feb 2021 16:03:57 +0000 Received: from BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::31bb:895e:6e93:7e9d]) by BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::31bb:895e:6e93:7e9d%7]) with mapi id 15.20.3805.026; Thu, 4 Feb 2021 16:03:57 +0000 From: "Ferriter, Cian" To: "Yigit, Ferruh" CC: "dev@dpdk.org" , "stable@dpdk.org" Thread-Topic: [PATCH] net/pcap: fix infinite Rx with large files Thread-Index: AQHW+kQvUJ0JBUpdjkavZbxgT9TFJqpIKMDw Date: Thu, 4 Feb 2021 16:03:56 +0000 Message-ID: References: <20210203154920.2449179-1-ferruh.yigit@intel.com> In-Reply-To: <20210203154920.2449179-1-ferruh.yigit@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.5.1.3 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [37.228.234.38] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fd12a4b8-a581-4dea-9f52-08d8c9267a53 x-ms-traffictypediagnostic: SJ0PR11MB5103: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MTHJkvx5db/71C3+n2wvxcoXex/uUBB7OjUNBm3veBNazogCoF8TGo5IhNT1W5bFJMAEF2ijzFSrZGn133Z9rmJJg4/v7AfC8/pbQTsBsxwIgmCfCaCiE9/OXrhkk3RjZOKRt3zp75f+ZLGknoV2WpAXyOCpZcVGxZSn63sVf23seh/l+lf7kGTmRc/mEM9bROx961N42+KuICnWsJ50qykw6p6p0SwxS2oV067Go0JLSlNP0oOKFp4SOAkGjCobawXrjy0KnJxtlHNv7K4jliiFTnwGOBut8tBSjqPIfVOmgJ0QKqLK1urvjPxBtEMwOsHPpej4keclLEQEAfAJxiM0gRnN5t+1aRfVtuZ6XOBqDLlOK4lbDdGc3QQZJHTgV3bbzzbmvwz9YwxjclvDnolQ4DWaTcpJPvhGx/yVKyQ7zA5tqyvtN8Cw8HpstM5Ch7h7mVu2tFZaAStuJQsXgBzNQmAC6s5x8eOGQSnkfU68AgEG5yZT1JJqJJXIx8EzMI86pjFy5cbA26pfIicgGQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3751.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(346002)(136003)(396003)(39860400002)(6636002)(186003)(2906002)(26005)(8676002)(5660300002)(8936002)(66946007)(66476007)(52536014)(86362001)(83380400001)(71200400001)(64756008)(33656002)(66556008)(4326008)(66446008)(450100002)(478600001)(54906003)(316002)(6506007)(53546011)(9686003)(6862004)(55016002)(76116006)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?Ht5lFhGRohf5NBbqUuNAnfBkiXOpmaMW20DSZw2cxwE/mbKaDLL5vMsSTa9X?= =?us-ascii?Q?O/UVk5HcXwFcCnuQQPF5fySQs7Ao7PpNrm9i0GvZL5rJqxv+lgNQfbdd23HW?= =?us-ascii?Q?skNQcQUhBky25Quwur1aC7VV0dcgRiYpMChJurRIcTZjlbl1jF5SVGAkZwOw?= =?us-ascii?Q?LXXCbpuVg8fCFbDS/oCPmP7M6kfTR8XS5O7m+RoIdUd0iftF/38wGX9+9pMM?= =?us-ascii?Q?zsLf7JKAnJLDkkZrHHDo9wDQjzh5ftdUsF1zUwiCyMMoYcbx6vdin8jN5MBF?= =?us-ascii?Q?FTEjwMg4nXhfQC9AwGfDR61BlYPFOXhEY6cL2Mky+8IQMYwR9ueUIyANNiF3?= =?us-ascii?Q?EMSQkvsO2zjm+ZuRBZXTNwQMG4q1qRhGg7jwg+LWxwNU4/+n733QFUo6r6SC?= =?us-ascii?Q?uOcbTiLaMt3SpXZ2cA040exRBT5X+AZIOVpYUr+UwU8p2PXvvqNYqIG2+ADd?= =?us-ascii?Q?GlmSUNhKJxk5allmh/D5MxbYELWHHomSOoedq5tZ2lV1uY7yCeE/Qbe9yKuY?= =?us-ascii?Q?eL/jCLfYbD+WpI5fzB2JXkKBeEVc4aECokUIN6++53qxoBaVyeapq8c51DjT?= =?us-ascii?Q?Ux8IHx8ADXgJ2maRW0Zu0I+swcySdV2/SVpLL/qDNqi59+vjqnTmAyKIwRAh?= =?us-ascii?Q?RG77QtsQuOplY4sokOYK1R4HEVi0K6Q3dx12RFpC3pqBGdORBQf9z5DPrHcV?= =?us-ascii?Q?e0uORv73imGCn9LlMJwqcySNlwS9qL3AMtuZ6757VDCBJ5mQZkQPUfqRSD5D?= =?us-ascii?Q?3YLQE+knMHGw0y+zdkbE0i42qedCNrvmdIISzU8u8XaWx6ezk5CnoUmBi87n?= =?us-ascii?Q?f8EMIA/dSsLAdemeZrFuuyDFzAHKsNrMpU5T9afszAqX89fQ/UfZcYvt/MkA?= =?us-ascii?Q?6vgGWt/igXD8csltAIIR4hH7ISi6zwk1XYmQbryHV1LQbEumxKxUjE4dSaSU?= =?us-ascii?Q?YUoSslE8aL4/04vDR8rtfcz4x9UTUzRt+9U+Ql7qzbZjDx6Foay+J9PdNe5U?= =?us-ascii?Q?fgC+rwW75fhs4xQyRMEoQO0baZOoFHQJFO7oTWux9rk1pXCH7BCBjg+FyjzZ?= =?us-ascii?Q?85y1EDK6?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3751.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fd12a4b8-a581-4dea-9f52-08d8c9267a53 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2021 16:03:56.9966 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pFnWWn6GMcabcDfO7F6Yh1qIZucplI0rUc4/EuwUT2syi+oeJIrj4an5+agE3rTP1Izca2jLVZzY8PKRLnFHfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5103 X-OriginatorOrg: intel.com Subject: Re: [dpdk-stable] [PATCH] net/pcap: fix infinite Rx with large files X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" Hi Ferruh, This fixes the issue I was seeing. Now an error is reported, rather than si= lent failure. I have one piece of feedback about the particular error message below inlin= e which you can take or leave, I'm happy for you to upstream this fix eithe= r way. Acked-by: Cian Ferriter > -----Original Message----- > From: Yigit, Ferruh > Sent: Wednesday 3 February 2021 15:49 > To: Ferriter, Cian > Cc: Yigit, Ferruh ; dev@dpdk.org; stable@dpdk.org > Subject: [PATCH] net/pcap: fix infinite Rx with large files >=20 > Packet forwarding is not working when infinite Rx feature is used with > large .pcap files that has high number of packets. >=20 > The problem is number of allocated mbufs are less than the infinite Rx > ring size, and all mbufs consumed to fill the ring, so there is no mbuf > left for forwarding. >=20 > Current logic can not detect that infinite Rx ring is not filled > completely and no more mbufs left, and setup continues which leads > silent fail on packet forwarding. >=20 > There isn't much can be done when there is not enough mbuf for the given > .pcap file, so additional checks added to detect the case and fail > explicitly with an error log. >=20 > Bugzilla ID: 595 > Fixes: a3f5252e5cbd ("net/pcap: enable infinitely Rx a pcap file") > Cc: stable@dpdk.org >=20 > Reported-by: Cian Ferriter > Signed-off-by: Ferruh Yigit > --- > drivers/net/pcap/rte_eth_pcap.c | 40 ++++++++++++++++++++------------- > 1 file changed, 25 insertions(+), 15 deletions(-) >=20 > diff --git a/drivers/net/pcap/rte_eth_pcap.c > b/drivers/net/pcap/rte_eth_pcap.c > index ff02ade70d1a..98f80368ca1d 100644 > --- a/drivers/net/pcap/rte_eth_pcap.c > +++ b/drivers/net/pcap/rte_eth_pcap.c > @@ -735,6 +735,17 @@ eth_stats_reset(struct rte_eth_dev *dev) > return 0; > } >=20 > +static inline void > +infinite_rx_ring_free(struct rte_ring *pkts) > +{ > + struct rte_mbuf *bufs; > + > + while (!rte_ring_dequeue(pkts, (void **)&bufs)) > + rte_pktmbuf_free(bufs); > + > + rte_ring_free(pkts); > +} > + > static int > eth_dev_close(struct rte_eth_dev *dev) > { > @@ -753,7 +764,6 @@ eth_dev_close(struct rte_eth_dev *dev) > if (internals->infinite_rx) { > for (i =3D 0; i < dev->data->nb_rx_queues; i++) { > struct pcap_rx_queue *pcap_q =3D &internals- > >rx_queue[i]; > - struct rte_mbuf *pcap_buf; >=20 > /* > * 'pcap_q->pkts' can be NULL if 'eth_dev_close()' > @@ -762,11 +772,7 @@ eth_dev_close(struct rte_eth_dev *dev) > if (pcap_q->pkts =3D=3D NULL) > continue; >=20 > - while (!rte_ring_dequeue(pcap_q->pkts, > - (void **)&pcap_buf)) > - rte_pktmbuf_free(pcap_buf); > - > - rte_ring_free(pcap_q->pkts); > + infinite_rx_ring_free(pcap_q->pkts); > } > } >=20 > @@ -835,21 +841,25 @@ eth_rx_queue_setup(struct rte_eth_dev *dev, > while (eth_pcap_rx(pcap_q, bufs, 1)) { > /* Check for multiseg mbufs. */ > if (bufs[0]->nb_segs !=3D 1) { > - rte_pktmbuf_free(*bufs); > - > - while (!rte_ring_dequeue(pcap_q->pkts, > - (void **)bufs)) > - rte_pktmbuf_free(*bufs); > - > - rte_ring_free(pcap_q->pkts); > - PMD_LOG(ERR, "Multiseg mbufs are not > supported in infinite_rx " > - "mode."); > + infinite_rx_ring_free(pcap_q->pkts); > + PMD_LOG(ERR, > + "Multiseg mbufs are not supported in > infinite_rx mode."); > return -EINVAL; > } >=20 > rte_ring_enqueue_bulk(pcap_q->pkts, > (void * const *)bufs, 1, NULL); > } > + > + if (rte_ring_count(pcap_q->pkts) < pcap_pkt_count) { > + infinite_rx_ring_free(pcap_q->pkts); > + PMD_LOG(ERR, > + "Not enough mbuf to fill the infinite_rx ring. " > + "At least %" PRIu64 " mbufs per queue is > required to fill the ring", > + pcap_pkt_count); [Cian Ferriter]=20 So we can say that the issue is either too many packets in the PCAP or too = few mbufs for the ring. What can the user do about this? They can use a PCAP with less packets. Can they change how many mbufs are available by passing more memory or any = other method? Should be mention these remedies, or is this outside the scope for an error= message? As I mentioned, I'm happy for you to upstream either way. > + return -EINVAL; > + } > + > /* > * Reset the stats for this queue since eth_pcap_rx calls > above > * didn't result in the application receiving packets. > -- > 2.29.2