From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 03633C44E for ; Thu, 23 Jun 2016 14:21:51 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id a66so47506398wme.0 for ; Thu, 23 Jun 2016 05:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=X5SjIIUr/c9eehckk4Xp1AGP06yyD7d/ycmOc4emY+s=; b=kom0N58+5cN3tb4qRdaREOqbtQDcajdsG7mAQEbP0+S2LU4dhPEj+YhSh4/XrxX/ss tvEpd2zs5LK5GL1llygCSAJZhUL9z88C5ZfGPmOtiOX5hlDSunIQl/S1lR3hfwMa7N+c iSTcWweIzn3Q+Cy9RBQUbHSWZDMnNxJlA0sQzWqeYEHSulOdjKJX1YU2ANpMkw0BBoU7 fDO/wRkm6yRfK8mb75SnhUNUPoYxBMwDWDj7Ov5PKUbbpHiqbjQsxJ0QO47n13vewa2M uT6x7TNTrwMuJTU75Ki1Xd3dwGsUb1Cti4whWYtF3gvXUStww4D2miVnvkuX1Bc3HfWg r6sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=X5SjIIUr/c9eehckk4Xp1AGP06yyD7d/ycmOc4emY+s=; b=Vn1glbZKD3NDFjBR5l3Qul2tgCRDUSBx54uDSh3/KloCVKErLlhH+t2jcIUfwT82x3 lvpykj9HRfQ+Uau7TJd8J9kuKwg//2r1x5/fg1SE2vd1iTV+VAtxjEyOut8/1BqbKgB+ Okmq0GCFnGceU2mF0HFqhE2y8p0MWftnUaDXTsfaF7NephKPhUBY759xZ3uxJVd7yeNK iRJFY8NkJT8TyLX5UdBXnFz4qyMBFrLrkQwuqBSMe5tWHJu5oQ60gCC4YBZMs2kaDg+J fHzW5ntk3Ds41OYPAI8zMLi/A9y9jtcHjdh62hej9A8461c2IN595yHCo3ySBw311pmY rNQg== X-Gm-Message-State: ALyK8tKeETiPqBgpAeTCOdBhrHQULewdeDihyMbDLM421xPDG7SSLbNSTo4fdj32zF8kxJ5b X-Received: by 10.28.67.69 with SMTP id q66mr13189977wma.81.1466684510174; Thu, 23 Jun 2016 05:21:50 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id p6sm3660340wme.22.2016.06.23.05.21.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jun 2016 05:21:49 -0700 (PDT) From: Thomas Monjalon To: "Lu, Wenzhuo" Cc: dev@dpdk.org Date: Thu, 23 Jun 2016 14:21:48 +0200 Message-ID: <3037324.FL8zRspYFl@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC090903489DBD@shsmsx102.ccr.corp.intel.com> References: <1460363050-27962-1-git-send-email-wenzhuo.lu@intel.com> <1871393.ccgjmFpxqt@xps13> <6A0DE07E22DDAD4C9103DF62FEBC090903489DBD@shsmsx102.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3] ethdev: fix DCB config issue on ixgbe X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 12:21:51 -0000 2016-06-23 01:04, Lu, Wenzhuo: > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2016-05-06 05:33, Wenzhuo Lu: > > > +int > > > +rte_eth_dev_mq_mode_set(uint8_t port_id, > > > + enum rte_eth_rx_mq_mode rx_mq_mode, > > > + enum rte_eth_tx_mq_mode tx_mq_mode); > > > > I've really tried to think about it and I think it is more or less a hack. > > First, it is not explained in the doc when we should use > > rte_eth_dev_mq_mode_set() instead of a simple call to rte_eth_dev_configure(). > > Second, I don't understand why having a function which configures the > > "multiqueue modes" without configuring properly RSS/VMDq/DCB. > > Last, it is said that rte_eth_dev_configure() "must be invoked first before any > > other function in the Ethernet API". > Sorry, didn't notice this announcement. > > > My opinion is that the primary goal of rte_eth_dev_configure() was "Embedding > > all configuration information in a single data structure" > > but it is currently configuring only speed and some flow steering (only RSS, > > VMDq, DCB and flow director). > > This bug and the state of the ethdev API clearly shows that we must have one > > function per feature (or group of features) and drop rte_eth_dev_configure(). > > > > You can argue it is a just a personal feeling and this comment comes late, but I > > promise it is not easy to give a negative opinion because of design perspective. > > I strongly feel we must stop workarounding the ethdev API issues and start really > > fixing it. > > > > Hope you understand and agree to work on a new API. > I have the same feeling with you. There's some problem with rte_eth_dev_configure. So this patch is a workaround more than a real fix. > But the problem is this API has already been used. What I think is could we take this workaround as a first step. It need not ask the APP to change too much. > Then we can discuss how could we rework on a new API or APIs. We all know the change in rte layer is not easy and need to be very careful :) We probably need more opinions. I think it is not a good idea to introduce a new API only to workaround another one and keep confusion in place. A similar approach which looks better is to introduce a new API which will partly replace the old one and will remain a good one when the old API will be completely removed. In other words, we should introduce a good API for flow steering as soon as possible and deprecate rte_eth_dev_configure().