From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,URIBL_SBL,URIBL_SBL_A autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3AAC2C76188 for ; Tue, 23 Jul 2019 04:54:24 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id C53342229A for ; Tue, 23 Jul 2019 04:54:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C53342229A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 65EEF1BF55; Tue, 23 Jul 2019 06:54:22 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 6E6141BF27 for ; Tue, 23 Jul 2019 06:54:20 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jul 2019 21:54:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,297,1559545200"; d="scan'208";a="320890234" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga004.jf.intel.com with ESMTP; 22 Jul 2019 21:54:19 -0700 Received: from fmsmsx113.amr.corp.intel.com (10.18.116.7) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 22 Jul 2019 21:54:18 -0700 Received: from lcsmsx154.ger.corp.intel.com (10.186.165.229) by FMSMSX113.amr.corp.intel.com (10.18.116.7) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 22 Jul 2019 21:54:18 -0700 Received: from hasmsx105.ger.corp.intel.com ([169.254.1.231]) by LCSMSX154.ger.corp.intel.com ([169.254.7.32]) with mapi id 14.03.0439.000; Tue, 23 Jul 2019 07:54:15 +0300 From: "Stojaczyk, Dariusz" To: Jerin Jacob Kollanukkaran , Thomas Monjalon , David Marchand , "Burakov, Anatoly" CC: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v4 0/4] Fixes on IOVA mode selection Thread-Index: AQHVQI0FjDxN6cq+2k2hb+hejqdguKbWl6+AgAD1FnD//9tLAIAAMy+g Date: Tue, 23 Jul 2019 04:54:14 +0000 Message-ID: References: <1562795329-16652-1-git-send-email-david.marchand@redhat.com> <1563800213-29839-1-git-send-email-david.marchand@redhat.com> <1735440.496QTsyyT4@xps> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.184.70.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 0/4] Fixes on IOVA mode selection X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" > -----Original Message----- > From: Jerin Jacob Kollanukkaran [mailto:jerinj@marvell.com] > Sent: Tuesday, July 23, 2019 6:19 AM >=20 > > -----Original Message----- > > From: Stojaczyk, Dariusz > > Sent: Tuesday, July 23, 2019 9:06 AM > > To: Thomas Monjalon ; David Marchand > > ; Burakov, Anatoly > > ; Jerin Jacob Kollanukkaran > > > > Cc: dev@dpdk.org > > Subject: [EXT] RE: [dpdk-dev] [PATCH v4 0/4] Fixes on IOVA mode selecti= on > > > > This introduces a regression where uio-bound devies are attached to a > DPDK > > app at runtime. >=20 > Just to understand the requirements; > # Is this requirement for SPDK? > # Is brand new PCI device scanned and attached to DPDK at runtime? > # Any specific reason for using uio vs vfio? Jerin, It came up in SPDK tests, but it's certainly nothing SPDK-specific, I can't give you the steps but it should be reproducible even with testpmd. The PCI device could have been simply hotplugged to the system after DPDK app start. DPDK didn't know about it at initialization, so it picked RTE_IOVA_VA and then would fail to attach any UIO-bound device ever after: EAL: Expecting 'PA' IOVA mode but current mode is 'VA', not initializing EAL: Driver cannot attach the device (0000:00:09.0) EAL: Failed to attach device on primary process UIO is commonly used on systems without IOMMU- including VMs. >=20 > If it is for SPDK, > # How about introducing rte_eal_init_with_mode(enum rte_iova_mode)? > # How about adding dummy bus which returns RTE_IOVA_PA in the > bus_get_iommus_class() in SPDK code base? There's already an --iova=3Dmode option in DPDK that forces the iova mode. I'm not concerned about configurability, but the regression in the default behavior. I can add workarounds to SPDK, sure, but that wouldn't be a very healthy approach. D. >=20 > > > > When there are no devices attached at initialization, the only safe def= ault > > should be RTE_IOVA_PA. With RTE_IOVA_VA we just won't be able to do > > any DMA to uio-bound PCI devices. > > > > Can we revert this patch? > > > > D. > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas > Monjalon > > > Sent: Monday, July 22, 2019 5:53 PM > > > To: David Marchand ; Burakov, Anatoly > > > ; jerinj@marvell.com > > > Cc: dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH v4 0/4] Fixes on IOVA mode selection > > > > > > 22/07/2019 14:56, David Marchand: > > > > Following the issues reported by Jerin and the discussion that > > > > emerged from it, here are fixes to restore and document the behavio= r > > > > of the EAL and the pci bus driver. > > > > > > > > I pondered all the arguments and tried to have the less changes > > > > possible. > > > > I can't find a need for a flag to just announce support of physical > > > > addresses from the pmd point of view. > > > > So it ended up with something really close to what Jerin had sugges= ted. > > > > > > > > But the problem is that this is still unfinished wrt the documentat= ion. > > > > I will be offline for 10 days and we need this to move forward, so > > > > sending anyway. > > > > > > > > Changelog since v3: > > > > - fixed typos in patch 2, > > > > - updated patch 3 title, > > > > - moved and reworded comments in the note section in patch 4, > > > > > > > > Changelog since v2 (Jerin): > > > > - Patch 2/4 - Remove personal appeals in log messages(Anatoly) > > > > - Patch 4/4 - Added documentation (Anatoly) > > > > > > > > Changelog since v1 (Jerin): > > > > - Changed RTE_PCI_DRV_IOVA_AS_VA flag name as > > > RTE_PCI_DRV_NEED_IOVA_AS_VA > > > > (patch 3/4) > > > > - Changed IOVA mode as VA for default case(patch 4/4) with > > > documentation > > > > - Tested the patch series on octeontx2 platform > > > > > > Applied, thanks Jerin, Anatoly and David for converging on a > > > documented solution together. > > > > > >