Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set MAC address after renaming the interface #280

Merged
merged 1 commit into from
Oct 13, 2023

Conversation

zeeke
Copy link
Member

@zeeke zeeke commented Sep 29, 2023

Setting the MAC address at the end of SetupVF reduces the chances of race conditions with tools that set MAC i address asynchronously (i.e. iavf).

pkg/sriov/sriov.go Outdated Show resolved Hide resolved
@mlguerrero12
Copy link
Contributor

LGTM

@adrianchiris
Copy link
Contributor

@zeeke could you provide more info on the the race condition and how this reduces the chance of race condition ?

Setting the MAC address at the end of SetupVF reduces the chances of race conditions with tools that set MAC i address asynchronously (i.e. iavf).

typo remove "i" in MAC i address

Copy link
Contributor

@adrianchiris adrianchiris left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

small nit in commit msg + adding more info on the race condition is appreciated.

overall LGTM

@zeeke
Copy link
Member Author

zeeke commented Oct 4, 2023

@zeeke could you provide more info on the the race condition and how this reduces the chance of race condition ?

I'm collaborating with kernel engineers to gather more information about this. What we discovered so far is that after recent changes to iavf driver (around c34743daca0eb1dc855831a5210f0800a850088e), setting the MAC address via sriov-cni produced VFs that are not able to ping each other.
Though this will likely be a kernel regression, I could not reproduce it via bare ip link ... commands, and these changes fix the problem with iavf cards.

I'm currently testing this against multiple NIC vendors. I hope I'll be back with more information, or at least regression test results to share with the community.

@zeeke
Copy link
Member Author

zeeke commented Oct 12, 2023

I managed to reproduce the issue this PR is trying to solve with bare ip ... commands, emulating what the SRIOV CNI does and highlighting the problem with the i40e driver.

test-ip.sh [2] executes steps before this changes: it configures two VFs from the same PF with MAC and IP addresses. Then tries a ping for a connectivity check.

i40e_before.txt [4] shows an error raised by the first MAC address set.

...
+ ip link set dev temp_71 address 20:04:0f:f1:88:A1
RTNETLINK answers: Resource temporarily unavailable
+ ip link set dev temp_71 address 20:04:0f:f1:88:A1
+ ip link set dev temp_71 netns ns_a
...

Though the second call goes well, the network device doesn't have any connectivity:

+ ip netns exec ns_a ping -c 3 10.255.255.2
PING 10.255.255.2 (10.255.255.2) 56(84) bytes of data.

--- 10.255.255.2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2069ms

test-ip.with-fix.sh.txt [1] shows this PR's changes fix the problem on i40e [3]:

+ ip link set dev ens1f0 vf 0 vlan 0
+ ip link set dev ens1f0 vf 0 state enable
+ ip link set dev ens1f0 vf 0 mac 20:04:0f:f1:88:A1
+ ip link set dev ens1f0v0 down
+ ip link set ens1f0v0 name temp_2
+ ip link set dev temp_2 netns ns_a
+ ip netns exec ns_a ip link set temp_2 name net1
+ ip netns exec ns_a sh -c 'echo 1 > /proc/sys/net/ipv4/conf/net1/arp_notify'
+ ip netns exec ns_a ip link set dev net1 address 20:04:0f:f1:88:A1
+ ip netns exec ns_a ip link set dev net1 up
+ ip netns exec ns_a ip address add dev net1 10.255.255.1/24

mlx5 driver is not affected by the problem [6], and the fix is not interfering with it [5].

Besides this test script, several tests have been executed against the sriov-operator with this cni fix, showing no regression on Intel E810 and Mellanox ConnectX-5

[1] test-ip.with-fix.sh.txt
[2] test-ip.sh.txt
[3] i40e_after.txt
[4] i40e_before.txt
[5] mlx5_after.txt
[6] mlx5_before.txt

@mlguerrero12
Copy link
Contributor

mlguerrero12 commented Oct 12, 2023

Nice work @zeeke!

Perhaps we should add a log in the retrying mechanism of SetVFEffectiveMAC to catch transient errors while setting the mac.

@zeeke
Copy link
Member Author

zeeke commented Oct 12, 2023

Nice work @zeeke!

Perhaps we should add a log in the retrying mechanism of SetVFEffectiveMAC to catch transient errors while setting the mac.

Good point

@zeeke
Copy link
Member Author

zeeke commented Oct 13, 2023

@Eoghan1232 can you please take a look at this?

@@ -402,3 +407,15 @@ func Retry(retries int, sleep time.Duration, f func() error) error {
}
return err
}

func warnOnError(callerFn string, f func() error) func() error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's simplify this. You can simply put the logging in the Retry function.

Copy link
Member Author

@zeeke zeeke Oct 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would involve many log calls, one for each error returned. Here we catch all of them.

I'm ok with removing all this logging and discussing it in another PR

Copy link
Contributor

@mlguerrero12 mlguerrero12 Oct 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but I didn't mean to add it inside the func() which is passed as a parameter in the Retry function, but to add it in the Retry function itself. Line 400 of utils.go. You would only add it once.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I got it. Not a big fan of logging from utility functions. it can lead to a lot of junk in the log files, for example, if the Retry function is called for another job where it's expected to have multiple failures before going well.

since it's not yet used widely, I'd overcome that by making it private

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can also add a new parameter "warnOnError" in the Retry func to control when to log

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5th parameter for a utility function. That's going to be even worse.
Thanks for the suggestions, but let's discuss it in a different PR, we went out of topic here.

Reverting

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alright, please create an issue to not forget this.

@zeeke zeeke force-pushed the ocpbugs-19536-us branch 2 times, most recently from 4ef5df7 to 03df0d8 Compare October 13, 2023 09:10
Copy link
Collaborator

@Eoghan1232 Eoghan1232 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am okay with these changes.

One question, I see you took out the changes to utils:

func warnOnError(callerFn string, f func() error) func() error {

was this intended? @zeeke

Setting the MAC address at the end of SetupVF reduces
the chances of race conditions with tools that set MAC
address asynchronously (i.e. iavf).

This commit solve an issue with i40e driver where calling
`SetVFEffectiveMAC` after `SetVFHardwareMAC` may produce
a VF with no connectivity even if the last configuration step
didn't produce any error:

```
+ ip link set dev ens1f0 vf 0 mac 20:04:0f:f1:88:A1   # No error
+ ip link set dev temp_71 address 20:04:0f:f1:88:A1   # Transient error
RTNETLINK answers: Resource temporarily unavailable
+ ip link set dev temp_71 address 20:04:0f:f1:88:A1   # No error
```

Note: this seems to be a kernel driver regression introduced near
torvalds/linux@c34743d

Signed-off-by: Andrea Panattoni <[email protected]>
@zeeke
Copy link
Member Author

zeeke commented Oct 13, 2023

I am okay with these changes.

One question, I see you took out the changes to utils:

func warnOnError(callerFn string, f func() error) func() error {

was this intended? @zeeke

Yes, we didn't find a consensus on how to log setting MAC address retries, so we'll tackle that on a different PR.

small nit in commit msg + adding more info on the race condition is appreciated.

overall LGTM

Updated the commit message

@Eoghan1232
Copy link
Collaborator

I am okay with these changes.
One question, I see you took out the changes to utils:

func warnOnError(callerFn string, f func() error) func() error {

was this intended? @zeeke

Yes, we didn't find a consensus on how to log setting MAC address retries, so we'll tackle that on a different PR.

small nit in commit msg + adding more info on the race condition is appreciated.
overall LGTM

Updated the commit message

understood, then I think we are good to merge this.

@zeeke
Copy link
Member Author

zeeke commented Oct 13, 2023

PR got 2 LGTMs from maintainers, merging.

@zeeke zeeke merged commit 75f2f5e into k8snetworkplumbingwg:master Oct 13, 2023
10 checks passed
@adrianchiris
Copy link
Contributor

Thx for the detailed information @zeeke !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants