Hi, 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.
Liron 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 <lng-odp@lists.linaro.org> 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: Hi, 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 platforms. 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. Liron From: Bill Fischofer <bill.fischo...@linaro.org<mailto:bill.fischo...@linaro.org>> 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 <lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>> 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? Thanks. BTW, The above approach is what DPDK offer with its EAL infrastructure. Thanks, Liron From: Bill Fischofer <bill.fischo...@linaro.org<mailto:bill.fischo...@linaro.org>> Sent: Monday, October 22, 2018 17:47 To: Elo, Matias (Nokia - FI/Espoo) <matias....@nokia.com<mailto:matias....@nokia.com>> Cc: Liron Himi <lir...@marvell.com<mailto:lir...@marvell.com>>; lng-odp-forward <lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>> 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? Thanks. Regards, Bill 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 packet. 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 hugepages. 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. Regards, Matias
