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?
Liron From: Bill Fischofer <bill.fischo...@linaro.org> Sent: Monday, October 22, 2018 21:32 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 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
