DPDK patches and discussions
 help / color / mirror / Atom feed
From: Chas Williams <3chas3@gmail.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Declan Doherty <declan.doherty@intel.com>,
	dev@dpdk.org,  Ferruh Yigit <ferruh.yigit@intel.com>,
	Tomasz Kulasek <tomaszx.kulasek@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2] net/bonding: fix link status check
Date: Mon, 12 Feb 2018 13:26:45 -0500	[thread overview]
Message-ID: <CAG2-Gk=pHUSfmRRm6--TLam=zzzJEpvbjC6LUb61a8qgJfx-eQ@mail.gmail.com> (raw)
In-Reply-To: <7290841.LMfcIyB1JH@xps>

It's not clear to me that link_properties_valid() is even correct.  Nothing
prevents an adapter from later negotiating a lower speed and would fail
this test.  If both adapters are set to autoneg, that should be sufficient
but nothing enforces the speed match after the slaves are configured.  So
what is the point of this check?

On Tue, Feb 6, 2018 at 3:52 PM, Thomas Monjalon <thomas@monjalon.net> wrote:

> 17/01/2018 17:02, Ferruh Yigit:
> > On 11/29/2017 3:42 PM, Tomasz Kulasek wrote:
> > > Some devices needs more time to initialize and bring interface up. When
> > > link is down the link properties are not valid, e.g. link_speed is
> > > reported as 0 and this is not a valid speed for slave as well as for
> whole
> > > bonding.
> > >
> > > During NIC (and bonding) initialization there's concurrency between
> > > updating link status and adding slave to the bonding.
> > >
> > > This patch:
> > >
> > >  - adds delay before configuring bonding (if link is down) to be sure
> that
> > >    link status of new slave is valid,
> > >  - propagates information about link status from first slave with link
> up
> > >    instead of first slave at all, to be sure that link speed is valid.
> > >
> > > Fixes: 6abd94d72ab5 ("net/bonding: fix check slaves link properties")
> > > Signed-off-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
> > > ---
> > > v2 changes:
> > >  - Checkpatch warnings,
> > >  - Improved code style
> > Hi Declan,
> >
> > Any comment on this patch?
>
> Any news?
>
>
>

  reply	other threads:[~2018-02-12 18:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-29 14:53 [dpdk-dev] [PATCH] " Tomasz Kulasek
2017-11-29 15:42 ` [dpdk-dev] [PATCH v2] " Tomasz Kulasek
2018-01-17 16:02   ` Ferruh Yigit
2018-02-06 20:52     ` Thomas Monjalon
2018-02-12 18:26       ` Chas Williams [this message]
2018-06-13 16:10         ` Ferruh Yigit
2018-06-18  8:39           ` Ferruh Yigit
2018-02-16 20:13   ` Stephen Hemminger

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-Gk=pHUSfmRRm6--TLam=zzzJEpvbjC6LUb61a8qgJfx-eQ@mail.gmail.com' \
    --to=3chas3@gmail.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=thomas@monjalon.net \
    --cc=tomaszx.kulasek@intel.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).