From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ferruh.yigit@intel.com>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id 0F0991B6C8;
 Sat,  4 Nov 2017 00:28:58 +0100 (CET)
Received: from fmsmga002.fm.intel.com ([10.253.24.26])
 by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 03 Nov 2017 16:28:57 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.44,339,1505804400"; d="scan'208";a="1239543621"
Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.241.225.48])
 ([10.241.225.48])
 by fmsmga002.fm.intel.com with ESMTP; 03 Nov 2017 16:28:57 -0700
To: Thomas Monjalon <thomas@monjalon.net>, Ophir Munk <ophirmu@mellanox.com>
Cc: dev@dpdk.org, stable@dpdk.org
References: <1509567158-15670-1-git-send-email-ophirmu@mellanox.com>
 <1509643623-10488-1-git-send-email-ophirmu@mellanox.com>
 <1557050.xg2fuQA1dT@xps>
From: Ferruh Yigit <ferruh.yigit@intel.com>
Message-ID: <93449286-352e-d632-fbae-970f52b861fe@intel.com>
Date: Fri, 3 Nov 2017 16:28:56 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <1557050.xg2fuQA1dT@xps>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2] net/failsafe: fix VLAN
 stripping configuration
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/stable>,
 <mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/stable>,
 <mailto:stable-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2017 23:28:59 -0000

On 11/3/2017 4:11 PM, Thomas Monjalon wrote:
> 02/11/2017 18:27, Ophir Munk:
>> failsafe device has vlan stripping configured at startup however once
>> a sub device is found as non-capable of vlan-stripping failsafe
>> updates it configuration and removes vlan stripping from it.
>> This update occurs only once at startup. Following a later plugin
>> attempt and in case of vlan stripping mismatch between failsafe
>> configuration and device capability - failsafe cannot recover and the
>> device remains constantly in plug out state.
>>
>> The sequence of events leading to this situation is described as
>> follows:
>> 1. Start testpmd with failsafe where mlx4 is a sub device (not capable
>> of vlan stripping). Expected printout:
>> PMD: net_failsafe: Disabling VLAN stripping offload
>> 2. Execute:
>> testpmd> port stop all
>> testpmd> port config all max-pkt-len 2048
>> testpmd> port start all
>> 3. Do a plug out (e.g. disable sriov)
>> 4. Do a plug in (e.g. enable sriov)
>> 5. Expected result: failsafe successfully configures and starts its sub
>> devices
>> Actual result: failsafe is continuously failing with these messages:
>> PMD: net_failsafe: VLAN stripping offload requested but not supported by
>> sub_device 0
>> PMD: net_failsafe: device already configured, cannot fix live
>> configuration
>> PMD: net_failsafe: Unable to synchronize sub device state
>>
>> Root cause analysis: at startup failsafe removes vlan stripping from its
>> configuration. After executing "port config all max-pkt-len 2048"
>> testpmd marks failsafe in need for configuration update.
>> After executing "port start all" testpmd overrides failsafe
>> configuration with its own configuration which includes vlan stripping
>>
>> During the plugin attempt failsafe refuses to update its configuration
>> by removing vlan stripping since it has already updated its
>> configuration at startup.
>>
>> The fix is for failsafe to stop validation and disabling non-supported
>> offloads in its sub-devices.
>>
>> Cc: stable@dpdk.org
>> Fixes: bbc6a53dda44 ("net/failsafe: support Rx offload capabilities")
> 
> The Cc:stable line is usually below the Fixes: line.
> 
>> Signed-off-by: Ophir Munk <ophirmu@mellanox.com>
> 
> The fix in this v2 matches what Gaetan requested after v1.
> 
> I agree it is better that failsafe does not interfere in configurations.
> The responsibility of failsafe is to build the capability set.
> The responsibility of the application is to check the capabilities
> before configuring the failsafe device (like any other device).
> 
> Acked-by: Thomas Monjalon <thomas@monjalon.net>

Applied to dpdk-next-net/master, thanks.