From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <3chas3@gmail.com>
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com
[209.85.223.177]) by dpdk.org (Postfix) with ESMTP id B1B301CC65;
Thu, 5 Apr 2018 17:02:00 +0200 (CEST)
Received: by mail-io0-f177.google.com with SMTP id 141so30958184iou.12;
Thu, 05 Apr 2018 08:02:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=uhUp+P6/9++0VyWeaCVTgneSvbyhWeDHcKFAImAzgJo=;
b=fv9fXj/9Ka09BPTHh6EN9/GKJRxGNtl82ieXgK0wTQNXNd4fU4nIycNlAyILJ+jSl9
7MGDjQkgfHlmq6Yk6xFDa66c/Y31OEuB60iZ6Kjdqz1POaRFEASiuo5vc9F9CcnHkIdg
2+QEOmam8amVqFh3y42AWJCVEtCvUTmMLRV47mnMhqWHc4lLb8v8E4jXyCuIWcoJdD7+
aIC7x3ZGvKEnRqDSHVNwX7aGaM8SkMnu7hLXJ2YrzV68IlZuL8ZcsMpQa4DiPWX8OfaR
iYxKQUQJ8l9lOx/zctyRBrqE4yAx2WNpGOPSzMDbxJOWkBAz+3uN6fcn+i58iC6HetLa
xioA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=uhUp+P6/9++0VyWeaCVTgneSvbyhWeDHcKFAImAzgJo=;
b=UL8UW+W+xhj1wvkG/0/Uj0V0iMwUfv+5Fbz+6ExwgMvsXGb2DLRdI9+ZYRbBGDGn0D
K16SegyEIFDLmu46uq9kVtfXffdu/7yPRkiMtGKHKN2PJHf25dcSMU4USP2xxQErKk+1
l6RI/agHxpOuH5ByfDBgoAS2drd3sx/kxsSgXW4a9fndOXPJ98rOZ6YaQKur2SkWlrjv
+GvUGJrGHWmknlG9he5pZ8GpZ+iUEMJuMq3jmHFTr4m4S+Ut4qGQHJJdLt4qq0xxDoO+
oVBTU72hTW3pfq7Wkh7ynwfDDVElV/kxA7oDEbi9UB4vux1fQOjQAusNjCYGDnoObRsP
GhzA==
X-Gm-Message-State: ALQs6tB1VlBH8twTP7zkzGg5LXD1m/arLuiLXjL9p/Sk8Syk5wr3+I+3
VycDgIduQPEOGBbZx+e3yUoIQAy1p4xKGHKB2wc=
X-Google-Smtp-Source: AIpwx49iMZZ6nsosNhonmvPegEcdMtq3uMbgPglSPzPgO1Xcmg1ms9eAYXxyxK0m7KTlael0Fnump/b7jv4Pt0QD/24=
X-Received: by 10.107.93.23 with SMTP id r23mr1130902iob.2.1522940519600; Thu,
05 Apr 2018 08:01:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.160.69 with HTTP; Thu, 5 Apr 2018 08:01:59 -0700 (PDT)
In-Reply-To: <1549783.CbrISpF0YD@xps>
References: <20180318014552.16703-1-3chas3@gmail.com>
<c7a2017c-c78b-4b7c-a7a5-6e172724d4a1@intel.com>
<1549783.CbrISpF0YD@xps>
From: Chas Williams <3chas3@gmail.com>
Date: Thu, 5 Apr 2018 11:01:59 -0400
Message-ID: <CAG2-Gk=iqowLDZ2fFqa_5K437g+uFjTCiaJYiKCBV29uA5g3Xw@mail.gmail.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Chas Williams <chas3@att.com>, dev@dpdk.org,
Ferruh Yigit <ferruh.yigit@intel.com>, skhare@vmware.com, stable@dpdk.org
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] net/vmxnet3: keep link state
consistent
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 15:02:01 -0000
On Thu, Apr 5, 2018 at 6:03 AM, Thomas Monjalon <thomas@monjalon.net> wrote:
> 20/03/2018 15:12, Ferruh Yigit:
>> On 3/18/2018 1:45 AM, Chas Williams wrote:
>> > From: Chas Williams <chas3@att.com>
>> >
>> > The vmxnet3 never attempts link speed negotiation. As a virtual device
>> > the link speed is vague at best. However, it is important for certain
>> > applications, like bonding, to see a consistent link_status. 802.3ad
>> > requires that only links of the same cost (link speed) be enslaved.
>> > Keeping the link status consistent in vmxnet3 avoids races with bonding
>> > enslavement.
>
> I don't understand the issue.
> Are you sure it is not an issue in bonding?
802.3ad "requires" you to bond together links of the same speed and duplex. The
primary reason for this (or so I gather) is to ensure that the
spanning-tree cost for
each port is the same. If you fail from one link to another, you
don't want a spanning
tree reconfiguration.
The problem exists in general for most of the PMDs -- see
https://dpdk.org/ml/archives/dev/2018-April/094696.html
The problem is more vexing for AUTONEG and bonding. I am still thinking about
that. You don't know until you go to activate the slave and bonding
only makes its
check during the setup phase. So for virtual adapters and bonding, not using
AUTONEG makes more sense because it is just easier to handle.
>
> About the right value to set for virtual PMDs, I don't know, both are fakes.
> I thought that AUTONEG better convey the vague link speed you describe.
It's not vague. There is no negotiation of any sort. The link speed
(and therefore cost)
of the link is fixed. While the particular rate you get from the
adapter depends
on a number of factors, the link speed isn't going to change. The
adapter is not
going to change the link speed from 10G to 1G or change from full duplex to half
duplex.
>
>
>> > Author: Thomas Monjalon <thomas@monjalon.net>
>> > Date: Fri Jan 5 18:38:55 2018 +0100
>> >
>> > Fixes: 1e3a958f40b3 ("ethdev: fix link autonegotiation value")
>> > Cc: stable@dpdk.org
>>
>> There were a few more PMDs [1] they have been updated from FIXED to AUTONEG with
>> above commit, do you think should we update them back to FIXED as well?
>>
>> [1]
>> pcap
>> softnic
>> vmxnet3
>
> Yes, they all can be fixed/LINK_FIXED :) I guess
>
>
>