Skip to contentSkip to conversation

net/vmxnet3: keep link state consistent

PATCH Applied Chas Williams 4 participants 10 messages Mar 18, 2018 – Apr 20, 2018

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 net/vmxnet3: keep link state consistent

From: Chas Williams <[email protected]>

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 <[email protected]>
Date:   Fri Jan 5 18:38:55 2018 +0100
Fixes 1e3a958f40b3 ("ethdev: fix link autonegotiation value")
---
 drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/vmxnet3/vmxnet3_ethdev.c +1 -1
index 426008722..48a4d4f98 100644
@@ -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);
 }
Signature · 1 line
2.13.6
#1 lore raw
Quoted 9 lines · Chas Williams

From: Chas Williams <[email protected]>

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.

Quoted 5 lines
Author: Thomas Monjalon <[email protected]>
Date:   Fri Jan 5 18:38:55 2018 +0100
Fixes 1e3a958f40b3 ("ethdev: fix link autonegotiation value")

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

Quoted 20 lines
---
 drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/vmxnet3/vmxnet3_ethdev.c +1 -1
index 426008722..48a4d4f98 100644
@@ -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 lore raw
Quoted 10 lines · Ferruh Yigit
Quoted 9 lines · Chas Williams

From: Chas Williams <[email protected]>

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.

Quoted 3 lines
Quoted 2 lines
Author: Thomas Monjalon <[email protected]>
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.

Quoted 8 lines
Quoted 3 lines
Fixes 1e3a958f40b3 ("ethdev: fix link autonegotiation value")

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.

Quoted 28 lines

[1]
pcap
softnic
vmxnet3

Review

Quoted 7 lines
---
 drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
(quoted diff) +0 -0

b/drivers/net/vmxnet3/vmxnet3_ethdev.c

Quoted 13 lines

index 426008722..48a4d4f98 100644

drivers/net/vmxnet3/vmxnet3_ethdev.c +1 -1
@@ -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);
 }
#3 lore raw
In reply to Ferruh Yigit

20/03/2018 15:12, Ferruh Yigit:

Quoted 9 lines · Chas Williams
Quoted 8 lines

From: Chas Williams <[email protected]>

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.

Quoted 6 lines
Quoted 5 lines
Author: Thomas Monjalon <[email protected]>
Date:   Fri Jan 5 18:38:55 2018 +0100
Fixes 1e3a958f40b3 ("ethdev: fix link autonegotiation value")
Quoted 7 lines

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

#4 lore raw
Quoted 11 lines · Thomas Monjalon

20/03/2018 15:12, Ferruh Yigit:

Quoted 9 lines · Chas Williams
Quoted 8 lines

From: Chas Williams <[email protected]>

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.

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 20 lines
Quoted 8 lines
Quoted 7 lines

Author: Thomas Monjalon <[email protected]>
Date:   Fri Jan 5 18:38:55 2018 +0100
Fixes 1e3a958f40b3 ("ethdev: fix link autonegotiation value")
Quoted 7 lines

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

#5 lore raw
Quoted 35 lines · Chas Williams
Quoted 11 lines · Thomas Monjalon

20/03/2018 15:12, Ferruh Yigit:

Quoted 9 lines · Chas Williams
Quoted 8 lines

From: Chas Williams <[email protected]>

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.

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 8 lines

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

Quoted 21 lines
Quoted 21 lines
Quoted 9 lines
Quoted 8 lines


Author: Thomas Monjalon <[email protected]>
Date:   Fri Jan 5 18:38:55 2018 +0100
Fixes 1e3a958f40b3 ("ethdev: fix link autonegotiation value")
Quoted 7 lines

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

#6 lore raw

17/04/2018 21:25, Ferruh Yigit:

Quoted 47 lines · Chas Williams
Quoted 35 lines · Thomas Monjalon
Quoted 11 lines

20/03/2018 15:12, Ferruh Yigit:

Quoted 9 lines · Chas Williams
Quoted 8 lines

From: Chas Williams <[email protected]>

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.

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 8 lines

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,

Quoted 7 lines

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.

Quoted 20 lines
Quoted 18 lines
Quoted 18 lines
Quoted 6 lines
Quoted 5 lines
Author: Thomas Monjalon <[email protected]>
Date:   Fri Jan 5 18:38:55 2018 +0100
Fixes 1e3a958f40b3 ("ethdev: fix link autonegotiation value")
Quoted 7 lines

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

#7 lore raw
Quoted 51 lines · Thomas Monjalon

17/04/2018 21:25, Ferruh Yigit:

Quoted 50 lines · Chas Williams
Quoted 35 lines · Thomas Monjalon
Quoted 11 lines

20/03/2018 15:12, Ferruh Yigit:

Quoted 9 lines · Chas Williams
Quoted 8 lines

From: Chas Williams <[email protected]>

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.

Quoted 2 lines

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.

Quoted 3 lines

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.

Quoted 8 lines

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

Quoted 6 lines
Quoted 4 lines

[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

Quoted 27 lines
Quoted 22 lines
Quoted 20 lines
Quoted 20 lines
Quoted 8 lines
Quoted 7 lines

Author: Thomas Monjalon <[email protected]>
Date:   Fri Jan 5 18:38:55 2018 +0100
Fixes 1e3a958f40b3 ("ethdev: fix link autonegotiation value")
Quoted 7 lines

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

#8 lore raw
In reply to Thomas Monjalon
Quoted 73 lines

-----Original Message-----
From: dev [mailto:[email protected]] On Behalf Of Thomas Monjalon
Sent: Tuesday, April 17, 2018 1:24 PM
To: Ferruh Yigit <[email protected]>
Cc: Chas Williams <[email protected]>; Chas Williams <[email protected]>; [email protected]; [email protected]; [email protected]
Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH] net/vmxnet3: keep link state consistent

17/04/2018 21:25, Ferruh Yigit:

Quoted 2 lines · Chas Williams
Quoted 1 line

On Thu, Apr 5, 2018 at 6:03 AM, Thomas Monjalon

Quoted 5 lines · <[email protected]> wrote:
Quoted 5 lines
Quoted 5 lines

20/03/2018 15:12, Ferruh Yigit:

Quoted 4 lines · Chas Williams
Quoted 3 lines

From: Chas Williams <[email protected]>

The vmxnet3 never attempts link speed negotiation. As a virtual

device

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

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

Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line

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

Quoted 8 lines
Quoted 8 lines

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=

Quoted 2 lines
Quoted 2 lines

The problem is more vexing for AUTONEG and bonding. I am still thinking

about

Quoted 3 lines
Quoted 3 lines

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

Quoted 4 lines
Quoted 4 lines

AUTONEG makes more sense because it is just easier to handle.

Quoted 2 lines

About the right value to set for virtual PMDs, I don't know, both are

fakes.

Quoted 1 line
Quoted 1 line
Quoted 1 line

I thought that AUTONEG better convey the vague link speed you

describe.

Quoted 8 lines
Quoted 8 lines

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

Quoted 5 lines
Quoted 1 line

duplex.

Hi Chas, Thomas,

What is the latest status of this patch? Is it agreed to convert link_autoneg

to

Quoted 8 lines
Quoted 6 lines

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.

Quoted 26 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Author: Thomas Monjalon <[email protected]>
Date:   Fri Jan 5 18:38:55 2018 +0100
Fixes 1e3a958f40b3 ("ethdev: fix link autonegotiation value")

There were a few more PMDs [1] they have been updated from FIXED

to AUTONEG with

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

above commit, do you think should we update them back to FIXED as

well?

Quoted 12 lines
Quoted 10 lines
Quoted 10 lines
Quoted 5 lines

[1]
pcap
softnic
vmxnet3

Yes, they all can be fixed/LINK_FIXED :) I guess

Acked-by Yong Wang on v1 1/1 Applied
#9 lore raw
In reply to Chas Williams
Quoted 15 lines · Chas Williams

From: Chas Williams <[email protected]>

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 <[email protected]>
Date:   Fri Jan 5 18:38:55 2018 +0100
Fixes 1e3a958f40b3 ("ethdev: fix link autonegotiation value")
Quoted 7 lines

From Thomas Monjalon <[email protected]>:
Yes, OK for ETH_LINK_FIXED.

From Yong Wang <[email protected]>:
Yes and it makes sense for vmxnet3 to use ETH_LINK_FIXED.

Converted into explicit ack:

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