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 <bill.fischo...@linaro.org>
wrote:

> 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
> >
> >
>

Reply via email to