From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5AC6643881; Wed, 10 Jan 2024 11:22:17 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 13CFF4068A; Wed, 10 Jan 2024 11:22:12 +0100 (CET) Received: from smtp-gw.pt.net (smtp-gw.pt.net [206.210.192.15]) by mails.dpdk.org (Postfix) with ESMTP id 24BB24013F for <dev@dpdk.org>; Tue, 9 Jan 2024 16:21:49 +0100 (CET) X-ASG-Debug-ID: 1704813708-09411a10bb230f4a0001-TfluYd Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id LtGcLDt0DLPQqKiR (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 09 Jan 2024 09:21:48 -0600 (CST) X-Barracuda-Envelope-From: lew@perftech.com X-Barracuda-Effective-Source-IP: mail.pt.net[206.210.194.11] X-Barracuda-Apparent-Source-IP: 206.210.194.11 Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 754701B1B70E; Tue, 9 Jan 2024 09:21:48 -0600 (CST) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavis, port 10032) with ESMTP id PECdg6wi9Gab; Tue, 9 Jan 2024 09:21:48 -0600 (CST) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 1D5331B1B783; Tue, 9 Jan 2024 09:21:48 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.pt.net 1D5331B1B783 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perftech.com; s=B15A3A56-ABEA-11EE-9719-5F12F125680F; t=1704813708; bh=vBCY5nZlOQbRYYXkoJzWkjkjfvuoUH8Y1/MPDcOMRxQ=; h=Date:From:To:Message-ID:MIME-Version; b=bjWC+5dCZxc4296dSgoPW9esq761wAm3C586tNxD9DOPvyoGbbN28J/k9gN6zlxys kRcE7zDwT3Cp59Z32jEj8ytHbFpRDZikE5CBwHIQOypdDZlWbUplkUYbVBVo7/lrFL q6i5DA8WGaaFGLs0I9PfOKZw8B0ddBIrjlDqEnhSckGq+RxNvgThudRyS6/AloXyzX 9YkIDmJUAauI8lypSG6/5Cy6dctTvhVTcHGXJv5ErrcIykZWVgRVJD2pbckCbU/xga NZS4WrmwFFd1rbk5Jai1HmEKFPHmZPlRklqiQCAmq/xcz5Yj6WlE+XFWZvGS5zdcjR RfRhHcHka+8vw== X-Virus-Scanned: amavis at pt.net Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavis, port 10026) with ESMTP id S0zUfMmVwRxV; Tue, 9 Jan 2024 09:21:48 -0600 (CST) Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by mail.pt.net (Postfix) with ESMTP id 0EB1E1B1B70C; Tue, 9 Jan 2024 09:21:48 -0600 (CST) Date: Tue, 9 Jan 2024 09:21:47 -0600 (CST) From: Lewis Donzis <lew@perftech.com> To: Bruce Richardson <bruce.richardson@intel.com> Cc: dev <dev@dpdk.org> Message-ID: <519672326.1276848.1704813707871.JavaMail.zimbra@donzis.com> In-Reply-To: <ZZ1X_CsHnlK2vJ5C@bricha3-MOBL.ger.corp.intel.com> References: <2134779104.413217.1638218715124.JavaMail.zimbra@donzis.com> <Ya3VCYKcuX5v9FCT@bricha3-MOBL.ger.corp.intel.com> <DM6PR11MB4491AD0722B029C4E8E117959A6D9@DM6PR11MB4491.namprd11.prod.outlook.com> <1796133353.5470017.1654262374494.JavaMail.zimbra@donzis.com> <12922153.12944.1704552603431.JavaMail.zimbra@donzis.com> <ZZ0eENQ96wcFsnN6@bricha3-MOBL.ger.corp.intel.com> <1182416671.1246287.1704808007894.JavaMail.zimbra@donzis.com> <ZZ1X_CsHnlK2vJ5C@bricha3-MOBL.ger.corp.intel.com> Subject: Re: vmxnet3 no longer functional on DPDK 21.11 MIME-Version: 1.0 X-ASG-Orig-Subj: Re: vmxnet3 no longer functional on DPDK 21.11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: [206.210.194.11] X-Mailer: Zimbra 8.8.15_GA_4581 (ZimbraWebClient - GC120 (Mac)/8.8.15_GA_4581) Thread-Topic: vmxnet3 no longer functional on DPDK 21.11 Thread-Index: tQcqHZn4Zfn1ldNMw8ckVwFn46gN+A== X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1704813708 X-Barracuda-Encrypted: TLS_AES_256_GCM_SHA384 X-Barracuda-URL: https://smtp-gw.pt.net:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at pt.net X-Barracuda-Scan-Msg-Size: 1679 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.119190 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Mailman-Approved-At: Wed, 10 Jan 2024 11:22:09 +0100 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 ----- On Jan 9, 2024, at 8:28 AM, Bruce Richardson bruce.richardson@intel.com wrote: > On Tue, Jan 09, 2024 at 07:46:47AM -0600, Lewis Donzis wrote: >> Hi, Bruce. >> >> I'm even less familiar with it, but we do quite a lot of testing using VMs, so >> it's been quite handy. >> >> Your patch seems very reasonable, however it also produces a warning: >> >> ../drivers/net/vmxnet3/vmxnet3_ethdev.c:264:1: warning: unused function >> 'vmxnet3_enable_all_intrs' [-Wunused-function] >> >> Adding an #ifndef around vmxnet3_enable_all_intrs() eliminates that warning. > > Right, I should have compile-tested on FreeBSD myself, before sending the > suggestion. Patch has now been submitted. Please test and ack if the fix > works for your use-cases, thanks. I compiled it and ran it just now and it appears to work just fine. Thanks very much for submitting. > In general, yes we try and avoid interrupts on the data-path or fast-path > and use polling. However, for some use-cases where traffic levels are low, > interrupts may make sense to save power for fast-path. Even if not, > interrupts are useful for things like error conditions or for monitoring > link-status changes (LSC). Unfortunately, we don't have any interrupt > support on BSD, so fixes like this are necessary. That makes sense. Makes me wonder why there's no interrupt support on BSD, i.e., maybe it's better to fix that than to have to fix "avoiding it" in the drivers? I kind of feel like we're a bit orphaned in the FreeBSD world. I don't know how many others are using BSD, but it seems like we're in a relatively less-supported environment. Thanks again, lew