From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id F42309FE for ; Wed, 20 Sep 2017 11:09:34 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2017 02:09:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,420,1500966000"; d="scan'208";a="1174075837" Received: from aburakov-mobl2.ger.corp.intel.com (HELO [10.237.210.143]) ([10.237.210.143]) by orsmga001.jf.intel.com with ESMTP; 20 Sep 2017 02:09:32 -0700 To: santosh , dev@dpdk.org References: <20170831032618.7120-1-santosh.shukla@caviumnetworks.com> <20170918104234.9149-1-santosh.shukla@caviumnetworks.com> <20170918104234.9149-3-santosh.shukla@caviumnetworks.com> <92424c77-29d5-4e4e-7f53-22c015d24fb3@intel.com> <345a32cc-7a22-ea86-78f9-131404a2642b@caviumnetworks.com> From: "Burakov, Anatoly" Message-ID: <80e535d6-f412-347e-99a9-9fb2f805551d@intel.com> Date: Wed, 20 Sep 2017 10:09:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <345a32cc-7a22-ea86-78f9-131404a2642b@caviumnetworks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v8 2/9] eal/pci: get iommu class 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: , X-List-Received-Date: Wed, 20 Sep 2017 09:09:35 -0000 Hi Santosh, On 19-Sep-17 6:29 PM, santosh wrote: > Hi Anatoly, > > > On Tuesday 19 September 2017 10:07 PM, Burakov, Anatoly wrote: >> On 18-Sep-17 11:42 AM, Santosh Shukla wrote: >>> Introducing rte_pci_get_iommu_class API which helps to get iommu class >>> of PCI device on the bus and returns preferred iova mapping mode for >>> PCI bus. >>> >>> Patch also add rte_pci_get_iommu_class definition for bsdapp, >>> in bsdapp case - api returns default iova mode. >>> >>> Signed-off-by: Santosh Shukla >>> Signed-off-by: Jerin Jacob >>> Reviewed-by: Maxime Coquelin >>> --- >> >> Hi Santosh, >> >> You have probably missed my comment on previous version of this patch, but for commit history reasons i really think you should add a linuxapp stub in this commit as well as a FreeBSD stub, even though you are adding a linuxapp function in the next commit. Any linuxapp application using that function will fail to compile with this commit, despite this API being already present and declared as public. >> > First, apologies for not following up on your note: > > I prefer to keep less context in each patch and > for [03/9], its already has _IOVA_AS_VA flag + whole autodetection > algo inside (squashed per Aron suggestion). > > Now if I squash [2/9] into [3/9], then would be too much info > for future reader to digest for (imo). Its a kind of trade-off. > > On any linuxapp appl breaking with this commit: > This series exposes eal api for application to use and identify iova mode. > > If you still feel not convinced with my explanation then I'll spin v9 and squash > [02/09], [03/09] in v9. No, i don't mean squashing these two patches into one. I mean, provide a stub like for FreeBSD, and then edit it to be a proper implementation in the next commit. I.e. in this commit, add a stub that just returns 0, like for FreeBSD. Next commit, instead of starting from scratch, start from this stub. Thanks, Anatoly > > Thanks. > > > -- Thanks, Anatoly