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 794432BBB for ; Wed, 7 Jun 2017 16:32:05 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E23FD2075C; Wed, 7 Jun 2017 10:32:04 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 07 Jun 2017 10:32:04 -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=PAUKWPKNdCqxspz 3sHQ1xmStSqygvbNT97DZO3AsLZg=; b=hhyLrZNxJIJM5uQ6oQkfh4GSWZfzBXY m038lOZdVlSeWznLlWrxaf3ARizLimnhOhZsPs/5FJe9X1IwqRYLP26QHrru8zH7 q33cjzMBiqxl8vuOkOWz2MZM9HZdAwcXUKYGEzAum3CgZOZbmxmcYb0NW96CAID+ AqBF2IMu364c= 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=PAUKWPKNdCqxspz3sHQ1xmStSqygvbNT97DZO3AsLZg=; b=jOG6BYGF AX1TKS4aRIccSW4/k4zNcAUYZ9LXYa/ZkFw6BONNbhSFfT38sZUD4nG5RQuSzMKl jNNxJKtbRtHMQ5LQPGGUesmoTsC/bJI8XOugCE62m40tb/43+Qp1mHq4+zmrnB3X wzW+z4IZ0NprjXRxlLL+Jkgm5PddC2gANPzIFQfgvEPHTu0Lkw46HxUu6EZg3b6n 5UzwMAf/ee7uKYhqVH1Vimzbm4e3ILan3Ymnmf/ZK3zYX3j71rYyxOlShPIvuUUf aKgoSAmd9o3E6D3DQqPba/OAp0RAVGsNtTNUnVHoQB6/WMPbCgSUPZaXmmpjLpTg mnMSQD3oE+wgOg== X-ME-Sender: X-Sasl-enc: xThLkq3vS8VbyqzEuxjNWDHBb2+DUNn/g4ozvfbnMgN+ 1496845924 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 94AEF248E3; Wed, 7 Jun 2017 10:32:04 -0400 (EDT) From: Thomas Monjalon To: Jasvinder Singh Cc: dev@dpdk.org, cristian.dumitrescu@intel.com, ferruh.yigit@intel.com, hemant.agrawal@nxp.com, Jerin.JacobKollanukkaran@cavium.com, wenzhuo.lu@intel.com Date: Wed, 07 Jun 2017 16:32:03 +0200 Message-ID: <3485754.OcGeoT3SaN@xps> In-Reply-To: <20170526181149.44085-1-jasvinder.singh@intel.com> References: <20170526181149.44085-1-jasvinder.singh@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: Wed, 07 Jun 2017 14:32:05 -0000 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? > 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?