> -----Original Message----- > From: Bill Fischofer [mailto:bill.fischo...@linaro.org] > Sent: Wednesday, May 24, 2017 6:30 PM > To: Savolainen, Petri (Nokia - FI/Espoo) <petri.savolai...@nokia.com> > Cc: Sachin Saxena <sachin.sax...@linaro.org>; lng-odp@lists.linaro.org > Subject: Re: [lng-odp] APIs for dealing with compact handles > > Given the assumptions that VPP makes on packet / pool organization, > perhaps another approach would be to add a request bit to the > odp_pool_param_t struct to request that this pool support linear > organization. > Something like: > > typedef struct odp_pool_param_t { > /** Pool type */ > int type; > > union { > uint32_t all_bits; > > struct { > uint32_t linear:1; > }; > } opts; > > /** Variant parameters for different pool types */ > union { > ... > }; > } odp_pool_param_t; > > Setting param.opts.linear would request that this pool be organized > such that applications like VPP can do the math it's currently doing? > We could also provide "official" APIs to create/expand compact handles > and encourage apps to make use of those since not every implementation > may be able to offer linear pools. Specifying the linear option on > such an implementation would result in the odp_pool_create() call > failing.
This is too specific requirement for how to implementation a pool. As I said before, the first option is to not change anything. VPP stores odp_packet_t directly and uses odp_packet_user_area(pkt) to get into VPP specific struct. Another option is to say that an ODP implementation does not always know which is optimal packet handle size, and thus introduce packet_handle_to_u32 and packet_u32_to_handle conversion functions for applications. So, VPP would do buf_index[i] = odp_packet_handle_to_u32(pkt) ... pkt = odp_packet_u32_to_handle(buf_index[i]); VPP_struct = odp_packet_user_area(pkt); There are also other options, like VPP maintaining per packet context and store handles/VPP pointer there. buffer_index[i] = get_buffer_index(); packet_ctx[buffer_index[i]].pkt = pkt; packet_ctx[buffer_index[i]].VPP_struct = odp_packet_user_area(pkt); ... VPP_struct = packet_ctx[buffer_index[i]].VPP_struct; So, there's no need to quarantee single linear memory region for a pool. A pool may be e.g. constructed (and dynamically extended with) multiple pieces of memory, etc. If application needs a contiguous piece of memory, it should use SHM API - not pool API. -Petri
