muvarov replied on github web page:
include/odp/api/spec/pool.h
line 16
@@ -172,7 +172,20 @@ int odp_pool_capability(odp_pool_capability_t *capa);
typedef struct odp_pool_param_t {
/** Pool type */
int type;
-
+ /** Flag to indicate whether user is requesting for contiguous
+ memory for buffers or packets in pool.
+ If TRUE, then address range for buffers or packets
+ must be returned by API as addr_start & addr_len.
+ If FALSE, then filling these parameters is optional.
+ */
+ odp_bool_t contig_mem;
+ /** Start of virtual address */
+ union {
+ void *addr_start;
+ uint64_t addr_start_64;
+ };
Comment:
1) is it needed for tmo and bufs also? why it's on only inside packets? 2) How
memory for *start_addr is allocated in VPP? In previous version of
odp_pool_create() was odp_shm_t parameter which said to reuse already created
shm. Maybe that needs to be reconsidered. 3) why union is needed? why it's not
with uintptr_t ?
> Dmitry Eremin-Solenikov(lumag) wrote:
> @Bill-Fischofer-Linaro yes, this looks like a good approach.
> @sachin-saxena could you please reimplement your PR following
> @Bill-Fischofer-Linaro 's suggestion?
>> Dmitry Eremin-Solenikov(lumag) wrote:
>> Got confused between single-segment packet and linear space for packets,
>> sorry.
>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>> Yes the existing `seg_len` parameter is set to the minimum size segment
>>> that the application requires. This can be set to be equal to `max_len` to
>>> require single-segment packets.
>>>
>>> However @sachin-saxena mentioned at SFO17 that VPP can deal with
>>> multi-segment packets, though I'm not sure how that works.
>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>> VPP will not run on such platforms without modification. If the goal is to
>>>> not modify VPP then an `odp_pool_capability()` output that says whether
>>>> pools can present a linear interface. During Connect @psavol also
>>>> mentioned that a separate API to get this info would be more appropriate
>>>> than bending the input to `odp_pool_create()` to give output parameters.
>>>>
>>>> My personal preference would be something like:
>>>>
>>>> * `odp_pool_capability()` indicates whether pools can be created that
>>>> provide linear addressing.
>>>>
>>>> * An option on `odp_pool_create()` to request a linear pool.
>>>>
>>>> * A new API (or an extension to the existing `odp_pool_info()` API) to get
>>>> the mapping info that VPP needs.
>>>>
>>>> That would seem to be more consistent with overall ODP structure.
>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>> What will happen for platforms where `odp_packet_t` is not mapped to the
>>>>> virtual memory?
>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>> Isn't setting `seg_len` enough? Maybe we should provide an updated
>>>>>> definition for `seg_len` (e.g. in case `seg_len > max_len`, always use
>>>>>> single segment).
https://github.com/Linaro/odp/pull/200#discussion_r142627981
updated_at 2017-10-04 09:55:13
