From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id D01A5A04C2; Mon, 25 Nov 2019 13:03:55 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C8E082952; Mon, 25 Nov 2019 13:03:54 +0100 (CET) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id B3EE028EE for ; Mon, 25 Nov 2019 13:03:52 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Nov 2019 04:03:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,241,1571727600"; d="scan'208";a="206120741" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.96]) ([10.237.221.96]) by fmsmga008.fm.intel.com with ESMTP; 25 Nov 2019 04:03:45 -0800 To: Thomas Monjalon Cc: david.marchand@redhat.com, ajit.khaparde@broadcom.com, alejandro.lucero@netronome.com, anatoly.burakov@intel.com, beilei.xing@intel.com, bruce.richardson@intel.com, dev@dpdk.org, hyonkim@cisco.com, igor.russkikh@aquantia.com, jerinj@marvell.com, jingjing.wu@intel.com, john.mcnamara@intel.com, johndale@cisco.com, kirankumark@marvell.com, konstantin.ananyev@intel.com, marko.kovacevic@intel.com, matan@mellanox.com, ndabilpuram@marvell.com, pavel.belous@aquantia.com, qi.z.zhang@intel.com, qiming.yang@intel.com, rmody@marvell.com, shahafs@mellanox.com, shshaikh@marvell.com, somnath.kotur@broadcom.com, viacheslavo@mellanox.com, wenzhuo.lu@intel.com, xiao.w.wang@intel.com, yskoh@mellanox.com References: <1563800213-29839-3-git-send-email-david.marchand@redhat.com> <20191125093313.61700-1-ferruh.yigit@intel.com> <9486799.kn5VEkfAUu@xps> From: Ferruh Yigit Message-ID: <7d735fc8-a80c-3517-8d8e-8eced554d13f@intel.com> Date: Mon, 25 Nov 2019 12:03:44 +0000 MIME-Version: 1.0 In-Reply-To: <9486799.kn5VEkfAUu@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v4 2/4] eal: fix IOVA mode selection as VA for PCI drivers 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" On 11/25/2019 10:22 AM, Thomas Monjalon wrote: > 25/11/2019 10:33, Ferruh Yigit: >> It looks like DPDK application initialized as IOVA=VA, >> and the new device is bound to 'igb_uio' which forces it to PA, >> fails on above check. > > Do you mean this use case was not tested earlier with DPDK 19.08? Perhaps, just a guess, this can be side affect of only using LTS. > > >> I would like to get your comment on the issue. >> >> For the OvS mode, hopefully binding the device to 'vfio-pci' >> can be a solution, but for the cases we don't have that option, >> can/should we force the DPDK to PA mode after initialization? > > I think this is expected, because VA is the new default since 19.08: > http://doc.dpdk.org/guides/rel_notes/release_19_08.html#new-features > > In case, there is no constraint on initialization, > we have to decide which mode is preferred. > Previously PA was preferred. > For the sake of modernity (and because it fits with some new devices), > the preference has been changed to VA. > > If igb_uio device is used at initialization, > the PA mode should be used. > If igb_uio (PA-only) device is hotplugged, no luck! > If VA-only device is hotplugged, it works! > > I think this change is one step in deprecating igb_uio. > I just want to confirm/clarify that this behavior change is by design, not a defect. Should we document this behavior change more clearly, or highlight more, to not let catch others too?