On Tue, Apr 07, 2015 at 01:58:51PM +0300, Taras Kondratiuk wrote: > On 04/07/2015 12:40 PM, Jerin Jacob wrote: > >On Tue, Apr 07, 2015 at 12:01:30PM +0300, Taras Kondratiuk wrote: > >>On 04/06/2015 07:41 PM, Bill Fischofer 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. > >> > >>If it is called "pool group", then it sounds like a separate > >>abstraction. Which in turn needs a separate type and new API functions > >>to destroy or attach to somewhere (pktio, CoS, etc.). > > > >We have introduced the new classification term ODP_PMR_LEN to > >address "Segmentation optimization" use case by attaching > >different pools based on packet len. > > > >Are we introducing the new composite pool schematics because > >ODP_PMR_LEN cannot implemented in hardware ? > > Hi Jerin, > > I've described in this thread why ODP_PMR_LEN does not address > this use-case correctly. It sets too strict classification rules, > which are not needed in this use-case.
Hi Taras, Got the use-case description from the thread. If application really _demands_ for such fine grained memory optimization then composite pool OR additional hint in the pool creation is the way to go _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
