[dpdk-dev] [PATCH v3 4/6] eal/memory: rename memory API to iova types

Thomas Monjalon thomas at monjalon.net
Fri Nov 3 12:11:47 CET 2017


20/10/2017 14:31, Santosh Shukla:
> Renamed memory translational api to _iova types.
> The following api renamed from:
> 
> rte_mempool_populate_phys()
> rte_mempool_populate_phys_tab()

These functions still have "physical addresses" in their description.
It is not consistent.

Please provide ABI compatibility for mempool functions.

> rte_eal_using_phys_addrs()

Why renaming rte_eal_using_phys_addrs?
I think we need to review how it is used.
Maybe it requires a rework.

> rte_mem_virt2phy()
> rte_dump_physmem_layout()
> rte_eal_get_physmem_layout()
> rte_eal_get_physmem_size()

Those 3 functions deal with physical memory layout.
I don't see a need to rename them.

But the dump function needs a change to avoid printing
"phys" even in VA case.

> rte_malloc_virt2phy()
> rte_mem_phy2mch()

This last function was removed with Xen.
It is wrong to rename it in the release notes.
It should just be removed from the map file (I will send a patch).

> To the following iova types api:
> 
> rte_mempool_populate_iova()
> rte_mempool_populate_iova_tab()
> rte_eal_using_iova_addrs()
> rte_mem_virt2iova()
[...]
> rte_malloc_virt2iova()

I am not convinced by the names virt2iova.
I sounds like "virt to virt".
What about "virt2io" or "virt2io_addr"?

As the ABI is broken in EAL 17.11, we do not care about compatibility.
But we must keep an alias to the old function name in order to allow
a smooth API transition for applications.
I suggest to add static inline functions with the old names and set
the deprecated attribute.


More information about the dev mailing list