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
