attachment is the scripts,
# ./setup.sh # ip netns exec ns1 ./team1.sh # ./team0.sh # ping 192.168.11.3
the issue is team0 cannot switch to veth2, even if the veth0 has no carrier.
This should be definitelly fixed in user part.
now it can disable/enable it in lw_ethtool_event_watch_port_changed() when receive event from kernel, but at the beginning, the first event from adding port will not going to team_port_en_option_set, as new_link_up == common_ppriv->link_up in lw_ethtool_event_watch_port_changed().
maybe it should be fixed there ?
Yes please.
Hi, Jiri, considering this issue only happens when adding ports, I found two places to fix it: lw_ethtool_port_added() and link_watch_event_watch_port_added()
I prefer in lw_ethtool_port_added(), as only when using ethtool link_watch it has this issue.
--- a/teamd/teamd_lw_ethtool.c +++ b/teamd/teamd_lw_ethtool.c @@ -156,6 +156,9 @@ static int lw_ethtool_port_added(struct teamd_context *ctx, teamd_log_err("Failed to register event watch."); goto delay_callback_del; } + if (!team_is_port_link_up(tdport->team_port)) + team_set_port_enabled(ctx->th, tdport->ifindex, false); + return 0;
what do you think ?
I also noticed another issue (not related to this one), at the first time port_changed event is triggered, right after port_added event, there is always a err log:
veth2: Failed to find "enabled" option.
It's from: lw_ethtool_event_watch_port_changed -> ... teamd_port_check_enable -> teamd_port_enabled
it's because at that time, no 'enabled' option is set in userspace yet.
do you think it's also a bug ?
Wed, Dec 07, 2016 at 01:14:04PM CET, lucien.xin@gmail.com wrote:
attachment is the scripts,
# ./setup.sh # ip netns exec ns1 ./team1.sh # ./team0.sh # ping 192.168.11.3
the issue is team0 cannot switch to veth2, even if the veth0 has no carrier.
This should be definitelly fixed in user part.
now it can disable/enable it in lw_ethtool_event_watch_port_changed() when receive event from kernel, but at the beginning, the first event from adding port will not going to team_port_en_option_set, as new_link_up == common_ppriv->link_up in lw_ethtool_event_watch_port_changed().
maybe it should be fixed there ?
Yes please.
Hi, Jiri, considering this issue only happens when adding ports, I found two places to fix it: lw_ethtool_port_added() and link_watch_event_watch_port_added()
I prefer in lw_ethtool_port_added(), as only when using ethtool link_watch it has this issue.
That does not look to me good at all.
Looking at the scripts you send me and teamd code, I don't understand that the problem is. Look at lb_event_watch_port_link_changed:
return teamd_port_check_enable(ctx, tdport, port_up, !port_up);
It enables/disables the port according to the linkup.
What is the issue?
--- a/teamd/teamd_lw_ethtool.c +++ b/teamd/teamd_lw_ethtool.c @@ -156,6 +156,9 @@ static int lw_ethtool_port_added(struct teamd_context *ctx, teamd_log_err("Failed to register event watch."); goto delay_callback_del; }
if (!team_is_port_link_up(tdport->team_port))
team_set_port_enabled(ctx->th, tdport->ifindex, false);
return 0;
what do you think ?
I also noticed another issue (not related to this one), at the first time port_changed event is triggered, right after port_added event, there is always a err log:
veth2: Failed to find "enabled" option.
It's from: lw_ethtool_event_watch_port_changed -> ... teamd_port_check_enable -> teamd_port_enabled
it's because at that time, no 'enabled' option is set in userspace yet.
do you think it's also a bug ?
It looks like it. Not sure why this happens. Could you debug a bit more? team_get_option calls find_option which created a temporary option if that is not fetched from kernel yet.
attachment is the scripts,
# ./setup.sh # ip netns exec ns1 ./team1.sh # ./team0.sh # ping 192.168.11.3
the issue is team0 cannot switch to veth2, even if the veth0 has no carrier.
This should be definitelly fixed in user part.
now it can disable/enable it in lw_ethtool_event_watch_port_changed() when receive event from kernel, but at the beginning, the first event from adding port will not going to team_port_en_option_set, as new_link_up == common_ppriv->link_up in lw_ethtool_event_watch_port_changed().
maybe it should be fixed there ?
Yes please.
Hi, Jiri, considering this issue only happens when adding ports, I found two places to fix it: lw_ethtool_port_added() and link_watch_event_watch_port_added()
I prefer in lw_ethtool_port_added(), as only when using ethtool link_watch it has this issue.
That does not look to me good at all.
Looking at the scripts you send me and teamd code, I don't understand that the problem is. Look at lb_event_watch_port_link_changed:
return teamd_port_check_enable(ctx, tdport, port_up, !port_up);
It enables/disables the port according to the linkup.
pls note the path of calling lb_event_watch_port_link_changed(): lw_ethtool_event_watch_port_changed() -> teamd_link_watch_check_link_up() -> teamd_event_port_link_changed() -> lb_event_watch_port_link_changed()
now in lw_ethtool_event_watch_port_changed(), it return earlier when checking: if (!teamd_link_watch_link_up_differs(common_ppriv, link_up)) return 0;
lb_event_watch_port_link_changed has no chance to be called at that time.
as we add a UNPLUG port, new_link_up and common_ppriv->link_up both are false.
is it clear now ?
What is the issue?
--- a/teamd/teamd_lw_ethtool.c +++ b/teamd/teamd_lw_ethtool.c @@ -156,6 +156,9 @@ static int lw_ethtool_port_added(struct teamd_context *ctx, teamd_log_err("Failed to register event watch."); goto delay_callback_del; }
if (!team_is_port_link_up(tdport->team_port))
team_set_port_enabled(ctx->th, tdport->ifindex, false);
return 0;
what do you think ?
I also noticed another issue (not related to this one), at the first time port_changed event is triggered, right after port_added event, there is always a err log:
veth2: Failed to find "enabled" option.
It's from: lw_ethtool_event_watch_port_changed -> ... teamd_port_check_enable -> teamd_port_enabled
it's because at that time, no 'enabled' option is set in userspace yet.
do you think it's also a bug ?
It looks like it. Not sure why this happens. Could you debug a bit more? team_get_option calls find_option which created a temporary option if that is not fetched from kernel yet.
yes, but in teamd_port_enabled(), it use "np" instead of "np!" as the param: option = team_get_option(ctx->th, "np", "enabled", tdport->ifindex); which wouldn't create the option.
libteam@lists.fedorahosted.org