> -----Original Message----- > From: Burakov, Anatoly <anatoly.bura...@intel.com> > Sent: Friday, July 12, 2019 5:40 PM > To: Jerin Jacob Kollanukkaran <jer...@marvell.com>; Ferruh Yigit > <ferruh.yi...@intel.com>; Vamsi Krishna Attunuru > <vattun...@marvell.com>; dev@dpdk.org > Cc: olivier.m...@6wind.com; arybche...@solarflare.com > Subject: [EXT] Re: [dpdk-dev] [PATCH v6 0/4] add IOVA = VA support in KNI > > External Email > > ---------------------------------------------------------------------- > On 12-Jul-19 12:37 PM, Jerin Jacob Kollanukkaran wrote: > >> -----Original Message----- > >> From: Burakov, Anatoly <anatoly.bura...@intel.com> > >> Sent: Friday, July 12, 2019 4:19 PM > >> To: Jerin Jacob Kollanukkaran <jer...@marvell.com>; Ferruh Yigit > >> <ferruh.yi...@intel.com>; Vamsi Krishna Attunuru > >> <vattun...@marvell.com>; dev@dpdk.org > >> Cc: olivier.m...@6wind.com; arybche...@solarflare.com > >> Subject: [EXT] Re: [dpdk-dev] [PATCH v6 0/4] add IOVA = VA support in > >> KNI On 12-Jul-19 11:26 AM, Jerin Jacob Kollanukkaran wrote: > >>>>>> What do you think? > >>>>> > >>>>> IMO, If possible we can avoid extra indirection of new config. In > >>>>> worst case We can add it. How about following to not have new > >>>>> config > >>>>> > >>>>> 1) Make MEMPOOL_F_NO_PAGE_BOUND as default > >>>>> http://patches.dpdk.org/patch/55277/ > >>>>> There is absolutely zero overhead of this flag considering the > >>>>> huge page size are minimum 2MB. Typically 512MB or 1GB. > >>>>> Any one has any objection? > >>>> > >>>> Pretty much zero overhead in hugepage case, not so in non-hugepage > >> case. > >>>> It's rare, but since we support it, we have to account for it. > >>> > >>> That is a fair concern. > >>> How about enable the flag in mempool ONLY when > >> rte_eal_has_hugepages() > >>> In the common layer? > >> > >> Perhaps it's better to check page size of the underlying memory, > >> because 4K pages are not necessarily no-huge mode - they could also > >> be external memory. That's going to be a bit hard because there may > >> not be a way to know which memory we're allocating from in advance, > >> aside from simple checks like `(rte_eal_has_hugepages() || > >> rte_malloc_heap_socket_is_external(socket_id))` - but maybe those > >> would be sufficient. > > > > Yes. > > > > > >> > >>> > >>>> (also, i don't really like the name NO_PAGE_BOUND since in memzone > >>>> API there's a "bounded memzone" allocation API, and this flag's > >>>> name reads like objects would not be bounded by page size, not that > >>>> they won't cross page > >>>> boundary) > >>> > >>> No strong opinion for the name. What name you suggest? > >> > >> How about something like MEMPOOL_F_NO_PAGE_SPLIT? > > > > Looks good to me. > > > > In summary, Change wrt existing patch" > > - Change NO_PAGE_BOUND to MEMPOOL_F_NO_PAGE_SPLIT > > - Set this flag in rte_pktmbuf_pool_create () when > rte_eal_has_hugepages() || > > rte_malloc_heap_socket_is_external(socket_id)) > > If we are to have a special KNI allocation API, would we even need that?
Not need this change in rte_pktmbuf_pool_create () if we introduce a new rte_kni_pktmbuf_pool_create () API. > > > > > Olivier, Any objection? > > Ref: http://patches.dpdk.org/patch/55277/ > > > > > > -- > Thanks, > Anatoly
