From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E4288A3295 for ; Wed, 23 Oct 2019 12:12:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B4BA51C031; Wed, 23 Oct 2019 12:12:57 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id 3C9AD1C02E for ; Wed, 23 Oct 2019 12:12:56 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id y12so6642677ioa.6 for ; Wed, 23 Oct 2019 03:12:56 -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=nXKiS9F5VKNuYGDCYL3AHpui90ZoQ8GF5igW07BQgGs=; b=R8vm+3l7olsg8SYCtTdVIs462DJsQ0+z0WDqHSK4BSoZujM3Xh5sR6Lg36euvRh+mS hpZg6Efk1k1qLxS+miE/Z3mJIVhgPocndisQQuS0INrIPdO3m/ThuPs+vmJziHCn3/IQ HvuHovOAlxy8qQ3K8m8XGkF+7Ou3UH8+BYheRcHKeDK7yF9+SMIUmiSJhCAjjcghrrAj 25uzhgUujio1IpcY0BVA51ImV/x+14fBzMQ3NYG8YrSMdT9+bGulyKwLC/pi/LyzJHwM evFulaLWH86AlGFfnCSx3cdS6jU2adx2uvtdXJ58QzcFwuACSDgghUB5aPLy/hq79V+U b6IQ== 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=nXKiS9F5VKNuYGDCYL3AHpui90ZoQ8GF5igW07BQgGs=; b=Jvy1bN2VQfcXPVRV5AhabkKchWZBz+XKAIaPDOZbFn0+0s9qZCGG33sGRz2JuKYPkl 5dN9g5IYs3+uVueOzi65Uz2flsskWV4F1oA9Au3db/fsXNeMlbyMW8iq865zifcvSMbA NjwoB7WOUs0csBPdVGriWkL9m9eAFbY3K9kVyiwDJiTmjLaTAqeKsF/9cipeOWoDPvGN E6hYSzmP/FH1HZsOFEUB+pZQ+Q1At32Pq8FLIjQb1M7IsYL5wQKbfawPSur+njsVZAvX nUv6w7zMEFnj1z8Ike+CyEwuCLgq+2ahCj4j9+9f5Gr2MgOEOil7u3LURsO8x7qTCUt/ bh3A== X-Gm-Message-State: APjAAAVPNfRopZtbBQMJ9wt+200pCslojxfitrn0hnBSQWRnldH37jaI t0popE/23pJyOAqqI6karpHyrgTJ7zuQlDKPwoM= X-Google-Smtp-Source: APXvYqwGmJ4HcJJ6Gc9tgI/NsRkeVcg0JjerQ3VRbYRDrBpiR94zDxiEkN4yhiLeUXyL5p/T961wLc/F12lWwM/OKyw= X-Received: by 2002:a6b:c701:: with SMTP id x1mr2471947iof.162.1571825575281; Wed, 23 Oct 2019 03:12:55 -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> In-Reply-To: From: Jerin Jacob Date: Wed, 23 Oct 2019 15:42:39 +0530 Message-ID: To: Vamsi Krishna Attunuru Cc: Andrew Rybchenko , "olivier.matz@6wind.com" , 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 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. > > I wanted to clarify ourselves about the need of mem pool patch(V11 1/4) and where to fit the fix(newer APIs or fix in mempool lib) before I start reworking the patches. > > Regards > A Vamsi > > > snipped > > >> > > >> This is new feature, who want to use it adding a specific flag makes > > >> more sense to me than all old users have to add the flag. > > > > > > Ferruh suggested to have a flag for enabling these new feature and also not > > interested in having newer mempool alloc APIs for KNI(see V10 review > > comments). Before reworking on the flag changes, I would like check with you > > whether the same flag can be used in mempool lib for checking and fulfilling the > > mempool page boundary requirement (mempool patch v11 1/4), by doing so, it > > can avoid newer exported APIs both in mempool and KNI lib. Anyways, these > > mempool requirement can be addressed with Olivier's below patches. > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__patchwork.dpdk.org > > > _project_dpdk_list_-3Fseries- > > 3D5624&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ& > > > r=WllrYaumVkxaWjgKto6E_rtDQshhIhik2jkvzFyRhW8&m=tCO- > > 8E27vdyIVMm_35Qv6K > > > -OwGCIobWI0H9DGGBm-gc&s=9aLHS9Og5L0uhuLGFAuQ9NAT3- > > hlFmtc9RrrSbLQC00&e= > > > > > > When those patches are merged, flag check can be removed. > > > > It is really hard to follow, sorry. > > Is it really a problem to have KNI switcher to enable new behaviour and > > document it that dedicated function should be used to allocate mbufs? > > > > Andrew. > > > > > Regards > > > A Vamsi