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 E3C7CA0C43; Tue, 14 Sep 2021 15:39:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A64364068F; Tue, 14 Sep 2021 15:39:58 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id A357F4003C for ; Tue, 14 Sep 2021 15:39:56 +0200 (CEST) X-IronPort-AV: E=McAfee;i="6200,9189,10106"; a="209225384" X-IronPort-AV: E=Sophos;i="5.85,292,1624345200"; d="scan'208";a="209225384" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2021 06:39:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,292,1624345200"; d="scan'208";a="470147010" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga007.fm.intel.com with ESMTP; 14 Sep 2021 06:39:55 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) 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.2242.12; Tue, 14 Sep 2021 06:39:54 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Tue, 14 Sep 2021 06:39:54 -0700 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (104.47.73.169) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Tue, 14 Sep 2021 06:39:54 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OhKYJfAR+LiEjQW3YldHdQlXCRRcXgqW4oUc5jdvwVIt/K94GqlJxQin9Osm1/KeZ2543W7IG9hiy1a+6zOc5iE21EvLfjaA1zb+KsV0tUkOqnOvN1Wj01fHkMO34QZ4LE0u7fz8OI9Equj64N/xXrIlyiKEgcMOVsXSv0Sx/7FbbjVmuTwLIt/1B59qM/ikxaPgzZ13sF0qff4+7+VZa3dqmM9byC9ZrbvUVELlGQVZFYLsnFDlL06Ol/IwCkLJAr3l7gOoI7ZMbe6rFCqMq9NgY9MNXkFwb+d60tX0t7/uvkeDVWIOjDGsyXRMoq2b32bvX/07YKuchRa/xYz0DQ== 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; bh=t9jZPMExVPl4SUPcwN1jw4P6tH93ME8zMV+zKeq4mEs=; b=IVMhbfCT6bU6tRZ6n6fbz5nZb0Vn5Zclk6ceOQcyE4ejO59lYmOvO6LGMWVOpB3ZSG6hscZDGN7QIAlwXNnCXqXbnmTS3yITg5vtpnsqZptEu/B36QPttdQLXE8GvSE/IukUxMrL7C9a1QmgV/O2CJHRYwgfmvwbfsmK3SA6QZiJcsBLI3KRQxgkqxKyZoml+ZFnAH0fw8ZBncgpY/ien3F0XuKRDFm6GYU543H1tGsdLG7H6b2A4U5BkxKM3nKuxKQsfb8k35SuRGcknuU7E0fIEmdVEQDn0SA9k5ppXuXt+Muh7TUTLjW+kfd5ANvHy8CPVY97C15/mDr27MFD8A== 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=t9jZPMExVPl4SUPcwN1jw4P6tH93ME8zMV+zKeq4mEs=; b=iQkyzMfQYGr45tBrayT82lJSTf4AGeD2F2xyUOyyFkRei3MeCsCkYOqXGTTRGSOe0ptNZSKBLYS7C0uDWtPIfknVBDzGK6e+QTVbCGoYTkP1oKQUMxuqhzWvFqXIERA/3aGXf8WaZn2oQ+KqWTNzDQ01dQuTz9LpUFtomM9tIL4= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=intel.com; Received: from PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) by PH0PR11MB5174.namprd11.prod.outlook.com (2603:10b6:510:3b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Tue, 14 Sep 2021 13:39:53 +0000 Received: from PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc]) by PH0PR11MB5000.namprd11.prod.outlook.com ([fe80::747b:3a08:d1ec:31fc%5]) with mapi id 15.20.4500.019; Tue, 14 Sep 2021 13:39:53 +0000 To: Qiming Chen , References: <20210828075628.1896-1-chenqiming_huawei@163.com> <20210828094751.1955-1-chenqiming_huawei@163.com> From: Ferruh Yigit CC: Dmitry Kozlyuk X-User: ferruhy Message-ID: <351139c2-3931-ef76-6324-4c42d413d958@intel.com> Date: Tue, 14 Sep 2021 14:39:48 +0100 In-Reply-To: <20210828094751.1955-1-chenqiming_huawei@163.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: DB9PR02CA0020.eurprd02.prod.outlook.com (2603:10a6:10:1d9::25) To PH0PR11MB5000.namprd11.prod.outlook.com (2603:10b6:510:41::19) MIME-Version: 1.0 Received: from [192.168.0.206] (37.228.236.146) by DB9PR02CA0020.eurprd02.prod.outlook.com (2603:10a6:10:1d9::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.14 via Frontend Transport; Tue, 14 Sep 2021 13:39:52 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ecb23033-1ecf-47fa-e5c5-08d977852230 X-MS-TrafficTypeDiagnostic: PH0PR11MB5174: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2803; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 96D7AzS3duZTlq8GNHIppfoGWsVgteArayulWnXYwuFk9CF+zRELxlLfJ6nCexJC+17/qPU47nGo1E3rC2+mPWRypFe1XP2JS0PwFVZwYdcdbExVUbqJ6Y4qIxXoZKx1hVgmbHjclGWKDgJID2Xu9R6LCUEazWWfHWsV5pxqXlNgB111ZclVUHEhMlXZhKIRhl3Yn0+D8jqvMnEKj6dN+ohT6sOkk4nOQ+/UOhKk8GoEsa6yWFfqb86EnWns8zQhRBAqI4d2M5rxVcp7BrmkMJx85lLFMs1HzXmutlX53VYG7DwYiqxu5JwYBD5Ryno9jAAaBFLh7eWMTGN2qqQ2KGK6sJR521UYlNsX1W8TR7dCsjFvprOql0ZQ6wq6IcP2HmV+OLjl+ROjcRqpCxxM39D+wsG7x11ps9hEqwKBLpXJ+aab7jPoqRz1wjyGj1aLOX2mQOOMRMzZrMrQI6QDUJnv2sveVkzdC7FBi2Yb1J57jUuvYLLjDFKUhqAy7/YSTd9l/5Av78A0/Wrm4Qs8q2/UMc6Ii9ZgFEnJU1zQ6co1PRVs52l/sq0m6yHka1METmcd0Ij8OYa9xCnZ/ofLWMgCHn84I2cTZ2nIWoWe95EnhZmVGCs7sz0SKHjLhSR/mwb00PA7QfMCH6lQX8accMwVtRh3VnbCI4geeIjhPymv5BZ4WkBBHVTJ+loVGId7wSepf49hvjeWSbVY3rqO2Q== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB5000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(31686004)(8676002)(26005)(6486002)(956004)(44832011)(83380400001)(8936002)(36756003)(2616005)(66556008)(2906002)(31696002)(66476007)(66946007)(86362001)(5660300002)(508600001)(316002)(16576012)(6666004)(53546011)(38100700002)(186003)(4326008)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VlZHZFQ0QmdmZXN5THVucjNFS09PNS92NzZOYlpVeitsSjl6dURPV0sxTjJ2?= =?utf-8?B?Tk9MRFJ4Z0c5bTZBbTRiNzZWRll5ejczQlRVbWZoYU1Cc0tWbmJ4OWJyT0pF?= =?utf-8?B?MmQvaHRRYzBVUEkxaDhNcUgyL3VYMVpyOUtUbGVMc3Q2cTZncGNhYitFUkla?= =?utf-8?B?UEFrcUZmRGMxYXYrVTMrcTJ0NkV5UkFOVzNyNEN3THkzUnR0bTBzRU9pblhY?= =?utf-8?B?WWM5OS80Q0tHUU84SVcwb2UrQ3FKdnN0Ty9EV1pPMjByT2hyR2VicXhNMTBm?= =?utf-8?B?eVkvSHJQSFJzcERTTXEwRE16UzdkWWZab2JQOUF0V29yQklNK2RKa2c3VXh4?= =?utf-8?B?T1NPM0FFS0htZGVJTkdZRDJVd1lXbmlJc0VxMExoQ3c1amRObUNWZzQrZjdC?= =?utf-8?B?aS9FVExTbVl0WFErUDlFd1FyZjNYSy9iTzhyaUNjTDZNbmsybU5hTDlJRVNn?= =?utf-8?B?QlNyZGhpc2tQY1R6SzE4MDVsY2ZxL0x5eWt6aFFpSXRmZjZLQS9MK1pPZ2VL?= =?utf-8?B?SGtxbE5tNit3OE93Y1pjdU9DL0dGTXlmY2VVQ0pGWUoxaWNZaFhWOVg5UGg1?= =?utf-8?B?WXRuekROQVh0L0orcUs0SEZCWlpJMitYbC9iUXhFcTlpU0Jrdk9iaVpTWWxY?= =?utf-8?B?SFNFZlg2YlhQeEpCRHBQOG5qWGZJNDFTSUdrYWpYMWhzbWpwcVorNEFOUXVM?= =?utf-8?B?M2JwbHB3eVhKc2EwSlR3a0RwR3EwalJWTlIxeFdReElTWXFhOG5Od2Radkp1?= =?utf-8?B?QnJrQThKdTVRQkJxS3hXbUlFRmsxQ0RyRG9jQmRycmV3SkYrczkvOHlJd3kr?= =?utf-8?B?aFI4VHVkN1lOdzZrSmhpRitCUlRZL2IrdUNoNDNhLy94NHlTSlo2VDl2Vnp5?= =?utf-8?B?c3oyajJlTnBoN0d1YVZzempEeW8rTFI2N24vRENlUVBFdDNvbkEvUTlJQ1Fm?= =?utf-8?B?d0dVdFBCeEcxb0FVTE1JenFZOWxTYmQ2K0oySjlKcldxZGMvZVNNbDlpZGFD?= =?utf-8?B?UmpjT0FCMkFScjBtMThsRFoxK0o0OVJtWDMyYkgzSERwcVJ3c1pKSnBCblF4?= =?utf-8?B?ajFYT0ZVaWZYNGM2V2tpeHJZTE4yWUV3aVZhV25FcG51ZThrMnc5dUpzdTlR?= =?utf-8?B?bTdoeWdsZDZOcjBUS1pXUWZySGpQdFFMd0VEOXRTSjlTb3FPK2RmWHlLUDdz?= =?utf-8?B?UU9ZT1U5MklvNVZ4dWdPQzVONFJHY3pncmZHZmhpdlhDN0ZrYU9CUXpPMVVp?= =?utf-8?B?WXRIQ1FwZDk1S0FqeFNrNWRIZjdkcjVwYVZzYitTN1B2OHU2YjZYa3BBWGlj?= =?utf-8?B?cGtjczBPL3ZtbmZXMzZZbER5ZmxHaFR2YmYyWFpOYXBvV2tNMWxBZUNyNHJW?= =?utf-8?B?eldrdjFmMGRIYXp0MENLcnFYd1oxV2FsS01YbzAxdnI2YXdhaEpNR3JJT3VJ?= =?utf-8?B?YkRqQm1pakVDT2daazE1UE01dmN3RG9kY0JiaUlxWHdsMjdaNzhiRmhMbnlM?= =?utf-8?B?YzY1TUFxeXV4OUozTG1VQkxkRnFiSGpvLzl5V2NDcTdHbjdMQnEvanV4ZWFE?= =?utf-8?B?ejVlR2JBcTJjdmpoWTB5U2Rya3haLzRMcEV3V216VXBKZGFIaHJQMGdibm5u?= =?utf-8?B?aFpMcUU4azFjVGhEMmVGVzZGd3c3S01ib0NMVVVBTlhmVjdrMVlWUzVObHJG?= =?utf-8?B?MDRrd1k3TVNmaWJWZFlyYldaZ2dEZGZ6SzJkbE1ibEswci9jY0g2ZWFSMWJR?= =?utf-8?Q?5a+oZxFaniPzHEprurYIGjFhV9wvghoEIfYE05i?= X-MS-Exchange-CrossTenant-Network-Message-Id: ecb23033-1ecf-47fa-e5c5-08d977852230 X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5000.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2021 13:39:53.8856 (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: ixYJWpCkK/FZ7kFRnqBkzJ74CUy0pGYb4Iif5UUAbn0vBaaoh43J9cmRdm7T3orCIbK338P9Ojdz/YZHqj550w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5174 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH v3] net/pcap: support buffer size parameter 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 Sender: "dev" On 8/28/2021 10:47 AM, Qiming Chen wrote: > When the pcap port is probed, the size of the pcap message buffer is not > set, the default is 2M, and then this value has a great impact on the > message forwarding performance. Therefore, parameters are provided for > users to set. > Hi Qiming, I assume you suggest buffer should be set bigger than 2M for better performance. I can see following description for "pcap message buffer" [1], I am not clear why this impacts the performance, can you please clarify? If the producer rate is higher than consumer rate, performance would be same but bigger buffer only delays the packet drops. It may only help on the case producer has peaks, but still not sure why it increase the performance. I did quick checks and not observed any performance improvement, can you please detail your usecase? Another concern is below description mentions "On some platforms, the buffer's size can be set". Pcap PMD now supports Windows too (cc'ed Dmitry), I wonder if this features is supported on Windows? [1] buffer size Packets that arrive for a capture are stored in a buffer, so that they do not have to be read by the application as soon as they arrive. On some platforms, the buffer's size can be set; a size that's too small could mean that, if too many packets are being captured and the snapshot length doesn't limit the amount of data that's buffered, packets could be dropped if the buffer fills up before the application can read packets from it, while a size that's too large could use more non-pageable operating system memory than is necessary to prevent packets from being dropped. The buffer size is set with pcap_set_buffer_size(). > In order to pass the buffer size parameter parsed by the probe to the > start function, the buf_size member variable is added to the > struct pmd_process_private structure. At the same time, for the uniform > code style, the buf_size member variable is also added to the > struct pmd_devargs structure, which is used by the probe function. > Why added to process_private data, but not to 'struct pmd_internals'. Process private data is for the variables that will be different for primary and secondary process. > Signed-off-by: Qiming Chen > --- > v2: > Clear coding style warning. > v3: > When buf_size=0, the modification keeps the old implementation unchanged. > --- > drivers/net/pcap/pcap_ethdev.c | 78 +++++++++++++++++++++++++++++----- > 1 file changed, 68 insertions(+), 10 deletions(-) Documentation also needs to be updated: 'doc/guides/nics/pcap_ring.rst' > > diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c > index a8774b7a43..fdc74313d5 100644 > --- a/drivers/net/pcap/pcap_ethdev.c > +++ b/drivers/net/pcap/pcap_ethdev.c > @@ -33,6 +33,7 @@ > #define ETH_PCAP_IFACE_ARG "iface" > #define ETH_PCAP_PHY_MAC_ARG "phy_mac" > #define ETH_PCAP_INFINITE_RX_ARG "infinite_rx" > +#define ETH_PCAP_BUF_SIZE_ARG "buf_size" > > #define ETH_PCAP_ARG_MAXLEN 64 > > @@ -98,6 +99,7 @@ struct pmd_process_private { > pcap_t *rx_pcap[RTE_PMD_PCAP_MAX_QUEUES]; > pcap_t *tx_pcap[RTE_PMD_PCAP_MAX_QUEUES]; > pcap_dumper_t *tx_dumper[RTE_PMD_PCAP_MAX_QUEUES]; > + int buf_size; > }; > > struct pmd_devargs { > @@ -109,6 +111,7 @@ struct pmd_devargs { > const char *type; > } queue[RTE_PMD_PCAP_MAX_QUEUES]; > int phy_mac; > + int buf_size; > }; > > struct pmd_devargs_all { > @@ -131,6 +134,7 @@ static const char *valid_arguments[] = { > ETH_PCAP_IFACE_ARG, > ETH_PCAP_PHY_MAC_ARG, > ETH_PCAP_INFINITE_RX_ARG, > + ETH_PCAP_BUF_SIZE_ARG, > NULL > }; > > @@ -521,11 +525,46 @@ open_iface_live(const char *iface, pcap_t **pcap) { > } > > static int > -open_single_iface(const char *iface, pcap_t **pcap) > +open_single_iface(const char *iface, int buf_size, pcap_t **pcap) > { > - if (open_iface_live(iface, pcap) < 0) { > - PMD_LOG(ERR, "Couldn't open interface %s", iface); > - return -1; > + if (buf_size == 0) { > + if (open_iface_live(iface, pcap) < 0) { > + PMD_LOG(ERR, "Couldn't open interface %s", iface); > + return -1; > + } > + } else { > + pcap_t *p = pcap_create(iface, errbuf); > + if (p == NULL) { > + PMD_LOG(ERR, "Couldn't create %s pcap", iface); > + return -1; > + } > + > + if (pcap_set_snaplen(p, RTE_ETH_PCAP_SNAPLEN) < 0) { > + PMD_LOG(ERR, "Couldn't set %s pcap snaplen", iface); > + return -1; > + } > + > + if (pcap_set_promisc(p, RTE_ETH_PCAP_PROMISC) < 0) { > + PMD_LOG(ERR, "Couldn't set %s pcap promisc", iface); > + return -1; > + } > + > + if (pcap_set_timeout(p, RTE_ETH_PCAP_TIMEOUT) < 0) { > + PMD_LOG(ERR, "Couldn't set %s pcap timeout", iface); > + return -1; > + } > + > + if (pcap_set_buffer_size(p, buf_size) < 0) { > + PMD_LOG(ERR, "Couldn't set %s pcap buffer size(%d)", iface, buf_size); > + return -1; > + } > + > + if (pcap_activate(p) < 0) { > + PMD_LOG(ERR, "Couldn't activate %s pcap", iface); > + return -1; > + } > + > + *pcap = p; > } > > return 0; > @@ -608,7 +647,7 @@ eth_dev_start(struct rte_eth_dev *dev) > > if (!pp->tx_pcap[0] && > strcmp(tx->type, ETH_PCAP_IFACE_ARG) == 0) { > - if (open_single_iface(tx->name, &pp->tx_pcap[0]) < 0) > + if (open_single_iface(tx->name, pp->buf_size, &pp->tx_pcap[0]) < 0) > return -1; > pp->rx_pcap[0] = pp->tx_pcap[0]; > } > @@ -627,7 +666,7 @@ eth_dev_start(struct rte_eth_dev *dev) > return -1; > } else if (!pp->tx_pcap[i] && > strcmp(tx->type, ETH_PCAP_TX_IFACE_ARG) == 0) { > - if (open_single_iface(tx->name, &pp->tx_pcap[i]) < 0) > + if (open_single_iface(tx->name, pp->buf_size, &pp->tx_pcap[i]) < 0) This is when the argument is 'tx_iface=eth0', why we are still passing the buffer size when having an handler for Tx? Is the buffer for both Rx & Tx? Isn't this buffer size parameter only for 'iface=...' argument? > return -1; > } > } > @@ -643,7 +682,7 @@ eth_dev_start(struct rte_eth_dev *dev) > if (open_single_rx_pcap(rx->name, &pp->rx_pcap[i]) < 0) > return -1; > } else if (strcmp(rx->type, ETH_PCAP_RX_IFACE_ARG) == 0) { > - if (open_single_iface(rx->name, &pp->rx_pcap[i]) < 0) > + if (open_single_iface(rx->name, pp->buf_size, &pp->rx_pcap[i]) < 0) > return -1; > } > } > @@ -1072,7 +1111,7 @@ open_rx_tx_iface(const char *key, const char *value, void *extra_args) > struct pmd_devargs *tx = extra_args; > pcap_t *pcap = NULL; > > - if (open_single_iface(iface, &pcap) < 0) > + if (open_single_iface(iface, tx->buf_size, &pcap) < 0) > return -1; > > tx->queue[0].pcap = pcap; > @@ -1104,7 +1143,7 @@ open_iface(const char *key, const char *value, void *extra_args) > struct pmd_devargs *pmd = extra_args; > pcap_t *pcap = NULL; > > - if (open_single_iface(iface, &pcap) < 0) > + if (open_single_iface(iface, pmd->buf_size, &pcap) < 0) > return -1; > if (add_queue(pmd, iface, key, pcap, NULL) < 0) { > pcap_close(pcap); > @@ -1154,6 +1193,15 @@ open_tx_iface(const char *key, const char *value, void *extra_args) > return open_iface(key, value, extra_args); > } > > +static int > +select_buf_size(const char *key __rte_unused, const char *value, > + void *extra_args) > +{ > + if (extra_args) > + *(int *)extra_args = atoi(value); > + return 0; > +} > + > static int > select_phy_mac(const char *key __rte_unused, const char *value, > void *extra_args) > @@ -1413,6 +1461,13 @@ pmd_pcap_probe(struct rte_vdev_device *dev) > return -1; > } > > + if (rte_kvargs_count(kvlist, ETH_PCAP_BUF_SIZE_ARG) == 1) { > + ret = rte_kvargs_process(kvlist, ETH_PCAP_BUF_SIZE_ARG, > + &select_buf_size, &pcaps.buf_size); > + if (ret < 0) > + goto free_kvlist; > + } > + > /* > * If iface argument is passed we open the NICs and use them for > * reading / writing > @@ -1456,6 +1511,7 @@ pmd_pcap_probe(struct rte_vdev_device *dev) > devargs_all.is_tx_iface = > rte_kvargs_count(kvlist, ETH_PCAP_TX_IFACE_ARG) ? 1 : 0; > dumpers.num_of_queue = 0; > + dumpers.buf_size = pcaps.buf_size; > > if (devargs_all.is_rx_pcap) { > /* > @@ -1562,6 +1618,7 @@ pmd_pcap_probe(struct rte_vdev_device *dev) > pp->tx_dumper[i] = dumpers.queue[i].dumper; > pp->tx_pcap[i] = dumpers.queue[i].pcap; > } > + pp->buf_size = pcaps.buf_size; > This is inside the seconday proccess branch, process private seems not updated at all for the primary process. > eth_dev->process_private = pp; > eth_dev->rx_pkt_burst = eth_pcap_rx; > @@ -1618,4 +1675,5 @@ RTE_PMD_REGISTER_PARAM_STRING(net_pcap, > ETH_PCAP_TX_IFACE_ARG "= " > ETH_PCAP_IFACE_ARG "= " > ETH_PCAP_PHY_MAC_ARG "=" > - ETH_PCAP_INFINITE_RX_ARG "=<0|1>"); > + ETH_PCAP_INFINITE_RX_ARG "=<0|1>" > + ETH_PCAP_BUF_SIZE_ARG "="); >