On Mon, Oct 22, 2018 at 3:17 PM Liron Himi <lir...@marvell.com> 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 <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> 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> > *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> 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> > *Sent:* Monday, October 22, 2018 17:47 > *To:* Elo, Matias (Nokia - FI/Espoo) <matias....@nokia.com> > *Cc:* Liron Himi <lir...@marvell.com>; lng-odp-forward < > 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> 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 > >
