I was not looking for a "standardized" set of internal API.
I want to use the linux-generic implementation of odp-shared-memory, and just 
request for additional linux-generic internal API to retrieve the physical 
address of the buffer.
Those internal APIs can be part of either of the odp_ishm<x>_internal.h files.


From: Bill Fischofer <bill.fischo...@linaro.org>
Sent: Monday, October 22, 2018 22:40
To: Liron Himi <lir...@marvell.com>
Cc: Elo, Matias (Nokia - FI/Espoo) <matias....@nokia.com>; lng-odp-forward 
Subject: Re: [EXT] Re: [lng-odp] Get Physical address

On Mon, Oct 22, 2018 at 1:40 PM Liron Himi 
<lir...@marvell.com<mailto:lir...@marvell.com>> wrote:

It is for implementing ODP itself on our platform. So yes, we need internal 
APIs to get physical address.
Do you have plans to add such internal APIs?

We do not have a "standardized" set of internal APIs because these would be 
very platform specific and hence not readily portable to other platforms. ODP 
has been focused on defining an external API set that address application needs 
and can be in turn implemented efficiently across a range of different platform 
architectures. This is the main reason why ODP makes use of abstract data types 
so that each platform can define what these mean in a manner that closely 
matches their own native data types and organizational model without impacting 
application portability.

One of the key design strategies behind ODP is not to define an implementation 
model to preserve maximum flexibility on the part of implementations to achieve 
native-level performance in a portable manner. This is what enables easy 
realization of different ODP APIs in HW, SW, or any combination of HW and SW as 
the implementation chooses.

My suggestion would be that you define these abstract types in terms that are 
native to your platform so that any "translation" needed can be done under the 
covers with casts or similar minimal-cost constructs. That's the model used in 
the reference implementation and has been successfully adopted by other 

If you'd like to discuss specifics we can do that during the weekly ODP public 
call (15:00 UTC every Tuesday). Feel free to join us for tomorrow's call or 
whenever else is convenient.


From: Bill Fischofer 
Sent: Monday, October 22, 2018 21:32
To: Liron Himi <lir...@marvell.com<mailto:lir...@marvell.com>>
Cc: Elo, Matias (Nokia - FI/Espoo) 
<matias....@nokia.com<mailto:matias....@nokia.com>>; lng-odp-forward 
Subject: Re: [EXT] Re: [lng-odp] Get Physical address

On Mon, Oct 22, 2018 at 12:41 PM Liron Himi 
<lir...@marvell.com<mailto:lir...@marvell.com>> wrote:
Hi Bill,

We would like to use the linux-generic’s memory management especially with the 
huge-pages support.
This way we can refer to the above as a “infrastructure service” for memory 
management. And we only need to get the physical address of the buffers and 
pass them to our HW pools.
Having this support provide us the ability to move to future versions with the 
need to modify the platform memory management and support new APIs.

Is this for applications or for implementing ODP itself on your platform? ODP 
implementations will typically use ODP APIs internally for many common needs 
and augment them with internal APIs. The ODP reference implementation we supply 
has many such internal APIs that are typically prefixed with _odp_xxx() to 
distinguish them from external APIs that use the odp_xxx() form. If your 
internal memory management has a need for the concept of physical addresses 
then you could certainly follow this pattern.

The criteria for adding new ODP APIs is twofold: To address the functional 
needs of ODP applications, and to enable platforms implementing ODP to expose 
acceleration functions to applications efficiently in a platform-neutral 
manner. Do you have an application use case for wanting physical addresses, and 
if so can you elaborate on how you'd expect applications to use them?


BTW, The above approach is what DPDK offer with its EAL infrastructure.


From: Bill Fischofer 
Sent: Monday, October 22, 2018 17:47
To: Elo, Matias (Nokia - FI/Espoo) 
Cc: Liron Himi <lir...@marvell.com<mailto:lir...@marvell.com>>; lng-odp-forward 
Subject: [EXT] Re: [lng-odp] Get Physical address

External Email
Hi Liron,

Sorry for the delay in responding as I was vacationing last week. As Matias 
noted, ODP does not have APIs for dealing with physical addresses, since the 
concept of a physical address tends to be very platform-specific and not 
universally shared. ODP refers to packet objects symbolically (odp_packet_t 
type) and has APIs to provide application addressability to packet segments 
when needed. I'd be interested in understanding the use case for wanting such 
an API, however. How would you see these being used?



On Mon, Oct 15, 2018 at 1:40 AM Elo, Matias (Nokia - FI/Espoo) 
<matias....@nokia.com<mailto:matias....@nokia.com>> wrote:
Hi Liron,

Is there an external or internal API to retrieve the physical address of a 

At least for now we haven’t seen a use case for such a function.

I would like to use the linux-generic memory management implementation with 
In DPDK there is :
* A macro that returns the IO address that points to the start of the
* data in the mbuf
#define rte_pktmbuf_iova(m)

rte_pktmbuf_iova() macro returns an address based on predefined iova pointer + 
offset. The function for doing the actual virt to phy conversion is 
rte_mem_virt2iova() (or rte_mem_virt2phy()). At a quick glance this function 
seems quite generic and you could potentially port it to your code.


Reply via email to