DPDK patches and discussions
 help / color / mirror / Atom feed
From: Chas Williams <3chas3@gmail.com>
To: Matan Azrad <matan@mellanox.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"declan.doherty@intel.com" <declan.doherty@intel.com>,
	 "Charles (Chas) Williams" <chas3@att.com>
Subject: Re: [dpdk-dev] [PATCH] net/bonding: don't clear active slave count
Date: Wed, 6 Jun 2018 10:28:12 -0400	[thread overview]
Message-ID: <CAG2-Gkn8he5j5mH2aznbLjzP-fL8G12xVY4iVb_ybJaVAt0KDw@mail.gmail.com> (raw)
In-Reply-To: <VI1PR0501MB26082387584B13F14FE7EC70D2650@VI1PR0501MB2608.eurprd05.prod.outlook.com>

On Wed, Jun 6, 2018 at 9:57 AM, Matan Azrad <matan@mellanox.com> wrote:

> Hi Chas
>
> From: Chas Williams
> > From: "Charles (Chas) Williams" <chas3@att.com>
> >
> > When the bond PMD is stopped, the active slave count is reset.
> > For 802.3ad mode this potentially leaks memory and clears state since a
> second
> > sequential activate_slave() will occur when the bond PMD is restarted
> and the
> > LSC callback is triggered while the active slave count is 0. To fix
> this, don't clear
> > the active slave count when stopping. Only deactivate_slave() should be
> used to
> > clear the slaves.
> >
>
> Looks like it is a fix, so need fix title, CC stable and fixes line, no?
>

Yes, I forgot to add those.  Let's call it an RFC for now.  It's not
completely clear to
me what is the right thing to do here.  The activate state of slaves is
really dependent
on the link status of the slaves.  Does a PMD have a link status outside of
a start/stop
sequence?  Or, since we clear the last_status on stop, the start will just
get all the
activate/deactivate states corrected.  Since we might stop/start for a
short interval,
it seems like we might not want to break what 802.3ad has negotiated?


>
> > Signed-off-by: Chas Williams <chas3@att.com>
> > ---
> >  drivers/net/bonding/rte_eth_bond_pmd.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
> > b/drivers/net/bonding/rte_eth_bond_pmd.c
> > index 02d94b1b1..4ae577078 100644
> > --- a/drivers/net/bonding/rte_eth_bond_pmd.c
> > +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
> > @@ -2173,7 +2173,6 @@ bond_ethdev_stop(struct rte_eth_dev *eth_dev)
> >                       tlb_last_obytets[internals->active_slaves[i]] = 0;
> >       }
> >
> > -     internals->active_slave_count = 0;
>
> But why not to call deactivate_slave() for all the active slaves?
>
> >       internals->link_status_polling_enabled = 0;
> >       for (i = 0; i < internals->slave_count; i++)
> >               internals->slaves[i].last_link_status = 0;
> > --
> > 2.14.3
>
>
>

  reply	other threads:[~2018-06-06 14:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-06 12:26 Chas Williams
2018-06-06 13:57 ` Matan Azrad
2018-06-06 14:28   ` Chas Williams [this message]
2018-07-04  2:28 ` [dpdk-dev] [PATCH v2] " Chas Williams
2018-07-05 12:42   ` [dpdk-dev] [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=CAG2-Gkn8he5j5mH2aznbLjzP-fL8G12xVY4iVb_ybJaVAt0KDw@mail.gmail.com \
    --to=3chas3@gmail.com \
    --cc=chas3@att.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=matan@mellanox.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).