From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Subject: Re: [PATCH v8 2/9] eal/pci: get iommu class
Date: Wed, 20 Sep 2017 10:09:31 +0100
Message-ID: <80e535d6-f412-347e-99a9-9fb2f805551d@intel.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
To: santosh <santosh.shukla@caviumnetworks.com>, dev@dpdk.org
Return-path: <dev-bounces@dpdk.org>
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
 by dpdk.org (Postfix) with ESMTP id F42309FE
 for <dev@dpdk.org>; Wed, 20 Sep 2017 11:09:34 +0200 (CEST)
In-Reply-To: <345a32cc-7a22-ea86-78f9-131404a2642b@caviumnetworks.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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 <santosh.shukla at caviumnetworks.com>
>>> Signed-off-by: Jerin Jacob <jerin.jacob at caviumnetworks.com>
>>> Reviewed-by: Maxime Coquelin <maxime.coquelin at redhat.com>
>>> ---
>>
>> 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