It looks like to get address is not so complex, just read /proc/$pid/pagemap https://stackoverflow.com/questions/5748492/is-there-any-api-for-determining-the-physical-address-from-virtual-address-in-li
But for linux-generic it's not clear why do we need this. Maybe AF_XDP require physical address... One of solution might be empty function in linux-generic which other implementers can use redefine and use it as template. Maxim. On Tue, 23 Oct 2018 at 00:13, Bill Fischofer <[email protected]> wrote: > On Mon, Oct 22, 2018 at 3:17 PM Liron Himi <[email protected]> wrote: > > > 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. > > > > At present linux-generic has no need for such an API so I'm not sure how > we'd define, use, or test one. But if you have a suggestion for what you'd > like to see, feel free to create a PR to add it if that would better > illustrate it. > > > > > > > > Liron > > > > > > > > *From:* Bill Fischofer <[email protected]> > > *Sent:* Monday, October 22, 2018 22:40 > > *To:* Liron Himi <[email protected]> > > *Cc:* Elo, Matias (Nokia - FI/Espoo) <[email protected]>; > > lng-odp-forward <[email protected]> > > *Subject:* Re: [EXT] Re: [lng-odp] Get Physical address > > > > > > > > > > > > On Mon, Oct 22, 2018 at 1:40 PM Liron Himi <[email protected]> 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 <[email protected]> > > *Sent:* Monday, October 22, 2018 21:32 > > *To:* Liron Himi <[email protected]> > > *Cc:* Elo, Matias (Nokia - FI/Espoo) <[email protected]>; > > lng-odp-forward <[email protected]> > > *Subject:* Re: [EXT] Re: [lng-odp] Get Physical address > > > > > > > > > > > > On Mon, Oct 22, 2018 at 12:41 PM Liron Himi <[email protected]> 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 <[email protected]> > > *Sent:* Monday, October 22, 2018 17:47 > > *To:* Elo, Matias (Nokia - FI/Espoo) <[email protected]> > > *Cc:* Liron Himi <[email protected]>; lng-odp-forward < > > [email protected]> > > *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) < > > [email protected]> 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 > > > > >
