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 D86AA2BB9 for ; Thu, 8 Jun 2017 15:59:52 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4CC9320AE6; Thu, 8 Jun 2017 09:59:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 08 Jun 2017 09:59:52 -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=ppxQbIktPgeEJvw HpJg+72d3U4mSV6LESUJkhJeOHFM=; b=NoxfuYyDMu2WKsie5kPyMshEUDkr9Ng qG497BeZNjHvK/IjayNQToxsqSh/QqCjqIiETtsv32WM29b95SM4Dab56HUO0HqL kxJFMwVXcmTYlGshoKoL+wj5+AAq7WEYNFZgQiPb3JqCRh+rNa9cU9tVejRruNxG e9+/kY6p/T64= 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=ppxQbIktPgeEJvwHpJg+72d3U4mSV6LESUJkhJeOHFM=; b=Dashe2wv fzAc7q5vjNmIV91xLJjK+U8FziNWKsIqLQ7YI38qRg8W43s+4QA7FgESx7ZM1R5G lPPu/gLGckYuhgPK5BTeLbRTd/9TFI7HbXlcSlpdmzD9DO5R1xeRtmfaCG7PlX1y dOR/R0ZqbD4Qyf51hWDHY2cPn9LUYlxuxx9uSLPyJgPd9nbz1Kqa9yoe/O6pIHEs TyLVwB0jhbdohfqjJ8owfioKsGdcjbu9hMj3LC9uYeMfiobQp5b3ep8lwnJbbxJd IOxRqX+v3RPRv3DDKMer+I/6t9hBPBKef5HXMG12oNLRVkvdHW65oPiyzYBedNPH t876slZBiD+RHQ== X-ME-Sender: X-Sasl-enc: ku6OhNoLHXq0Hw8H1R1O/hTr0P8cMZvwVKNGo38nYB57 1496930392 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id F1B082475E; Thu, 8 Jun 2017 09:59:51 -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 15:59:51 +0200 Message-ID: <1864257.RH1pdGjOGJ@xps> In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891267BA669D7@IRSMSX108.ger.corp.intel.com> References: <20170526181149.44085-1-jasvinder.singh@intel.com> <3485754.OcGeoT3SaN@xps> <3EB4FA525960D640B5BDFFD6A3D891267BA669D7@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 13:59:53 -0000 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"? > > > 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 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.