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 5DFD711C5 for ; Thu, 8 Jun 2017 18:16:48 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A6D9520D9D; Thu, 8 Jun 2017 12:16:47 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 08 Jun 2017 12:16:47 -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=h8tB2/KcFo7eVmt 2vFg/QucN81ZE2VnFkuYonG3K+t8=; b=TnS2QeYTpwag4/fEuu7SKj5r34AS3eh ENFbNfz/d229GM/S2Dj/OwNGBGsPNgW7ul0nSKcJri7ULWONXHmMmuyXvEnCvXu4 JQ7Fb2qDd0K+hNy3w/2hg8ZDBNylo+tRVfRT6OaX5OxfIWBHz5wjKflyt6y7MVJQ 26fr26LVrqZ0= 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=h8tB2/KcFo7eVmt2vFg/QucN81ZE2VnFkuYonG3K+t8=; b=mY1mZT3a Xhb00d2U76htfM3XBTxJ+B7whMVb2CDAIA8B4L9UPWGSvghM1cPAMFRWn7fU+fed uq2lJVPQHEEXghDi5xPoq6y/yZl9c+Dj+0xL/IB3hqBXZKM5YA5znhPWKoCe06uS WuhrSjR9yBPwldLg3TcVyqxIugU3bI8/0XK1Jz2kgLjmqaTgMNG0DjWodJqDxN4a qg6++Cmy5rKmq3q1nViavKLRMG85Cggk9AuQwTYx83mkFhrJFrLmUKTHXTkriZH/ sMwoUdXgGpLH/WgMNllN2ua52V5/iywYiOn+rBpboQQ3azg+T7YFy022pljg2nPg dIwYhc93Dr4nhw== X-ME-Sender: X-Sasl-enc: ZCdcu1f6LKICggeuysRhy1t14WrONvX95KpZSBAsOwoh 1496938607 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 596D67E8B7; Thu, 8 Jun 2017 12:16:47 -0400 (EDT) From: Thomas Monjalon To: "Dumitrescu, Cristian" Cc: "Singh, Jasvinder" , dev@dpdk.org, "Yigit, Ferruh" , "hemant.agrawal@nxp.com" , "Jerin.JacobKollanukkaran@cavium.com" , "Lu, Wenzhuo" Date: Thu, 08 Jun 2017 18:16:46 +0200 Message-ID: <1855073.SEfz2U5OaA@xps> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BA66B0B@IRSMSX108.ger.corp.intel.com> References: <20170526181149.44085-1-jasvinder.singh@intel.com> <1864257.RH1pdGjOGJ@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA66B0B@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 0/2] net/softnic: sw fall-back for traffic management 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: Thu, 08 Jun 2017 16:16:48 -0000 08/06/2017 17:27, Dumitrescu, Cristian: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 08/06/2017 15:27, Dumitrescu, Cristian: > > > Hi Thomas, > > > > > > Thanks for reviewing this patch set! > > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > > > > Hi Jasvinder, > > > > > > > > 26/05/2017 20:11, Jasvinder Singh: > > > > > The SoftNIC PMD provides SW fall-back option for the NICs not > > supporting > > > > > the Traffic Management (TM) features. > > > > > > > > Do you mean that you want to stack PMDs in order to offer some > > fallbacks? > > > > It means the user needs to instantiate this PMD for each HW which does > > > > not support traffic management, instead of normal hardware probing? > > > > > > > > > > No, the normal HW probing still takes place for the HW device. Then if QoS > > "probing" fails, the user can decide to create a new virtual device on top of > > the HW device. > > > > What do you mean by "QoS probing"? > > Check if the hierarchy specified by the user can be met by the HW device. > > > > > > > > SoftNIC PMD overview: > > > > > - The SW fall-back is based on the existing librte_sched DPDK library. > > > > > - The TM-agnostic port (the underlay device) is wrapped into a TM- > > aware > > > > > softnic port (the overlay device). > > > > > - Once the overlay device (virtual device) is created, the configuration > > of > > > > > the underlay device is taking place through the overlay device. > > > > > - The SoftNIC PMD is generic, i.e. it works for any underlay device PMD > > that > > > > > implements the ethdev API. > > > > > > > > Why not calling librte_sched directly in ethdev for PMDs which do not > > > > implement hardware offload? > > > > Am I missing something obvious? > > > > > > Yes, we are calling the librte_sched in ethdev, but how else can we do it? > > > > If you call librte_sched from ethdev, that's fine. > > We don't need more, do we? > > > > We also need to make sure the other non-patched functionality is working as provided by the underlying HW device. E.g. we patch TX to enable TM, but we don't patch RX and RX should still be working. > > > > - We cannot change the ethdev ops of the HW device PMD because > > same might be used by other HW devices in the system where TM feature is > > not required. > > > - We cannot change the ethdev ops of the current HW device, as on- > > the-fly changes of the ops structure are not allowed, right? > > > > Right > > > > > - We can create a new virtual device on top of existing HW device to > > inherit most of the ethdev ops of the HW device and patch some specific > > ethdev ops with librte_sched. > > > > > > IMHO there aren't two different ways to do this. > > > > When initializing a HW device, it can (should) reports its TM capabilities. > > Then ethdev can decide to use a SW fallback if a capability is missing. > > Unfortunately, having the ethdev taking this decision is not possible with the current librte_ether, as this means the changing the ethdev ops on the fly, which you also agreed is currently not allowed. I'm sure I'm missing something. In my understanding, we do not need to change the ops: - if the device offers the capability, let's call the ops - else call the software fallback function > This is why we have to leave this decision to the application, which creates the virtual device on top of the existing HW when it wants the SW fall-back to be enabled.