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
