netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: zhuyj <zyjzyj2000@gmail.com>
To: "Tantilov, Emil S" <emil.s.tantilov@intel.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
	"Nelson, Shannon" <shannon.nelson@intel.com>,
	"Wyborny, Carolyn" <carolyn.wyborny@intel.com>,
	"Skidmore, Donald C" <donald.c.skidmore@intel.com>,
	"Allan, Bruce W" <bruce.w.allan@intel.com>,
	"Ronciak, John" <john.ronciak@intel.com>,
	"Williams, Mitch A" <mitch.a.williams@intel.com>,
	"intel-wired-lan@lists.osuosl.org"
	<intel-wired-lan@lists.osuosl.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"e1000-devel@lists.sourceforge.net"
	<e1000-devel@lists.sourceforge.net>
Cc: "Viswanathan,
	Ven \(Wind River\)" <venkat.viswanathan@windriver.com>,
	"Shteinbock,
	Boris \(Wind River\)" <boris.shteinbock@windriver.com>,
	"Bourg, Vincent \(Wind River\)" <vincent.bourg@windriver.com>
Subject: Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of link_up and speed
Date: Wed, 6 Jan 2016 13:41:39 +0800	[thread overview]
Message-ID: <568CA913.3030901@gmail.com> (raw)
In-Reply-To: <87618083B2453E4A8714035B62D67992504FD8D5@FMSMSX105.amr.corp.intel.com>

On 12/31/2015 12:37 AM, Tantilov, Emil S wrote:
>> -----Original Message-----
>> From: zhuyj [mailto:zyjzyj2000@gmail.com]
>> Sent: Wednesday, December 30, 2015 12:20 AM
>> To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
>> Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak,
>> John; Williams, Mitch A; intel-wired-lan@lists.osuosl.org;
>> netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net
>> Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River); Bourg,
>> Vincent (Wind River)
>> Subject: Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization
>> of link_up and speed
>>
>> On 12/30/2015 02:55 PM, Tantilov, Emil S wrote:
>>>> -----Original Message-----
>>>> From: zhuyj [mailto:zyjzyj2000@gmail.com]
>>>> Sent: Tuesday, December 29, 2015 6:49 PM
>>>> To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
>>>> Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak,
>>>> John; Williams, Mitch A; intel-wired-lan@lists.osuosl.org;
>>>> netdev@vger.kernel.org; e1000-devel@lists.sourceforge.net
>>>> Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River);
>> Bourg,
>>>> Vincent (Wind River)
>>>> Subject: Re: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict
>> synchronization
>>>> of link_up and speed
>>>>
>>>> On 12/30/2015 12:18 AM, Tantilov, Emil S wrote:
>>>>>> -----Original Message-----
>>>>>> From: Intel-wired-lan [mailto:intel-wired-lan-
>> bounces@lists.osuosl.org]
>>>> On
>>>>>> Behalf Of zyjzyj2000@gmail.com
>>>>>> Sent: Monday, December 28, 2015 6:32 PM
>>>>>> To: Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny,
>>>>>> Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak, John; Williams,
>>>> Mitch
>>>>>> A; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; e1000-
>>>>>> devel@lists.sourceforge.net
>>>>>> Cc: Viswanathan, Ven (Wind River); Shteinbock, Boris (Wind River);
>>>> Bourg,
>>>>>> Vincent (Wind River)
>>>>>> Subject: [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization
>>>> of
>>>>>> link_up and speed
>>>>>>
>>>>>> From: Zhu Yanjun <yanjun.zhu@windriver.com>
>>>>>>
>>>>>> When the X540 NIC acts as a slave of some virtual NICs, it is very
>>>>>> important to synchronize link_up and link_speed, such as a bonding
>>>>>> driver in 802.3ad mode. When X540 NIC acts as an independent
>> interface,
>>>>>> it is not necessary to synchronize link_up and link_speed. That is,
>>>>>> the time span between link_up and link_speed is acceptable.
>>>>> What exactly do you mean by "time span between link_up and link_speed"?
>>>> In the previous mail, I show you some ethtool logs. In these logs, there
>>>> is some
>>>> time with NIC up while speed is unknown. I think this "some time" is
>>>> time span between
>>>> link_up and link_speed. Please see the previous mail for details.
>>> Was this when reporting the link state from check_link() (reading the
>> LINKS
>>> register) or reporting the adapter->link_speed?
>>>
>>>>> Where is it you think the de-synchronization occurs?
>>>> When a NIC interface acts as a slave, a flag "IFF_SLAVE" is set in
>>>> netdevice struct.
>>>> Before we enter this function, we check IFF_SLAVE flag. If this flag is
>>>> set, we continue to check
>>>> link_speed. If not, this function is executed whether this link_speed is
>>>> unknown or not.
>>> I can already see this in your patch. I was asking about the reason why
>>> your change is needed.
>> an extreme example, let us assume this scenario:
> Is this the scenario you are trying to fix?
Sure. If IFF_SLAVE is checked, this scenario will not happen.

Zhu Yanjun
>
>> An ixgbe NIC directly connects to another NIC (let us call it NIC-a).
>> And auto-negotiate is off while no static speed is set in the 2 NICs.
> The ixgbe driver does not support disabling auto-negotiation directly.
> The only time this is true is when the advertised speed is restricted,
> so the above scenario is not possible (you either have autoneg or
> advertised speed set) with the current driver.
>
> Is this example in theory or do you have your interface configured this
> way somehow?
>
> Thanks,
> Emil
>
>


------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

  reply	other threads:[~2016-01-06  5:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-23  6:46 [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed and duplex zyjzyj2000
2015-12-23 10:54 ` Jeff Kirsher
2015-12-24  3:12   ` [V2 PATCH 1/1] ixgbe: force to synchronize reporting "link on" and zyjzyj2000
2015-12-24  3:12     ` [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed zyjzyj2000
2015-12-24  5:10     ` [V2 PATCH 1/1] ixgbe: force to synchronize reporting "link on" and zhuyj
2015-12-24  6:17       ` [Intel-wired-lan] " Tantilov, Emil S
2015-12-29  2:32     ` [PATCH V3] ixgbe: force to synchronize link_up and speed as a slave zyjzyj2000
2015-12-29  2:32       ` [PATCH 1/2] ixgbe: force to synchronize reporting "link on" and getting speed zyjzyj2000
2015-12-29  2:32       ` [PATCH 2/2] ixgbe: restrict synchronization of link_up and speed zyjzyj2000
2015-12-29 16:18         ` [Intel-wired-lan] " Tantilov, Emil S
2015-12-29 19:17           ` Rustad, Mark D
2015-12-30  3:06             ` zhuyj
2015-12-30  9:16             ` [PATCH V4] ixgbe: synchronize the link_speed and link_up of a slave interface zyjzyj2000
2015-12-30  9:16               ` [PATCH 1/3] ixgbe: force to synchronize reporting "link on" and getting speed zyjzyj2000
2015-12-30  9:16               ` [PATCH 2/3] ixgbe: restrict synchronization of link_up and speed zyjzyj2000
2015-12-30  9:16               ` [PATCH 3/3] ixgbe: synchronize the link_speed and link_up of a slave interface zyjzyj2000
2015-12-30 19:02                 ` Rustad, Mark D
2015-12-31  5:04                   ` [PATCH V5] ixgbe: synchronize link_up and link_speed of a slave zyjzyj2000
2015-12-31  5:04                     ` [PATCH 1/1] ixgbe: synchronize link_up and link_speed of a slave interface zyjzyj2000
2015-12-31  5:37                       ` Jeff Kirsher
2015-12-31  7:11                         ` [PATCH V6] ixgbe: synchronize link_up and link_speed of a slave zyjzyj2000
2015-12-31  7:11                           ` [PATCH V6 1/1] ixgbe: synchronize link_up and link_speed of a slave interface zyjzyj2000
2015-12-31  5:17                     ` [PATCH V5] ixgbe: synchronize link_up and link_speed of a slave Jeff Kirsher
2015-12-31  5:24                       ` zhuyj
2015-12-30  2:49           ` [Intel-wired-lan] [PATCH 2/2] ixgbe: restrict synchronization of link_up and speed zhuyj
2015-12-30  6:55             ` Tantilov, Emil S
2015-12-30  8:20               ` zhuyj
2015-12-30 16:37                 ` Tantilov, Emil S
2016-01-06  5:41                   ` zhuyj [this message]
2016-01-06 15:30                     ` Tantilov, Emil S
2016-01-07  2:08                       ` zhuyj
2016-01-07  2:38                       ` zhuyj
2015-12-23 12:17 ` [PATCH 1/1] ixgbe: force to synchronize reporting "link on" and getting speed and duplex Sergei Shtylyov
2015-12-23 15:59 ` [Intel-wired-lan] " Tantilov, Emil S
2015-12-23 18:09   ` [E1000-devel] " Stephen Hemminger
2015-12-24  2:27   ` zhuyj
2015-12-24  5:58     ` Tantilov, Emil S
2015-12-24  6:24       ` zhuyj
2015-12-24 14:52         ` Tantilov, Emil S

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=568CA913.3030901@gmail.com \
    --to=zyjzyj2000@gmail.com \
    --cc=boris.shteinbock@windriver.com \
    --cc=bruce.w.allan@intel.com \
    --cc=carolyn.wyborny@intel.com \
    --cc=donald.c.skidmore@intel.com \
    --cc=e1000-devel@lists.sourceforge.net \
    --cc=emil.s.tantilov@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=john.ronciak@intel.com \
    --cc=mitch.a.williams@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=shannon.nelson@intel.com \
    --cc=venkat.viswanathan@windriver.com \
    --cc=vincent.bourg@windriver.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).