All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ophir Munk <ophirmu@mellanox.com>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	Thomas Monjalon <thomas@monjalon.net>,
	"Olga Shern" <olgas@mellanox.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [PATCH v1] net/failsafe: fix VLAN stripping configuration
Date: Fri, 3 Nov 2017 09:52:28 +0000	[thread overview]
Message-ID: <DB5PR05MB1254F1006294AAA12F9EFDF3D15D0@DB5PR05MB1254.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <20171102141623.GL10890@bidouze.vm.6wind.com>

Hi,
Please see below

> -----Original Message-----
> From: Gaëtan Rivet [mailto:gaetan.rivet@6wind.com]
> Sent: Thursday, November 02, 2017 4:16 PM
> To: Ophir Munk <ophirmu@mellanox.com>
> Cc: dev@dpdk.org; Thomas Monjalon <thomas@monjalon.net>; Olga Shern
> <olgas@mellanox.com>; stable@dpdk.org
> Subject: Re: [PATCH v1] net/failsafe: fix VLAN stripping configuration
> 
> On Thu, Nov 02, 2017 at 02:52:16PM +0100, Gaëtan Rivet wrote:
> > On Wed, Nov 01, 2017 at 08:12:38PM +0000, Ophir Munk wrote:
> > > 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 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
> > >
> >
> > Have you tried launching testpmd with the option
> >
> > "--disable-hw-vlan"
> >
> > as your mlx4 port does not support it?
> >
> 
> On a second thought, I think there is a simple solution:
> 
> The fail-safe should stop trying to be clever with port configuration.
> On rte_eth_dev_configure, simply apply the user configuration (without
> trying to detect support and disabling flags on the fly).
> 
> If a PMD has an issue, it should warn the user. If it has an issue but does not
> warn, it is a bug for this PMD. This is the case for MLX4:
> either the PMD changes its behavior, or not, as long as users are fine with it.
> 
> So a proper fix would be to remove the checks (fs_port_offload_validate and
> fs_port_disable_offload) and depend on the sub-device for proper
> configuration vetting.
> 
> Thoughts?

Agreed. I have sent v2 based on your suggestion. 

> 
> > > 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 to remove the limitation of one time configuration at
> > > startup and allow it during plugin attempts.
> > >
> > > Cc: stable@dpdk.org
> > > Fixes: bbc6a53dda44 ("net/failsafe: support Rx offload
> > > capabilities")
> > >
> > > Signed-off-by: Ophir Munk <ophirmu@mellanox.com>
> > > ---
> > > The commit message includes bug and fix descriptions
> > > ---
> > >  drivers/net/failsafe/failsafe_ops.c | 10 ----------
> > >  1 file changed, 10 deletions(-)
> > >
> > > diff --git a/drivers/net/failsafe/failsafe_ops.c
> > > b/drivers/net/failsafe/failsafe_ops.c
> > > index f460551..953ee65 100644
> > > --- a/drivers/net/failsafe/failsafe_ops.c
> > > +++ b/drivers/net/failsafe/failsafe_ops.c
> > > @@ -187,16 +187,6 @@
> > >  			continue;
> > >  		DEBUG("Checking capabilities for sub_device %d", i);
> > >  		while ((capa_flag = fs_port_offload_validate(dev, sdev))) {
> > > -			/*
> > > -			 * Refuse to change configuration if multiple devices
> > > -			 * are present and we already have configured at
> least
> > > -			 * some of them.
> > > -			 */
> > > -			if (PRIV(dev)->state >= DEV_ACTIVE &&
> > > -			    PRIV(dev)->subs_tail > 1) {
> > > -				ERROR("device already configured, cannot
> fix live configuration");
> > > -				return -1;
> > > -			}
> > >  			ret = fs_port_disable_offload(&dev->data-
> >dev_conf,
> > >  						      capa_flag);
> > >  			if (ret) {
> > > --
> > > 1.8.3.1
> > >
> >
> > --
> > Gaëtan Rivet
> > 6WIND
> 
> --
> Gaëtan Rivet
> 6WIND

  reply	other threads:[~2017-11-03  9:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-01 20:12 [PATCH v1] net/failsafe: fix VLAN stripping configuration Ophir Munk
2017-11-02 13:52 ` Gaëtan Rivet
2017-11-02 14:16   ` Gaëtan Rivet
2017-11-03  9:52     ` Ophir Munk [this message]
2017-11-02 17:27 ` [PATCH v2] " Ophir Munk
2017-11-03 23:11   ` Thomas Monjalon
2017-11-03 23:28     ` [dpdk-stable] " Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB5PR05MB1254F1006294AAA12F9EFDF3D15D0@DB5PR05MB1254.eurprd05.prod.outlook.com \
    --to=ophirmu@mellanox.com \
    --cc=dev@dpdk.org \
    --cc=gaetan.rivet@6wind.com \
    --cc=olgas@mellanox.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.