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 EC85443891; Thu, 11 Jan 2024 10:12:48 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B42504025E; Thu, 11 Jan 2024 10:12:48 +0100 (CET) Received: from smtp-gw.pt.net (smtp-gw.pt.net [206.210.192.15]) by mails.dpdk.org (Postfix) with ESMTP id 0B5F74025E for <dev@dpdk.org>; Wed, 10 Jan 2024 14:36:09 +0100 (CET) X-ASG-Debug-ID: 1704893764-09411a10bb236d9c0001-TfluYd Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by smtp-gw.pt.net with ESMTP id fhzFn2K05lJtcNoS (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 10 Jan 2024 07:36:04 -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 BDA531B9830D; Wed, 10 Jan 2024 07:36:04 -0600 (CST) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavis, port 10032) with ESMTP id jYNUOO1E-iaO; Wed, 10 Jan 2024 07:36:04 -0600 (CST) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 0265D1B98252; Wed, 10 Jan 2024 07:36:04 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.pt.net 0265D1B98252 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perftech.com; s=B15A3A56-ABEA-11EE-9719-5F12F125680F; t=1704893764; bh=aPM7zML+3CXP+qv2YAwpXXPP3N/taqpCsS6PT01nHJw=; h=Date:From:To:Message-ID:MIME-Version; b=lHP23MnLKrvmmSpbDiDGn2XOrUz2DD/uYZko0qmm5clk5dexuj9Jd/K7X5FleRZ3Q oMZLrj/pUUvCWlZ/VLDkEm8sXJcvIlpSfFvoO+1PBmED59mPfwjOWhLra5PepOmj5o 616sbj75xD9OiW1bvDN8qf2mLU9l/H6XCnWvTt92lf4k4preAUMvbtPQBHyiAQ+uSQ hUhi0IkPz5Jy4Kw0pvBgbbPrno8RK4uI67fC6Gw8LJJY2tmxlaFQaYORWiQfrzR9+e ObHlo9QeragWTfQ1+VXmXjGUN+R/i4XnaBwP+kzfe+PVamyEW0dblCKiW+cEh0qVRs Bc7/gvQtUIxHQ== 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 cqLaqDyRLI24; Wed, 10 Jan 2024 07:36:03 -0600 (CST) Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by mail.pt.net (Postfix) with ESMTP id D9EE31B982A2; Wed, 10 Jan 2024 07:36:03 -0600 (CST) Date: Wed, 10 Jan 2024 07:36:02 -0600 (CST) From: Lewis Donzis <lew@perftech.com> To: Stephen Hemminger <stephen@networkplumber.org> Cc: Bruce Richardson <bruce.richardson@intel.com>, Konstantin Ananyev <konstantin.ananyev@intel.com>, dev <dev@dpdk.org>, "Wang, Yong" <yongwang@vmware.com> Message-ID: <1440015893.2126132.1704893762303.JavaMail.zimbra@donzis.com> In-Reply-To: <20240109155527.7eed113e@hermes.local> References: <2134779104.413217.1638218715124.JavaMail.zimbra@donzis.com> <1909271468.2730688.1638755553311.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> <20240109155527.7eed113e@hermes.local> 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: QAix+7W6ijKMLvasqPqy/aipJ55FoA== X-Barracuda-Connect: mail.pt.net[206.210.194.11] X-Barracuda-Start-Time: 1704893764 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: 1479 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.119231 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Mailman-Approved-At: Thu, 11 Jan 2024 10:12:47 +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 5:55 PM, Stephen Hemminger stephen@networkplumber.org wrote: > Probably need to go further with this. > - what about unreigster in vmxnet3_dev_stop > - vmxnet3_interrupt_handler is then dead code, should it be #ifdef guarded? > - and vmxnet3_dev_rx_queue_intr_enable/disable > - and vmxnet3_enable_intr > - and vmxnet3_configure_msix > - and checks for rte_eth_intr_conf bits? in configure I wondered the same thing, but checking other drivers, there appears to be little provision for this. Just as an example, ixgbe has a FREEBSD ifdef, but it doesn't bother with trying to avoid all interrupt code. And hardly any other network drivers have FREEBSD ifdefs at all and just ignore errors from registering interrupt callbacks. In addition, the FreeBSD EAL interrupt code appears to have stubs that return "false" for calls that question whether interrupts are enabled, e.g., rte_intr_dp_is_en(), or an error for calls that attempt to use interrupts. It's interesting that it works as well as it does because most drivers appear to be enabling interrupts in the NIC hardware. But if the interrupt remains masked in the APIC due to lack of support in freebsd/eal_interrupts.c, then perhaps it doesn't matter? So while your suggestions seem quite well-founded, I don't see any equivalent provision in any other driver. Apparently there is no harm in attempting to use interrupts on FreeBSD since they will never trigger anyway?