From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] ethdev: fix applications failure on configure Date: Wed, 02 May 2018 12:06:11 +0200 Message-ID: <4396631.OICrUNRNKa@xps> References: <20180501133343.125260-1-ferruh.yigit@intel.com> <68310139-6baf-baab-bbe9-3da0883960bc@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org To: "Xueming(Steven) Li" , Ferruh Yigit Return-path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 69ED323C for ; Wed, 2 May 2018 12:06:13 +0200 (CEST) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 02/05/2018 11:58, Xueming(Steven) Li: > From: Ferruh Yigit > > Or as Xueming suggested, we can take rss_hf config as best effort and not return error at all. > > > > I think this forces PMDs to have up-to-date flow_type_rss_offloads values, is there any other benefit? > > What was the initial motivation to add error return on this check? > > The original idea is to add rss_hf check on mlx5 PMD, while it looks more generic > to move the check to ethdev api from discussion[1]. > > [1] http://www.dpdk.org/ml/archives/dev/2018-April/095136.html I think it is not correct to not return an error when the app request an offload which is not supported. Do we agree to work on PMDs and applications to fix this offload compliance? And submit a deprecation notice to return an error in a later release?