On Wed, Oct 23, 2019 at 8:17 PM Olivier Matz <olivier.m...@6wind.com> wrote: > > Hi, > > On Wed, Oct 23, 2019 at 03:42:39PM +0530, Jerin Jacob wrote: > > On Tue, Oct 22, 2019 at 7:01 PM Vamsi Krishna Attunuru > > <vattun...@marvell.com> wrote: > > > > > > Hi Ferruh, > > > > > > Can you please explain the problems in using kni dedicated mbuf alloc > > > routines while enabling kni iova=va mode. Please see the below discussion > > > with Andrew. He wanted to know the problems in having newer APIs. > > > > > > While waiting for the Ferruh reply, I would like to summarise the > > current status > > > > # In order to make KNI work with IOVA as VA, We need to make sure > > mempool pool _object_ should not span across two huge pages > > > > # This problem can be fixed by, either of: > > > > a) Introduce a flag in mempool to define this constraint, so that, > > when only needed, this constraint enforced and this is in line > > with existing semantics of addressing such problems in mempool > > > > b) Instead of creating a flag, Make this behavior by default in > > mempool for IOVA as VA case > > > > Upside: > > b1) There is no need for specific mempool_create for KNI. > > > > Downside: > > b2) Not align with existing mempool API semantics > > b3) There will be a trivial amount of memory waste as we can not > > allocate from the edge. Considering the normal huge > > page memory size is 1G or 512MB this not a real issue. > > > > c) Make IOVA as PA when KNI kernel module is loaded > > > > Upside: > > c1) Doing option (a) would call for new KNI specific mempool create > > API i.e existing KNI applications need a one-line change in > > application to make it work with release 19.11 or later. > > > > Downslide: > > c2) Driver which needs RTE_PCI_DRV_NEED_IOVA_AS_VA can not work with KNI > > c3) Need root privilege to run KNI as IOVA as PA need root privilege > > > > For the next year, we expect applications to work 19.11 without any > > code change. My personal opinion to make go with option (a) > > and update the release notes to document the change any it simple > > one-line change. > > > > The selection of (a) vs (b) is between KNI and Mempool maintainers. > > Could we please reach a consensus? Or can we discuss this TB meeting? > > > > We are going back and forth on this feature on for the last 3 > > releases. Now that, we solved all the technical problems, please help > > us > > to decide (a) vs (b) to make forward progress. > > Thank you for the summary. > What is not clear to me is if (a) or (b) may break an existing > application, and if yes, in which case.
Thanks for the reply. To be clear we are talking about out of tree KNI tree application. Which they don't want to change rte_pktmbuf_pool_create() to rte_kni_pktmbuf_pool_create() and build for v19.11 So in case (b) there is no issue as It will be using rte_pktmbuf_pool_create (). But in case of (a) it will create an issue if out of tree KNI application is using rte_pktmbuf_pool_create() which is not using the NEW flag.
