From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 54ED2CA9EB6 for ; Wed, 23 Oct 2019 15:02:27 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id DB78C21872 for ; Wed, 23 Oct 2019 15:02:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QcDikcVg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DB78C21872 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 3E9E91C1FE; Wed, 23 Oct 2019 17:02:26 +0200 (CEST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) by dpdk.org (Postfix) with ESMTP id A08471C1FD for ; Wed, 23 Oct 2019 17:02:25 +0200 (CEST) Received: by mail-io1-f65.google.com with SMTP id c25so25260637iot.12 for ; Wed, 23 Oct 2019 08:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HoSy9WSJpgpEjynt+dYEqSiNOaehxGG4NfCR8xooSlE=; b=QcDikcVg68Amiw4le2IPWR2hqDiCleRRjxCUCDEX7vI2SNY5GBfQnqryplxxzfhOEY 8oUVIvTd1EUmdBxVap7+chLkCwqbubPkxyFXhdR67JeS/ATpGFLSQ1HWiGXGlWOy1tjP bBWSeEu+7Xav5sSUXmasxBxbycC+NHkbawby2vAhzWrK09070ZwrO0MJFmgBMv8H5l/Z ksoHr/FlXXQ4ryAsBIQy9xrHtv78dRXv6L5tu/1giC7hM2T7RlBCu3ZItVOhOzjmWszl 0UvZqtUpBiR7GhoWpI0bgeZjk+mS8drZ771IwcFwsHGYfg2YwBGHb4V6KlMbmM3eej8q lneQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HoSy9WSJpgpEjynt+dYEqSiNOaehxGG4NfCR8xooSlE=; b=S8diukUs3YicCXYFOwmIxnsN8Q5rtzt3OsLC3cH/gofw8KGeBBwQutM2A9v+KktoK9 tVWHgd5t8uj4iZzyMjAnLiN42cZvGBUepp18cqT4Kt0N8vZO9MDJzeXVc47w+1IKHazR +7AfTzJeTt+sebEhxvg0FI+xrttFrsY8YSYyZPkNW/U/g3pK+ZxiSwzAR/36piFFFumt 3uczi0gJo94X3h0Y7MHOkKTy04S+Dci7AhHuaZfuVM/ZifdztgQ0bAp+8Oe86w2k7+T9 LVGCfKP3CFzu7r/q783FknqrMFOxL6Fcif5ReyYGT6hTnbK5SfxOXkY4XdGuGyx6nSj1 rvJA== X-Gm-Message-State: APjAAAXTzPqnkVd9wlZS7E7EDqWv+ZxrpLK8Uoa0x2UqP94+XgQCRvlB nHt8dcWS5kW2lxiVIp6V4Ok/dqAs9m7CCepkUa4= X-Google-Smtp-Source: APXvYqy6WgtgX0rdw5avmeLRIsRgo5rtW7GCCc2XuT0ikQEO8cTLd8CczK9yPk+FHeylEAprcCHS/hcxnddkKgzZ3j0= X-Received: by 2002:a6b:740b:: with SMTP id s11mr3865138iog.294.1571842944658; Wed, 23 Oct 2019 08:02:24 -0700 (PDT) MIME-Version: 1.0 References: <20190816061252.17214-1-vattunuru@marvell.com> <20191021080324.10659-1-vattunuru@marvell.com> <20191021080324.10659-3-vattunuru@marvell.com> <4bd1acf5-2da2-b2da-2b0c-7ee243d5aeb9@intel.com> <77f8eaf0-52ca-1295-973d-c8085f7b7736@intel.com> <08c426d1-6fc9-1c3f-02d4-8632a8e3c337@solarflare.com> <20191023144724.GO25286@glumotte.dev.6wind.com> In-Reply-To: <20191023144724.GO25286@glumotte.dev.6wind.com> From: Jerin Jacob Date: Wed, 23 Oct 2019 20:32:08 +0530 Message-ID: To: Olivier Matz Cc: Vamsi Krishna Attunuru , Andrew Rybchenko , Ferruh Yigit , "thomas@monjalon.net" , Jerin Jacob Kollanukkaran , Kiran Kumar Kokkilagadda , "anatoly.burakov@intel.com" , "stephen@networkplumber.org" , "dev@dpdk.org" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v11 2/4] eal: add legacy kni option X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, Oct 23, 2019 at 8:17 PM Olivier Matz 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 > > 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.