From: Zhu Yanjun
Sometimes vfta registers can not be written successfully in dcb mode.
This is very occassional. When the ixgbe nic runs for a very long time,
sometimes this bug occurs. But after IXGBE_WRITE_FLUSH is executed,
this bug never occurs.
Signed-off-by: Zhu Yanjun
---
drivers/net/et
From: Zhu Yanjun
The source code is related with ipv6. As such, it is better to insert
ipv6 macro.
Signed-off-by: Zhu Yanjun
---
drivers/net/vxlan.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index e7d1668..9af6600 100644
From: Zhu Yanjun
Replace defined macro with IS_ENABLED in ixgbe.h file
Signed-off-by: Zhu Yanjun
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
From: Zhu Yanjun
The struct nlattr variable should not be changed.
Signed-off-by: Zhu Yanjun
---
drivers/net/vxlan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index f605a36..ce65897 100644
--- a/drivers/net/vxlan.c
+++ b/d
From: Zhu Yanjun
This header file is not used in vxlan.c file.
Signed-off-by: Zhu Yanjun
---
drivers/net/vxlan.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index c0dda6f..3f7e0d2 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -27
From: Zhu Yanjun
The message "803.ad" should be "802.3ad".
Signed-off-by: Zhu Yanjun
---
drivers/net/bonding/bond_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 1f276fa..217e8da 100644
--- a/dri
From: Zhu Yanjun
The variable autoneg_wait_to_complete is not used. So it is removed.
Signed-off-by: Zhu Yanjun
---
drivers/net/ethernet/intel/ixgbevf/ethtool.c | 4 ++--
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 2 +-
drivers/net/ethernet/intel/ixgbevf/vf.c | 11 +++
From: Zhu Yanjun
The variable get_mac_status is a bool variable. So a bool value is
better than an integer number.
Signed-off-by: Zhu Yanjun
---
drivers/net/ethernet/intel/ixgbevf/ethtool.c | 2 +-
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 4 ++--
2 files changed, 3 insertions(+
From: Zhu Yanjun
With the original enum, when a several bits state is set, it is
possible that the wrong test occurs.
For example,
a state is 0x3, its bits are 11. When testing a state 0x2 whose
bits are 10, it is difficult to confirm that state 0x2 is set or
not.
As such, the MACROs are defin
Sorry. Please ignore the last mail because there are some typos
in the patch.
In this patch, these typos are corrected.
Zhu Yanjun
From: Zhu Yanjun
With the original num, when a several bits state is set, it is
possible that the wrong test occurs.
For example,
a state is 0x3, its bits are 11. When testing a state 0x2 whose
bits are 10, it is difficult to confirm that state 0x2 is set or
not.
As such, the MACROs are define
From: Zhu Yanjun
When performing hardware reset, it is not necessary to check hang.
Or else, the call trace will appear.
Signed-off-by: Zhu Yanjun
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 1 +
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 5 +++--
drivers/net/ethernet/inte
v1->v2:
Follow the advice from Donald, replacing read directly from RSTD and
RSTI register with a state variable __IXGBEVF_HW_RESETTING;
From: Zhu Yanjun
When performing hardware reset, it is not necessary to check hang.
Or else, the call trace will appear.
Signed-off-by: Zhu Yanjun
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbevf/i
From: Zhu Yanjun
When the fiber tranceiver is plugged/unplugged, a netdev notifier is
sent. The userspace tools or kernel can receive this notifier.
Signed-off-by: Zhu Yanjun
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h |2 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 24 +
Hi, all
The changes are as below:
V3:
1.move the 2 variables from ixgbe_hw struct to ixgbe_adapter struct;
V2:
1. Replace IXGBE_IDENTIFIER with IXGBE_ESDP;
2. Replace plug interrupt with poll;
3. Indicate the NICs that does not support to plug/unplug tranceiver as
plugged;
Hi, Don
Than
From: Zhu Yanjun
When the fiber tranceiver is plugged/unplugged, a netdev notifier is
sent. The userspace tools or kernel can receive this notifier.
Signed-off-by: Zhu Yanjun
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 24 +++-
drivers/net/ethernet/intel/ixgbe/ix
Hi, Don
The latest patch is based on your suggestion.
The changes are as below:
1. Replace IXGBE_IDENTIFIER with IXGBE_ESDP;
2. Replace plug interrupt with poll;
3. Indicate the NICs that does not support to plug/unplug tranceiver as plugged;
The patch can work well with the following steps:
From: Zhu Yanjun
When the fiber tranceiver is plugged/unplugged, a netdev notifier is
sent. The userspace tools or kernel can receive this notifier.
Signed-off-by: Zhu Yanjun
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 26 -
drivers/net/ethernet/intel/ixgbe/ix
Hi, all
When the fiber tranceiver is plugged/unplugged from the nic, there is no any
notifiers to indicate this events now.
This events sometimes are needed by the userspace tools or kernel.
So,
Is there any interrupt to indicate the unplug event?
If no interrupt, is there any method to notif
From: Zhu Yanjun
Signed-off-by: Zhu Yanjun
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 088c47c..cb19cbc 100644
-
Hi,all
I am using the ixgbe nic. I found that the rtnl_lock is being
used to enable upper device, such as macvlan. I am curious
why rcu_read_lock is not used here.
I replaced rtnl_lock with rcu_read_lock here. Then I made tests and
it can work well.
So can the rtnl_lock be replaced with
From: Zhu Yanjun
Adjust indent and remove unnecessary parentheses in igb driver.
Signed-off-by: Zhu Yanjun
---
drivers/net/ethernet/intel/igb/igb_main.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/dri
From: Zhu Yanjun
The commit 0e4d422f5f72 ("ixgbe: do not call check_link for ethtool
in ixgbe_get_settings()") decreases the bonding failures. But the
following time slice still results in a bonding failure.
bondingixgbe
| |
|carrier_on
Hi, Emil
Thanks for your patch.
After I applied your patch, the following are the feedback from my users.
"
Users had tested the latest patch that you provided and it is much improved
now. However it’s still not good enough as the users are planning field
deployment. Here are their findings:
From: Zhu Yanjun
rcu_read_lock and rcu_read_unlock are to protect the function
bond_miimon_inspect. As such, moving rcu_read_lock and rcu_read_unlock
to the function bond_miimon_inspect to make the source code compact.
CC: Jay Vosburgh
CC: Veaceslav Falico
CC: Andy Gospodarek
Signed-off-by: Z
From: Zhu Yanjun
This is just a test patch. Jay and Emil helped me a lot. The original patch
is in net-next. But kernel v4.4 needs this patch, too. As such, I backport
to kernel v4.4.
Bonding will utilize notifier callbacks to detect slave
link state changes. It is intended to be used with miim
From: Zhu Yanjun
Bonding will utilize notifier callbacks to detect slave
link state changes. It is intended to be used with miimon
set to zero, and does not support the updelay or downdelay
options to bonding.
Because of link flap from the slave interface, if the notifier
is NETDEV_UP while the
Hi, Jay && Emil
Thanks for your hard work. I forget to send this patch to you. Please help to
review. Thanks a lot.
I think the similar patch is needed in linux kernel 4.4. As such, based on
linux kernel 4.4, I made this patch. Please comment.
Best Regards!
Zhu Yanjun
Hi, all
Thanks for the reply from Jeff.
V2: Based on feedback from Jeff Kirsher, it is not appropriate to continue
in the function ixgbe_watchdog_link_is_up without link_speed since this will
make some virtual NICs not work well.
V3: Based on feedback from Emil Tantilov, the time span b
From: Zhu Yanjun
According to the suggestions from Rustad, Mark D, to all the slave
interfaces, the link_speed and link_up should be synchronized since
the time span between link_up and link_speed will make some virtual
NICs not work well, such as a bonding driver in 802.3ad mode.
Signed-off-by
From: Zhu Yanjun
According to the suggestions from Rustad, Mark D, to all the slave
interfaces, the link_speed and link_up should be synchronized since
the time span between link_up and link_speed will make some virtual
NICs not work well, such as a bonding driver in 802.3ad mode.
Signed-off-by
Hi, all
Thanks for the suggestions from Rustad, Mark D.
According to his suggestions, the logs and source code are simplified.
Zhu Yanjun
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger
Hi, all
According to Rustad, Mark D, maybe it is related with copper phy. To make fiber
phy more
robust, synchronize both the link_up and link_speed of a slave interface in
ixgbe driver.
Best Regards!
Zhu Yanjun
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body o
From: Zhu Yanjun
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 ti
From: Zhu Yanjun
According to the suggestion from Rustad, Mark D, this behavior perhaps
is more related to the copper phy. But to make fiber phy more robust,
to all the interfaces as a slave interface, the link_speed and link_up
is synchronized.
Signed-off-by: Zhu Yanjun
---
drivers/net/ethern
From: Zhu Yanjun
In X540 NIC, there is a time span between reporting "link on" and
getting the speed and duplex. To a bonding driver in 802.3ad mode,
this time span will make it not work well if the time span is big
enough. The big time span will make bonding driver change the state of
the slave
From: Zhu Yanjun
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 ti
Hi, all
During the discussion with Emil, I think the time span between link_up
and link_speed is not important when the X540 NIC acts as an independent
interface. As such, a new patch is made to restrict synchronization
between link_up and link_speed.
Any reply is appreciated.
Zhu Yanjun
--
From: yzhu1
In X540 NIC, there is a time span between reporting "link on" and
getting the speed and duplex. To a bonding driver in 802.3ad mode,
this time span will make it not work well if the time span is big
enough. The big time span will make bonding driver change the state of
the slave devic
From: yzhu1
In X540 NIC, there is a time span between reporting "link on" and
getting the speed and duplex. To a bonding driver in 802.3ad mode,
this time span will make it not work well if the time span is big
enough. The big time span will make bonding driver change the state of
the slave devic
Hi, Jeff
Thanks for your reply.
Changes:
Since there is a time span between link_up and link_speed to X540 NIC, it is
not appropriate to continue in the function ixgbe_watchdog_link_is_up if only
link_up is ready.
Best Regards!
Zhu Yanjun
--
To unsubscribe from this list: send the line "unsub
From: Zhu Yanjun
In X540 NIC, there is a time span between reporting "link on" and
getting the speed and duplex. To a bonding driver in 802.3ad mode,
this time span will make it not work well if the time span is big
enough. The big time span will make bonding driver change the state of
the slave
Hi, Jay
Thanks for your reply.
Yes. The NIC is a bit odd. We have to be compatible with it.
I followed your advice to delay calling netif_carrier_on().
Changes:
Delay calling netif_carrier_on().
Best Regards!
Zhu Yanjun
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
th
From: yzhu1
In 802.3ad mode, the speed and duplex is needed. But in some NICs,
there is a time span between NIC up state and getting speed and duplex.
As such, sometimes a slave in 802.3ad mode is in up state without
speed and duplex. This will make bonding in 802.3ad mode can not
work well.
To
From: Zhu Yanjun
In 802.3ad mode, the speed and duplex is needed. But in some NIC,
there is a time span between NIC up state and getting speed and duplex.
As such, sometimes a slave in 802.3ad mode is in up state without
speed and duplex. This will make bonding in 802.3ad mode can not
work well.
From: Zhu Yanjun
As we all know, the value of pf_retrans >= max_retrans_path can
disable pf state. The variables of pf_retrans and max_retrans_path
can be changed by the userspace application.
Sometimes the user expects to disable pf state while the 2
variables are changed to enable pf state. So
Hi, vlad
Sorry. There is a typo in Documentation/networking/ip-sysctl.txt of V3 patch.
Now I correct it.
Best Regards!
Zhu Yanjun
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.
Hi, vlad
Thanks for your ack. The latest patch is in the attachment.
Changes:
Modify Documentation/networking/ip-sysctl.txt according to Marcelo and David.
Best Regards!
Zhu Yanjun
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.k
From: Zhu Yanjun
As we all know, the value of pf_retrans >= max_retrans_path can
disable pf state. The variables of pf_retrans and max_retrans_path
can be changed by the userspace application.
Sometimes the user expects to disable pf state while the 2
variables are changed to enable pf state. So
From: Zhu Yanjun
As we all know, the value of pf_retrans >= max_retrans_path can
disable pf state. The variables of pf_retrans and max_retrans_path
can be changed by the user space application.
Sometimes the user expects to disable pf state while the 2
variables are changed to enable pf state. S
From: Zhu Yanjun
As we all know, the vale of pf_retrans >= max_retrans_path can
disable pf state. The variables of pf_retrans and max_retrans_path
can be changed by the user space application.
Sometimes the user expects to disable pf state while the 2
variables are changed to enable pf state. So
From: yzhu1
This feature is introduced in the commit 5aa93bc "sctp: Implement
quick failover draft from tsvwg". This feature should be disabled
if the quick failover feature is disabled.
Signed-off-by: yzhu1
---
net/sctp/associola.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
d
53 matches
Mail list logo
