I would like to get application use-case for different scenarios where this would be useful before finalizing "pool groups" and their API signature. Also in the above proposal it is not possible to combine multiple pools to form a pool group, I like this idea as it gives freedom for implementation to allocate and optimize the individual pools.
Regards, Bala On 6 April 2015 at 22:11, Bill Fischofer <[email protected]> wrote: > I would call these "pool groups" for symmetry with "queue groups" and so the > API would be odp_pool_create_group(), odp_pool_destroy_group(), etc. > > On Mon, Apr 6, 2015 at 11:35 AM, Taras Kondratiuk > <[email protected]> wrote: >> >> On 04/06/2015 03:31 PM, Bill Fischofer wrote: >> > The /expression/ may be linear, but that doesn't imply that is how any >> > given implementation needs to realize the expression. Since PMRs are >> > reasonably static, I'd expect them to be "compiled" into whatever native >> > classification capabilities are present in the platform. Real >> > classification is typically done in parallel by the HW as the packet is >> > coming "off the wire". This is necessary because one of the outputs of >> > classification is pool selection, so all of this happens while the >> > packet is in the HW's receive FIFO before the DMA engines are told where >> > to store it. >> >> Following our discussion on a call. >> >> Choosing a pool on ingress solves two separate issues: >> 1. Isolation - packets that belong to different CoS'es may need to use >> separate packet pools. Pool choice is strictly deterministic. >> This case is covered by current API. >> 2. Segmentation optimization - application may want to sort packets of >> different size into pools with different segment size. In this case >> pool choice is not very strict. For example a small packet can be >> allocated from a pool with big segments if small-segment pool is >> empty. This case can't be expressed with a current API. >> >> Assigning several pools to CoS and allowing implementation to pick an >> optimal pool would be one option to solve #2. >> During a meeting Maxim proposed to use a 'composite' pool instead, and >> I like this idea more. I imagine something like this: >> >> /** >> * Create a composite pool >> * >> * This routine is used to create a pool which logically consists of >> * a set of sub-pools. Each sub-pool has its own configuration >> * parameters. Only pool of ODP_POOL_PACKET type can be created. >> * On allocation an implementation will choose an optimal sub-pool to >> * allocate a packet from. >> * A composite pool can be used to optimize memory usage and minimize >> * packet segmentation. >> * >> * @param name Name of the pool, max ODP_POOL_NAME_LEN-1 chars. >> * May be specified as NULL for anonymous pools. >> * >> * @param shm The shared memory object in which to create the pool. >> * Use ODP_SHM_NULL to reserve default memory type >> * for the pool type. >> * >> * @param num_pools Number of sub-pools in a composite pool >> * >> * @param params Array of sub-pools' parameters. >> * >> * @return Handle of the created pool >> * @retval ODP_POOL_INVALID Pool could not be created >> */ >> >> odp_pool_t odp_pool_create_composite(const char *name, >> odp_shm_t shm, >> uint32_t num_pools, >> odp_pool_param_t *params[]); >> > _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
