-
Notifications
You must be signed in to change notification settings - Fork 124
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
Remove forced delay for linux interface notifications #1742
Conversation
Signed-off-by: Ondrej Fabry <ofabry@cisco.com>
Signed-off-by: Ondrej Fabry <ofabry@cisco.com>
Fixes: ligato#1739 Signed-off-by: Ondrej Fabry <ofabry@cisco.com>
Codecov Report
@@ Coverage Diff @@
## master #1742 +/- ##
==========================================
- Coverage 57.13% 55.64% -1.49%
==========================================
Files 618 379 -239
Lines 44673 27912 -16761
==========================================
- Hits 25522 15532 -9990
+ Misses 16192 10892 -5300
+ Partials 2959 1488 -1471
Flags with carried forward coverage won't be shown. Click here to find out more. |
// delayNotification delays notification about enabled interface - typically | ||
// interface is created in multiple stages and we do not want to notify scheduler | ||
// about intermediate states. | ||
func (w *InterfaceWatcher) delayNotification(ifName string) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't remember the exact scenario(s), but the reason for this was that newly created interface would send multiple UP/DOWN notifications, as if it was being created in multiple steps (causing dependent stuff to be created/deleted multiple times). Actually I think it is TAP that in VPP is being created through multiple syscalls. Anyway, let's get rid of the timeout and see if any issues appear (if yes, we can do this for example for VPP TAP, but not for VETH).
Btw. I don't think pendingIntfs map and running applyDelayedNotification as go routine is needed anymore. Also "applyDelayedNotification" is probably not a good name anymore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't remember the exact scenario(s), but the reason for this was that newly created interface would send multiple UP/DOWN notifications, as if it was being created in multiple steps (causing dependent stuff to be created/deleted multiple times).
For simple case of VETHs+AFPACKET I see several notifications, most likely because of various things configured on the interfaces (alias, namespace, peer, ...) and these dont see to cause issues for me. Running more e2e tests to confirm this though.
Actually I think it is TAP that in VPP is being created through multiple syscalls.
Will run e2e tests for TAPs as well.
Anyway, let's get rid of the timeout and see if any issues appear (if yes, we can do this for example for VPP TAP, but not for VETH).
I think we will need to find a way to avoid sleeps/delays totally and somehow figure out which inter-states to ignore, because these sleeps make configuration of interfaces veeeery slow (see #1739)
Btw. I don't think pendingIntfs map and running applyDelayedNotification as go routine is needed anymore. Also "applyDelayedNotification" is probably not a good name anymore.
Will fix that before merge, just wanted travis to run tests on this.
Signed-off-by: Ondrej Fabry <ofabry@cisco.com>
Tests seem to be passing for both TAPs and VETHs. |
This PR is a fix for #1739
Agent log showing all received notifications for same config as in #1734: