On Fri, May 26, 2017 at 6:17 AM, Savolainen, Petri (Nokia - FI/Espoo) <[email protected]> wrote: > > >> -----Original Message----- >> From: Bill Fischofer [mailto:[email protected]] >> Sent: Wednesday, May 24, 2017 6:30 PM >> To: Savolainen, Petri (Nokia - FI/Espoo) <[email protected]> >> Cc: Sachin Saxena <[email protected]>; [email protected] >> 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);
The fundamental issue is not what ODP APIs we use but that VPP needs to change to use APIs to do this conversion rather than assume that it can just do math on packet "handles" directly, as it does today. As an aside, for the reverse mapping if we don't pass the pool as an argument then implementations need to encode this information in the generated index, similar to the way odp-linux used to do. That effectively limits the number of packets/pools that can participate in this scheme and we'd need to verify that that assumption is OK for VPP's use case. > > > 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 > > > >
