[dpdk-dev] [PATCH v9 6/9] eal: auto detect iova mode
santosh.shukla at caviumnetworks.com
Fri Oct 6 11:11:35 CEST 2017
On Friday 06 October 2017 01:41 PM, Thomas Monjalon wrote:
> 06/10/2017 05:25, santosh:
>> On Friday 06 October 2017 05:49 AM, Thomas Monjalon wrote:
>>> 20/09/2017 13:23, Santosh Shukla:
>>>> For auto detection purpose:
>>>> * Below calls moved up in the eal initialization order:
>>>> - eal_option_device_parse
>>>> - rte_bus_scan
>>>> Based on the result of rte_bus_scan_iommu_class - select iova
>>>> mapping mode.
>>> It does not explain why you need to move things up.
>> For that one should understand eal_init sequence first.
>> Should know about _option_device_parse and rte_bus_scan() dependency.
>> After that bus_scan is a need for _get_iommu_class() of api to know that
>> - kdrv is igb/uio/vfio etc.. That's why. Refer work history.
>> Again V9 series happened not for fun. I diagress on your comment.
> This is the basics of writing a commit log.
> You have to explain why things are done.
> You move things because of dependencies without explaining them.
Agree, But if reader does reading from 0..5, by then he could understand
" auto detection purpose" reasoning.
Anyways, I'll add more context in patch summary in v10...sending..
> And I'm pretty sure this move will cause big troubles.
> For instance, have you tried shared library mode?
Its builds, also testpmd works.
> One more comment, you are considering only devices scanned at initialization.
> What happens when a new device is plugged in?
in vfio mode: if PMDs(for that device) flag set to IOVA_AS_VA flag then newly
bound device will have iova=_va mapping mode.
Or else iova=_pa.
> I can push it as is, given there are some Reviewed-by and Tested-by.
> I am trying to avoid you a revert of this patch when one will discover
> some major bugs.
> But I wonder whether it's worth given how you welcome it.
More information about the dev