From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH] igb_uio: prevent reset for a list of devices
Date: Sat, 04 Nov 2017 00:03:32 +0100
Message-ID: <2051591.HpGYabZJN9@xps>
References: <20171103223822.28852-1-ferruh.yigit@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, Jianfeng Tan <jianfeng.tan@intel.com>,
 Jingjing Wu <jingjing.wu@intel.com>,
 Shijith Thotton <shijith.thotton@caviumnetworks.com>,
 Gregory Etelson <gregory@weka.io>, Harish Patil <harish.patil@cavium.com>,
 George Prekas <george.prekas@epfl.ch>,
 Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>,
 Rasesh Mody <rasesh.mody@cavium.com>, Lee Roberts <lee.roberts@hpe.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
 [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id DF65F1B6A3
 for <dev@dpdk.org>; Sat,  4 Nov 2017 00:03:35 +0100 (CET)
In-Reply-To: <20171103223822.28852-1-ferruh.yigit@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

03/11/2017 23:38, Ferruh Yigit:
> Some devices are having problem on device reset that happens during DPDK
> application exit [1].
> 
> Create a static list of devices and exclude them from device reset.
[...]
> This is alternative approach to
> http://dpdk.org/dev/patchwork/patch/31144/

It is better to change the behaviour only for the misbehaving device,
as it is done with this alternative.

However as far as I understand, the change is removing a long delay due
to the reset, but re-enable a security hole due to the lack of reset.
So I think we must have a compilation option anyway, in order to let
the packager (or distribution) make this difficult decision.
The compilation option could be something like
	RTE_BNX2X_PREFER_SECURITY_HOLE_THAN_LONG_RESTART
Feel free to find a better name :)