All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] net/vmxnet3: keep link state consistent
@ 2018-03-18  1:45 Chas Williams
  2018-03-20 14:12 ` [dpdk-stable] " Ferruh Yigit
  2018-04-20  0:10 ` Ferruh Yigit
  0 siblings, 2 replies; 10+ messages in thread
From: Chas Williams @ 2018-03-18  1:45 UTC (permalink / raw)
  To: dev; +Cc: skhare, Chas Williams, stable

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.

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

Signed-off-by: Chas Williams <chas3@att.com>
---
 drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index 426008722..48a4d4f98 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -1105,7 +1105,7 @@ __vmxnet3_dev_link_update(struct rte_eth_dev *dev,
 		link.link_status = ETH_LINK_UP;
 	link.link_duplex = ETH_LINK_FULL_DUPLEX;
 	link.link_speed = ETH_SPEED_NUM_10G;
-	link.link_autoneg = ETH_LINK_AUTONEG;
+	link.link_autoneg = ETH_LINK_FIXED;
 
 	return rte_eth_linkstatus_set(dev, &link);
 }
-- 
2.13.6

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [dpdk-stable] [PATCH] net/vmxnet3: keep link state consistent
  2018-03-18  1:45 [PATCH] net/vmxnet3: keep link state consistent Chas Williams
@ 2018-03-20 14:12 ` Ferruh Yigit
  2018-03-20 14:42   ` Chas Williams
  2018-04-05 10:03   ` Thomas Monjalon
  2018-04-20  0:10 ` Ferruh Yigit
  1 sibling, 2 replies; 10+ messages in thread
From: Ferruh Yigit @ 2018-03-20 14:12 UTC (permalink / raw)
  To: Chas Williams, dev; +Cc: skhare, Chas Williams, stable

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.
> 
> 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

> 
> Signed-off-by: Chas Williams <chas3@att.com>
> ---
>  drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c b/drivers/net/vmxnet3/vmxnet3_ethdev.c
> index 426008722..48a4d4f98 100644
> --- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
> +++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
> @@ -1105,7 +1105,7 @@ __vmxnet3_dev_link_update(struct rte_eth_dev *dev,
>  		link.link_status = ETH_LINK_UP;
>  	link.link_duplex = ETH_LINK_FULL_DUPLEX;
>  	link.link_speed = ETH_SPEED_NUM_10G;
> -	link.link_autoneg = ETH_LINK_AUTONEG;
> +	link.link_autoneg = ETH_LINK_FIXED;
>  
>  	return rte_eth_linkstatus_set(dev, &link);
>  }
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-stable] [PATCH] net/vmxnet3: keep link state consistent
  2018-03-20 14:12 ` [dpdk-stable] " Ferruh Yigit
@ 2018-03-20 14:42   ` Chas Williams
  2018-04-05 10:03   ` Thomas Monjalon
  1 sibling, 0 replies; 10+ messages in thread
From: Chas Williams @ 2018-03-20 14:42 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: dev, skhare, Chas Williams, stable

On Tue, Mar 20, 2018 at 10:12 AM, Ferruh Yigit <ferruh.yigit@intel.com>
wrote:

> 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.
> >
> > Author: Thomas Monjalon <thomas@monjalon.net>
> > Date:   Fri Jan 5 18:38:55 2018 +0100
>

Didn't mean for this to be in the commit message.  I will submit a v2.


> >
> > 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?
>

Same comments as above apply.  link_autoneg implies that there is some sort
of
autonegotiation.  Unless there is actually sort some of autonegotiating
happening
there isn't a reason to indicate it.


> [1]
> pcap
> softnic
> vmxnet3
>
> >
> > Signed-off-by: Chas Williams <chas3@att.com>
> > ---
> >  drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
> b/drivers/net/vmxnet3/vmxnet3_ethdev.c
> > index 426008722..48a4d4f98 100644
> > --- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
> > +++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
> > @@ -1105,7 +1105,7 @@ __vmxnet3_dev_link_update(struct rte_eth_dev *dev,
> >               link.link_status = ETH_LINK_UP;
> >       link.link_duplex = ETH_LINK_FULL_DUPLEX;
> >       link.link_speed = ETH_SPEED_NUM_10G;
> > -     link.link_autoneg = ETH_LINK_AUTONEG;
> > +     link.link_autoneg = ETH_LINK_FIXED;
> >
> >       return rte_eth_linkstatus_set(dev, &link);
> >  }
> >
>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-stable] [PATCH] net/vmxnet3: keep link state consistent
  2018-03-20 14:12 ` [dpdk-stable] " Ferruh Yigit
  2018-03-20 14:42   ` Chas Williams
@ 2018-04-05 10:03   ` Thomas Monjalon
  2018-04-05 15:01     ` Chas Williams
  1 sibling, 1 reply; 10+ messages in thread
From: Thomas Monjalon @ 2018-04-05 10:03 UTC (permalink / raw)
  To: Chas Williams, Chas Williams; +Cc: dev, Ferruh Yigit, skhare, stable

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?

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.


> > 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-stable] [PATCH] net/vmxnet3: keep link state consistent
  2018-04-05 10:03   ` Thomas Monjalon
@ 2018-04-05 15:01     ` Chas Williams
  2018-04-17 19:25       ` Ferruh Yigit
  0 siblings, 1 reply; 10+ messages in thread
From: Chas Williams @ 2018-04-05 15:01 UTC (permalink / raw)
  To: Thomas Monjalon; +Cc: Chas Williams, dev, Ferruh Yigit, skhare, stable

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
>
>
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-stable] [PATCH] net/vmxnet3: keep link state consistent
  2018-04-05 15:01     ` Chas Williams
@ 2018-04-17 19:25       ` Ferruh Yigit
  2018-04-17 20:24         ` Thomas Monjalon
  0 siblings, 1 reply; 10+ messages in thread
From: Ferruh Yigit @ 2018-04-17 19:25 UTC (permalink / raw)
  To: Chas Williams, Thomas Monjalon; +Cc: Chas Williams, dev, skhare, stable

On 4/5/2018 4:01 PM, Chas Williams wrote:
> 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.

Hi Chas, Thomas,

What is the latest status of this patch? Is it agreed to convert link_autoneg to
ETH_LINK_FIXED for following PMDs [1]?

[1]
pcap
softnic
vmxnet3


> 
>>
>>
>>>> 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
>>
>>
>>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-stable] [PATCH] net/vmxnet3: keep link state consistent
  2018-04-17 19:25       ` Ferruh Yigit
@ 2018-04-17 20:24         ` Thomas Monjalon
  2018-04-18 16:23           ` Ferruh Yigit
  2018-04-18 16:59           ` Yong Wang
  0 siblings, 2 replies; 10+ messages in thread
From: Thomas Monjalon @ 2018-04-17 20:24 UTC (permalink / raw)
  To: Ferruh Yigit; +Cc: Chas Williams, Chas Williams, dev, skhare, stable

17/04/2018 21:25, Ferruh Yigit:
> On 4/5/2018 4:01 PM, Chas Williams wrote:
> > 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.
> 
> Hi Chas, Thomas,
> 
> What is the latest status of this patch? Is it agreed to convert link_autoneg to
> ETH_LINK_FIXED for following PMDs [1]?
> 
> [1]
> pcap
> softnic
> vmxnet3

Yes, OK for ETH_LINK_FIXED.


> >>>> 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
> >>
> >>
> >>
> 
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-stable] [PATCH] net/vmxnet3: keep link state consistent
  2018-04-17 20:24         ` Thomas Monjalon
@ 2018-04-18 16:23           ` Ferruh Yigit
  2018-04-18 16:59           ` Yong Wang
  1 sibling, 0 replies; 10+ messages in thread
From: Ferruh Yigit @ 2018-04-18 16:23 UTC (permalink / raw)
  To: Chas Williams; +Cc: Thomas Monjalon, Chas Williams, dev, stable

On 4/17/2018 9:24 PM, Thomas Monjalon wrote:
> 17/04/2018 21:25, Ferruh Yigit:
>> On 4/5/2018 4:01 PM, Chas Williams wrote:
>>> 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.
>>
>> Hi Chas, Thomas,
>>
>> What is the latest status of this patch? Is it agreed to convert link_autoneg to
>> ETH_LINK_FIXED for following PMDs [1]?
>>
>> [1]
>> pcap
>> softnic
>> vmxnet3
> 
> Yes, OK for ETH_LINK_FIXED.

Thanks for clarification.


Hi Chas,

Do you prefer to re-make the patch to cover them all, or should I get this one
as start, which one do you prefer?

Thanks,
ferruh

> 
> 
>>>>>> 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
>>>>
>>>>
>>>>
>>
>>
> 
> 
> 
> 
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-stable] [PATCH] net/vmxnet3: keep link state consistent
  2018-04-17 20:24         ` Thomas Monjalon
  2018-04-18 16:23           ` Ferruh Yigit
@ 2018-04-18 16:59           ` Yong Wang
  1 sibling, 0 replies; 10+ messages in thread
From: Yong Wang @ 2018-04-18 16:59 UTC (permalink / raw)
  To: Thomas Monjalon, Ferruh Yigit
  Cc: Chas Williams, Chas Williams, dev, skhare, stable

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Tuesday, April 17, 2018 1:24 PM
> To: Ferruh Yigit <ferruh.yigit@intel.com>
> Cc: Chas Williams <3chas3@gmail.com>; Chas Williams <chas3@att.com>;
> dev@dpdk.org; skhare@vmware.com; stable@dpdk.org
> Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] net/vmxnet3: keep link state
> consistent
> 
> 17/04/2018 21:25, Ferruh Yigit:
> > On 4/5/2018 4:01 PM, Chas Williams wrote:
> > > 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__dpdk.org_ml_archives_dev_2018-
> 2DApril_094696.html&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=v4BBYIqi
> Dq552fkYnKKFBFyqvMXOR3UXSdFO2plFD1s&m=6ysGgXVpT4Dvp9bYO4DiAL
> 5HD_akgEyC0198WlWh8-0&s=zNjF-
> 3TX65mjvz8ONIeKuiZcPyXqt00aou26gUTXejQ&e=
> > >
> > > 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.
> >
> > Hi Chas, Thomas,
> >
> > What is the latest status of this patch? Is it agreed to convert link_autoneg
> to
> > ETH_LINK_FIXED for following PMDs [1]?
> >
> > [1]
> > pcap
> > softnic
> > vmxnet3
> 
> Yes, OK for ETH_LINK_FIXED.

Yes and it makes sense for vmxnet3 to use ETH_LINK_FIXED.

> > >>>> 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
> > >>
> > >>
> > >>
> >
> >
> 
> 
> 
> 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [dpdk-stable] [PATCH] net/vmxnet3: keep link state consistent
  2018-03-18  1:45 [PATCH] net/vmxnet3: keep link state consistent Chas Williams
  2018-03-20 14:12 ` [dpdk-stable] " Ferruh Yigit
@ 2018-04-20  0:10 ` Ferruh Yigit
  1 sibling, 0 replies; 10+ messages in thread
From: Ferruh Yigit @ 2018-04-20  0:10 UTC (permalink / raw)
  To: Chas Williams, dev; +Cc: skhare, Chas Williams, stable

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.
> 
> 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
> 
> Signed-off-by: Chas Williams <chas3@att.com>

>From Thomas Monjalon <thomas@monjalon.net>:
> Yes, OK for ETH_LINK_FIXED.

>From Yong Wang <yongwang@vmware.com>: 	
> Yes and it makes sense for vmxnet3 to use ETH_LINK_FIXED.
Converted into explicit ack:
Acked-by: Yong Wang <yongwang@vmware.com>

Applied to dpdk-next-net/master, thanks.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2018-04-20  0:10 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-18  1:45 [PATCH] net/vmxnet3: keep link state consistent Chas Williams
2018-03-20 14:12 ` [dpdk-stable] " Ferruh Yigit
2018-03-20 14:42   ` Chas Williams
2018-04-05 10:03   ` Thomas Monjalon
2018-04-05 15:01     ` Chas Williams
2018-04-17 19:25       ` Ferruh Yigit
2018-04-17 20:24         ` Thomas Monjalon
2018-04-18 16:23           ` Ferruh Yigit
2018-04-18 16:59           ` Yong Wang
2018-04-20  0:10 ` Ferruh Yigit

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.