From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 355951C882 for <dev@dpdk.org>; Mon, 14 May 2018 16:16:03 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BD0D422316; Mon, 14 May 2018 10:16:02 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 14 May 2018 10:16:02 -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; s=mesmtp; bh=gOhL+P6C+QZvGQa5qPx/I3gLJr TzPQijqCJFAXvuokE=; b=aqbxOwyG9vC496oHQ6VJHcsxaZimzQ7SG2bqiDboHa Id4Vd/ushpV9kLwMVrwOfXsertQMv9xqA3herFQlmufMvzcqXPmSj/r/G30GDTJZ W7Ba6GsX5EKJ+HxidRVTmbnHp6y80AR3htPos8OdWhaljIUQFeWXnAyaL47Ue3yr w= 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; s=fm2; bh=gOhL+P 6C+QZvGQa5qPx/I3gLJrTzPQijqCJFAXvuokE=; b=Ql0uA2KaMKNJrjOi4SODyP wE+npNAmrUHWDVTvva7eNR4qUSJkgXMBiYmVN7cgOTP6oj3ScTUq9asQXGH+u4U/ Wk9WOBATVGbBu9qJG08zZsAmIR3UzsVMknvyCGNqUoTQd1sX5Hyr9Besg8emqWOF WnqprML3OdChHrpfYVIVzJ/OcJyKZ2cEi45tgcf9KTFuj+op9daKINYYWGtmD63E l1ym6KGBGGooELMisIY5NEgL3J1QTbUsPK8EeQGENLxKvu3lRFuomITM/LXOIEmV JMmqJvf0VxygwQBogYXhd7bh0pwR0BvH9dXya51tqeCPQ51O7ofd0cE836EyYmiw == X-ME-Sender: <xms:Ipr5WqE1j344hmAPy6JcjknPZkoMypf1JGz0gUiIHFkNctUZhLG6Hw> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id CE1FBE50A6; Mon, 14 May 2018 10:16:01 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Ferruh Yigit <ferruh.yigit@intel.com>, Shahaf Shuler <shahafs@mellanox.com>, Andrew Rybchenko <arybchenko@solarflare.com> Cc: Wei Dai <wei.dai@intel.com>, "dev@dpdk.org" <dev@dpdk.org> Date: Mon, 14 May 2018 16:15:59 +0200 Message-ID: <2214189.LTvPZJhkzD@xps> In-Reply-To: <0b7a04a0-c12b-829f-2cac-7a00e6308fab@intel.com> References: <a3aae93d-3293-2644-0d16-6d9af711d2ff@solarflare.com> <DB7PR05MB4426FC491099DB3D5AFDAF8CC39C0@DB7PR05MB4426.eurprd05.prod.outlook.com> <0b7a04a0-c12b-829f-2cac-7a00e6308fab@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] Rx/Tx offloads checks behaviour in 18.05 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Mon, 14 May 2018 14:16:03 -0000 14/05/2018 16:10, Ferruh Yigit: > On 5/14/2018 11:19 AM, Shahaf Shuler wrote: > > Monday, May 14, 2018 1:00 PM, Ferruh Yigit: > >>> > >>> It depends on which PMD is used. Yes, it was no checks in ethdev before. > >>> If PMD does not support multi-segment Tx, some checksum or VLAN > >>> insertion offload, but application requests it and rely on it, it will > >>> result in invalid packets sent to network. > >>> > >>> I realize that some applications may simply use empty txq_flags, but > >>> do not use any offloads in fact. If so, such PMDs will fail to setup > >>> TxQ if checks are made fatal, return error and underlying PMD does not > >>> support these offloads. > >>> > >>> At least it is safer behaviour than transmitting garbage. > >>> Yes, not easy decision. > >>> > >>> I will publish my patches which passed our tests. > >>> > >>> > >>> > >>> I agree with Andrew here. Even though there is a concern about the > >>> existing application we cannot use only logging. > >>> > >>> It is better to enforce the right behavior rather than having wrong > >>> configuration silently accepted by the PMD. > >> > >> What do you think send an error for the application that switch to new > >> offloading API and only print error log for the old ones. I believe we can > >> detect this via ETH_TXQ_FLAGS_IGNORE and ignore_offload_bitfield. > >> > >> And we will already force old applications to switch to new API next release, > >> next release we can introduce return error without condition. > >> Does it make sense? > > > > The issue is currently none of the PMDs verify the offloads v.s. the caps as ethdev layer does it. > > We cannot have offload to be set if it is not supported, even under the old API. allowing such breach on ethdev means we need to enforce it back again on each PMD. > > Hi Shahaf, Andrew, > > Thank you for sharing your concern I agree this is a valid one and thanks for > the solution provided. > > Ethdev configure() and queue_setup() are two common functions used for almost > all (if not all) DPDK networking applications, independent from they are > interested in offloading or not. > I am not comfortable on possibility to break them when we already scheduled a > break next release withing the process. > > With Wei's latest updates within comment it mentions return error will be added > in next release, this is good from documenting intention point of view. > > > With taking the pressure to close the v18.05 I am for getting offloading patch > as it is and reject Andrew's update. > And do new offloading API related work, including adding these returns, early in > next release (18.08) It is a really difficult decision, but I agree with Ferruh. We discussed it and we cannot take more risk in 18.05, even if it is a bad choice from API perspective. Thank you Andrew, and let's fix it in early days of 18.08.