This patch does not define sub-pools. It gives application a way to specify more fine grained how many packets of each size is needed. Implementation may or may not be based on sub-pools. Pool create still returns one pool (odp_pool_t) handle.
E.g. instead of today's: num = 4k len = 1.5k max_len = 64k application may give: num[0] = 4k len[0] = 1.5k num[1] = 256 len[1] = 9k num[2] = 32 len[2] = 64k max_len = 64k max_num = 8k which tells more accurately what is needed. Implementation may calculate optimal segment size(s) and round up (up to max_num). Today: max_num == num, and application cannot tell how many e.g. 64k packets it needs. In the example above, one 64k packet would be enough by the spec. -Petri > -----Original Message----- > From: Nikhil Agarwal [mailto:nikhil.agar...@nxp.com] > Sent: Friday, June 23, 2017 7:58 AM > To: Petri Savolainen <petri.savolai...@linaro.org>; lng- > o...@lists.linaro.org > Subject: RE: [lng-odp] [API-NEXT PATCH v3] api: pool: additional packet > length configuration > > This concept for sub-pools within a pool is adding unnecessary complexity > to pool configurations. What is the purpose of this? We don't support > having multiple size buffers in same pool. In case application wants to > attach multiple pools to same pktio, we can introduce an API to attach > pool to pktio. In case of sub-pools there will be ambiguity that which > sub-pool is used for odp_packet_alloc. > > Regards > Nikhil > > -----Original Message----- > From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of Petri > Savolainen > Sent: Thursday, June 15, 2017 7:51 PM > To: lng-odp@lists.linaro.org > Subject: [lng-odp] [API-NEXT PATCH v3] api: pool: additional packet length > configuration > > Added packet pool parameters for more fine grained pool configuration. The > basic usage of the parameters is not changed, except that implementation > may now round up 'num' by default. > Application can limit the round up with new 'max_num' parameter. > Another new parameter (opt) allows application give hints and requirements > about e.g. memory to be used for a pool (or parts of the pool). > > Additionally, pool configuration may be extended with a table of > num/len/opt values. This gives application more flexibility to specify > requirements for various packet sizes. > > For example, the new specification allows to create this kind of > pool: > > ^ > | > max_num | - - - - - - - - > | > | * > NUM | * * > | * * * > | o * * * * > | o * * * * * > +---------------> > LEN > > o == small number of short packets into fast memory > * == all other packets into DDR
