I'd like to discuss this during today's ODP call as there are lots of good ideas being discussed here.
Bill On Tue, Apr 7, 2015 at 7:28 AM, Jerin Jacob <[email protected]> wrote: > 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 [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
