From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 8CA731AEE8 for ; Fri, 6 Oct 2017 14:13:41 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 087A320CB3; Fri, 6 Oct 2017 08:13:41 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 06 Oct 2017 08:13:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=98CvFqghGFu+6rh HS9bDg6wAGXWPRfo9hg2HlH+4vaY=; b=Cv3DO7xtKwwm1Qw+W3u71rI8g92SpUq wUIJda1rS7y74YpY0OCT3KSOJJTSNFUJY1mpxcKtU4FhEVIcGhkMQz1oQDiCohAm ck5d0eYrjqwA7XONZMX7Mw24PqxYLMDI1dhLYD3fZQ9W5iB+KNNVbrfw/mt1NzX8 3PFIz4DfVLSE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=98CvFqghGFu+6rhHS9bDg6wAGXWPRfo9hg2HlH+4vaY=; b=KJ2k91hV 7y8TCGieMUAmUh3sltJ9CfEqB6xQw0FGfiVUfxydVeeICk7zxpVmBnba/MQCvKDk 3eCEQFNZt3QZzdkj4RDlnGGzi3al8y6P6OnY4QWC7LOiXAd+8PmRP2zZ1GarEJ0S BS5YkrPRmluZz6M7VUUDtIf6tI6GZnUyNTtJpszhyOa2A3dT1SpRhJAqZvPRXeVc /CkPy783E0j0Pm2vcU7w1A0kHErFPjaaRuCSCtviaDT54nemhFXbUHsbMjXktbpY W7cv/JlmhsP9HGU5JTN2y7lAAa81MxoyMe3yfkDNtcCf6wADSit0viTmoukKcIGn dngCxcvoEAZYOA== X-ME-Sender: X-Sasl-enc: IPCpR/6ivEjixvwbadZ29tvi4/Ri9esRPjNlF4GXlv7w 1507292020 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id AA989247AE; Fri, 6 Oct 2017 08:13:40 -0400 (EDT) From: Thomas Monjalon To: "Dumitrescu, Cristian" Cc: "Singh, Jasvinder" , dev@dpdk.org, "Yigit, Ferruh" Date: Fri, 06 Oct 2017 14:13:39 +0200 Message-ID: <4027350.aJV4RcU0HN@xps> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BACA9D0@IRSMSX108.ger.corp.intel.com> References: <20170811124929.118564-2-jasvinder.singh@intel.com> <9843308.sSVeHNjL0n@xps> <3EB4FA525960D640B5BDFFD6A3D891267BACA9D0@IRSMSX108.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4 0/4] net/softnic: sw fall-back pmd for traffic mgmt and others 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: , X-List-Received-Date: Fri, 06 Oct 2017 12:13:41 -0000 06/10/2017 12:40, Dumitrescu, Cristian: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 18/09/2017 11:10, Jasvinder Singh: > > > The SoftNIC PMD is intended to provide SW fall-back options for specific > > > ethdev APIs in a generic way to the NICs not supporting those features. > > > > I agree it is important to have a solution in DPDK to better manage > > SW fallbacks. One question is to know whether we can implement and > > maintain many solutions. We probably must choose only one solution. > > > > I have not read the code. I am just interested in the design for now. > > I think it is a smart idea but maybe less convenient than calling fallback > > from ethdev API glue code. My opinion has not changed since v1. > > Thanks for the detailed explanations. Let's discuss below. > > > > Don't understand me wrong, I would also like to have the single device solution (hard NIC augmented with SW-implemented features) as opposed to the current proposal, which requires two devices (hard device and soft device acting as app front-end for the hard device). > > The problem is that right now the single device solution is not an option with the current librte_ether, as there simply a lot of changes required that need more time to think through and get agreement, and likely several incremental stages are required to make it happen. As detailed in the Dublin presentation, they mostly refer to: > - the need of the SW fall-back to maintain its owns data structures and functions (per device, per RX queue, per TX queue) > - coexistence of all the features together > - how to bind an ethdev to one (or several) SW threads > - thread safety requirements between ethdev SW thread and app threads > > Per our Dublin discussion, here is my proposal: > 1. Get Soft NIC PMD into release 17.11. > a) It is the imperfect 2-device solution, but it works and provides an interim solution. > b) It allows us to make progress on the development for a few key features such as traffic management (on TX) and hopefully flow & metering (on RX) and get feedback on this code that we can later restructure into the final single-device solution. > c) It is purely yet another PMD which we can melt away into the final solution later. > 2. Start an RFC on librte_ether required changes to get the single-device solution in place. > a) I can spend some time to summarize the objectives, requirements, current issues and potential approaches and send the first draft of this RFC in the next week or two? > b) We can then discuss, poll for more ideas and hopefully draft an incremental path forward > > What do you think? I think temporary solutions (which often become definitive) must be avoided, especially when it implies new API. In the case of softnic, there is no new API really, just a new workflow for applications and some new driver parameters. So my conclusion is that we should merge and experience it. It does not prevent from working on another solution, as you suggest. Acked-by: Thomas Monjalon PS: thank you for having given your opinion on other questions