Is this an ODP application question or an ODP implementation question? Physical memory addresses are not and have never been part of the ODP API. Most applications will not use odp_shm_reserve() directly but rather get memory allocated automatically as part of calls to odp_buffer_pool_create(). In this case the memory in the buffer pool by default will be globally addressable across the application and any ODP APIs it calls. The flags argument to odp_shm_reserve() is there more for future use than anything else. The only flag which currently has any effect in linux-generic is ODP_SHM_PROC, which asks that the name of the shared memory segment be added to /dev/shm.
>From an implementation perspective, all addresses provided to ODP APIs are virtual addresses. If the implementation requires physical addresses then it is up to the implementation to provide them, since the manner in which such translations might be done is platform-specific. The phys_addr[] fields in the odp_buffer_hdr_t (which is a linux-generic internal structure and not part of the ODP API) was there initially as it was thought that linux-generic might need these and the intent was this was a place they could be cached internally on a per-buffer basis. However, it turned out that these were not needed in linux-generic and hence this field (and others) were removed from odp_buffer_hdr_t as part of the v0.5 restructure of the buffer manager internals. The intent is that implementations will define whatever internal structures they need to implement ODP APIs efficiently for their platform. That's one of the reasons why ODP uses abstract types like odp_buffer_t that are defined by the implementation. It's expected that each implementation will define internal data structures and types that support the ODP APIs in a manner appropriate to its platform. If your platform requires the use of physical addresses, then you'd manage them internally as needed in such structures. Does that answer your questions? On Sun, Jan 18, 2015 at 7:07 AM, Mrityunjay Kumar < [email protected]> wrote: > > I want to allocate memory by the ODP API, which will also seen by the > hardware. As per my understanding address actually seen by the memory > hardware is a physical address. Is there any way to find out the physical > address? Might be there is a way to do but I am not able to figure it out. > > Regards > > ________________________________________ > From: Taras Kondratiuk <[email protected]> > Sent: Sunday, January 18, 2015 4:40 PM > To: Mrityunjay Kumar; [email protected]; [email protected] > Subject: Re: [lng-odp] Regarding reserve memory where both SW + HW can > access. > > On 01/18/2015 11:08 AM, Mrityunjay Kumar wrote: > > Hi > > > > I want to reserve memory where both SW + HW can be access. I have > > explore the code ODP v0.7. I come to know that we have only two flags: > > > > /* Share level */ > > #define ODP_SHM_SW_ONLY 0x1 /**< Application SW only, no HW access */ > > #define ODP_SHM_PROC 0x2 /**< Share with external processes */ > > > > I come across the ODP v0.7 directly from ODP v0.2. I have seen that in > > ODP v0.2; we have option to store physical memory in odp_buffer_hdr_t; > > but in latest release (ODP v0.7) option to store physical memory has > > been removed. if some body point me if there is any option to map > > between virtual to physical memory? > > > > odp_shm_create takes a flag argument which has two values 1. > > ODP_SHM_SW_ONLY and 2. ODP_SHM_PROC, but odp_pktio uses 0. could we also > > explicitly extend this flag list to work across platforms? > > Sorry I didn't get what is the issue. Could you please clarify your > intent? > > ODP_SHM_SW_ONLY is an optimization flag which should be set only if a > caller is sure that memory won't be used by HW (not passed into any ODP > API). If ODP_SHM_SW_ONLY is not set, implementation should expect it to > be used by HW and should act accordingly. > > -- > Taras Kondratiuk > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or used > for any purpose other than for what it is intended. If you have received > this message in error, please notify the originator immediately. If you are > not the intended recipient, you are notified that you are strictly > prohibited from using, copying, altering, or disclosing the contents of > this message. Aricent accepts no responsibility for loss or damage arising > from the use of the information transmitted by this email including damage > from virus." > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
