> On Aug 22, 2018, at 5:19 PM, Yongseok Koh <ys...@mellanox.com> wrote: > > On Tue, Aug 21, 2018 at 12:07:49PM +0200, Alejandro Lucero wrote: >> Hi Yonngseok, >> >> There is a patchset aimed at 17.11.x: >> >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatches.dpdk.org%2Fcover%2F42741%2F&data=02%7C01%7Cyskoh%40mellanox.com%7Cb1b0e3eff71c499ff3fb08d6088e1ede%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636705803846548967&sdata=8f12c1IuUe4mw2EaTZ18vVTuLTjXOD2cSe%2B%2B7f6OFfk%3D&reserved=0 >> >> It was not accepted for master because the memory code has changed a lot >> since 17.11, and I'm working on another patchset for adjusting to the those >> changes. >> >> I wonder if there is any issue with adding this patchset to stable 17.11.4. >> Note that this makes unlikely a known limitation with emulated IOMMU inside >> VMs. > > This patchset seems quite large for stable release and need to be well > verified > before GA. In -rc1 stage, we don't usually take such a large patchset as > people > have already started verification. And we don't usually release -rc2. If > you're > trying to solve a very critical issue with this patchset, I have to release > -rc2 > and ask people to verify again. How critical is your issue?
Looks like you have sent a mail to sta...@dpdk.org in July. http://mails.dpdk.org/archives/stable/2018-July/008589.html I don't know why some of emails to sta...@dpdk.org haven't arrived at my mailbox. I'm still trying to figure out the reason with IT depart in my company and re-subscribed to the mailing list as well. My apologies for that. Yongseok > For the patchset, > - "mem: add function for checking memsegs IOVAs addresses" > This is adding a new API, so I don't expect any API/ABI breakage, but want to > double-confirm with Thomas. Thomas? > > - "bus/pci: use IOVAs check when setting IOVA mode" > All the patches got ack except for this one but from looking at the threads > in > dev mailing list, it looks okay. I have a question though. > >> @@ -640,13 +643,17 @@ >> { >> struct rte_pci_device *dev = NULL; >> struct rte_pci_driver *drv = NULL; >> + int iommu_dma_mask_check_done = 0; >> >> FOREACH_DRIVER_ON_PCIBUS(drv) { >> FOREACH_DEVICE_ON_PCIBUS(dev) { >> if (!rte_pci_match(drv, dev)) >> continue; >> - if (!pci_one_device_iommu_support_va(dev)) >> - return false; >> + if (!iommu_dma_mask_check_done) { >> + if (pci_one_device_iommu_support_va(dev) < 0) > > pci_one_device_iommu_support_va() returns true/false(1/0), then why do you > expect to see a negative return value in case of failure? > >> + return false; >> + iommu_dma_mask_check_done = 1; >> + } >> } >> } >> return true;
