[dpdk-dev] [EXT] Re: [PATCH v11 2/4] eal: add legacy kni option
olivier.matz at 6wind.com
Wed Oct 23 16:47:24 CEST 2019
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
> <vattunuru at 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
> b1) There is no need for specific mempool_create for KNI.
> 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
> 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.
> 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
> 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.
More information about the dev