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 42E8DA04B4; Fri, 8 Nov 2019 15:54:40 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BF4C71C21F; Fri, 8 Nov 2019 15:54:39 +0100 (CET) Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) by dpdk.org (Postfix) with ESMTP id 1A1351C1DC for ; Fri, 8 Nov 2019 15:54:38 +0100 (CET) Received: by mail-il1-f194.google.com with SMTP id z12so5380558ilp.2 for ; Fri, 08 Nov 2019 06:54:38 -0800 (PST) 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:content-transfer-encoding; bh=rymasp/eOGMO4N8Exie7oBe9TU0FrI6W7C4oniOA2j4=; b=IexekyconK/bpabq1BRQGMQW9PEWeTngjnUezi8u+JlbPFOODtOrhsJtFkDtRmJx8B lavKjrUk/1PWqO+BNAtoi0h6a3yQlQbZdm4DorCv/jqFexsR1y+l7UKMBeT8gUegnMuq mHuD81fve5Ee443n377xEFXX2atEtuAaNuhZZUPWv/noQBFG+gMTBUEFTGf0EDfX37i3 vRyjVN+yStBAwooMb2Rm3LCN/WXphL1tTcprogno5PX7Es68KhsMQMTjMo586xXQP7IY NMcHFWwDPgXzRmEAiMQnxhYwFmtOCjB8jUISKwfJdOJdBZzKFkySBIRRRFL0sqJOKJC2 qbTw== 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:content-transfer-encoding; bh=rymasp/eOGMO4N8Exie7oBe9TU0FrI6W7C4oniOA2j4=; b=AApm0hA/OiZtoQd30gFKn0RHN+riNiHU+y5QWQ8HGO3rY4IrsecavIjIx3ooHWTgOR 8qtD89PehP4jcoEj4yeCu+/8+aR4EH1qxQLbC2wOZcXxCjqfi3yxUAqNB0cGDlhOHAys Gs2o9bkUSLDZ62+nUrAZSo8VVpzt216oKWgAbpcqRtfVKtMD/JY8+fyn/vPWqRFzg7hS 7hQLShSdiuYATsm2j3l1EBq5hQd3RdJ5x0D8UeZ8fU3lXjAhZi+lfq5Gu+htG5+Bxl79 s87kAsfRZI64/2FeibXXD7M9uOr9GqH+pHZgCemaA2lIqDhRTSEOYRdBPEj+qAfxfgHk 1zLw== X-Gm-Message-State: APjAAAWhgSgmUh+1HeY2NB2Aw6GgLtmDmuOSBa0iE0OUD2bIjDC3/WPq F6dqtZ56+a4g/nrzsb//DTSBAQ57BwlXpN1L3BY= X-Google-Smtp-Source: APXvYqyxnXZhHHxLz4C3Ua/LWaMzwXlgNdFKnKy3kmxwu3rrt4WqbV4gXWbTzJYoqbkffY9QVv0liHcOXolfwReNyEM= X-Received: by 2002:a92:aa48:: with SMTP id j69mr13226882ili.162.1573224877188; Fri, 08 Nov 2019 06:54:37 -0800 (PST) MIME-Version: 1.0 References: <20191021080324.10659-1-vattunuru@marvell.com> <20191105110416.8955-1-vattunuru@marvell.com> In-Reply-To: From: Jerin Jacob Date: Fri, 8 Nov 2019 20:24:20 +0530 Message-ID: To: Ferruh Yigit Cc: Vamsi Krishna Attunuru , "dev@dpdk.org" , "thomas@monjalon.net" , Jerin Jacob Kollanukkaran , Kiran Kumar Kokkilagadda , "olivier.matz@6wind.com" , "anatoly.burakov@intel.com" , "arybchenko@solarflare.com" , "stephen@networkplumber.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v12 0/2] add IOVA=VA mode support 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 Fri, Nov 8, 2019 at 7:56 PM Ferruh Yigit wrote: > > > >> Hi Vasim, Jerin, > >> > >> Overall looks good and I not getting any functional error but I am obs= erving a > >> huge performance drop with this update, 3.8Mpps to 0.7Mpps [1]. > > > > Hi Ferruh, > > When it comes to actual kernel netdev test cases like iperf or any oth= er use cases, there would not be any impact on performance. I think synthet= ic test case like loopback mode might not be the actual test case alone to = depend on when the kernel module is featured to work with kind of devices(p= dev or vdev). Users can always fallback to pa mode with cmd line option. > > > > Please suggest your thoughts on considering what test case to use & eva= luate the performance difference. > > Hi Vasim, > > I also assume the real life test cases will be affected less, but the loo= pback > performance testing is good to show performance impact of the change. Yes. real-world case Linux kernel stack will be the bottleneck. > > (Stephen's predictions that KNI is not as fast as tun/tap are getting mor= e real > by time J) > > At least I think the possible performance drop and how to mitigate it sho= uld be > documented both in release notes and kni documentation. +1 for adding documentation. Setting iova-mode=3Dpa will be mitigation if the application does not care about iova-mode. > > For the final decision, I am not objecting it but I would like to see mor= e ack > from community to confirm that we trade off iova=3Dva functionality again= st > performance. In my view, IOVA as VA mode case, translation cannot be avoided and we have the requirement where it needs to work with vdev(where is not backed by any IOMMU context) = so I am not sure how to avoid the translation cost. Since we have support for both modes,i.e existing IOVA as PA path still exists, I don't think, we are losing anythin= g. > @Jerin, @Thomas, should we conclude this in techboard? Perhaps we can get= it for > rc2 and drop it back if rejected in techboard? > > Regards, > ferruh