From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 7A2731B6C2; Sat, 4 Nov 2017 00:11:14 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BC76320C00; Fri, 3 Nov 2017 19:11:13 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 03 Nov 2017 19:11:13 -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=8a79reFcc/KGfubVCRX5D70bq1 maplXTAUBmq9GYK1c=; b=QWQXMNf05HOa8WtG8TfupjOvjLkgiroR4CQ/T91K4w hN3lhiblr4WQFN3v3Zd65zjedQd7PhxmHu0KNZcbHVyBz210giXoE9SPBwfgxFAU +AxUPHAL8LMqrIgZtyyQlw+TCHEU3kYbcfcpgLBIT1YK3W0akCv3D0UsrCaioSXa A= 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=fm1; bh=8a79re Fcc/KGfubVCRX5D70bq1maplXTAUBmq9GYK1c=; b=fW5hLzdBUo9EmMH6aTfJtz x/g+m85CwYPDLR4BavqGLOYgMuPlkah9xtPpDzZs6NiPJ+YbyuWuhUl+8AxBSZAh +aYEcnJVTgNRq5GH7XMj5T5jvCBbIK89UihvVJf40N6xz+3/fdsrQcuVkAXEAAO6 psr3yweHi6l7LoyQtCR2oRWsTlqREEQb0ZlDWXoolQHzHFvs13zQPYyAfC+64GyX PtzrCW/XQciG0uJQif23Pf2+XX8rRblIYViJ3qVc011QDv+7wgJHUZkjqSHlqDvu ERJ4ADaVPMioBOKbr9BNi4gkXSWf/A5agYIMWq1OB7vfYMrZ3u4Sx01DuwaiSqlw == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7ACA22489B; Fri, 3 Nov 2017 19:11:13 -0400 (EDT) From: Thomas Monjalon To: Ophir Munk Cc: dev@dpdk.org, stable@dpdk.org Date: Sat, 04 Nov 2017 00:11:12 +0100 Message-ID: <1557050.xg2fuQA1dT@xps> In-Reply-To: <1509643623-10488-1-git-send-email-ophirmu@mellanox.com> References: <1509567158-15670-1-git-send-email-ophirmu@mellanox.com> <1509643623-10488-1-git-send-email-ophirmu@mellanox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] net/failsafe: fix VLAN stripping configuration X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 23:11:14 -0000 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 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