libnetwork/osl: stop tracking neighbor entries#50088
Merged
robmry merged 4 commits intomoby:masterfrom May 27, 2025
Merged
Conversation
func (*Namespace) AddNeighbor is only ever called with the force parameter set to false. Remove the parameter and eliminate dead code. Signed-off-by: Cory Snider <csnider@mirantis.com>
Scope local variables as narrowly as possible. Signed-off-by: Cory Snider <csnider@mirantis.com>
The isDefault and nlHandle fields are immutable once the Namespace is constructed. Signed-off-by: Cory Snider <csnider@mirantis.com>
The Namespace keeps some state for each inserted neighbor-table entry which is used to delete the entry (and any related entries) given only the IP and MAC address of the entry to delete. This state is not strictly required as the retained data is a pure function of the parameters passed to AddNeighbor(), and the kernel can inform us whether an attempt to add a neighbor entry would conflict with an existing entry. Get rid of the neighbor state in Namespace. It's just one more piece of state that can cause lots of grief if it falls out of sync with ground truth. Require callers to call DeleteNeighbor() with the same aguments as they had passed to AddNeighbor(). Push the responsibility for detecting attempts to insert conflicting entries into the neighbor table onto the kernel by using (*netlink.Handle).NeighAdd() instead of NeighSet(). Modernize the error messages and logging in DeleteNeighbor() and AddNeighbor(). Signed-off-by: Cory Snider <csnider@mirantis.com>
There was a problem hiding this comment.
Pull Request Overview
This pull request removes the in-memory tracking of neighbor entries in the namespace and pushes neighbor management entirely to the kernel. Key changes include:
- Refactoring AddNeighbor and DeleteNeighbor to remove state management and instead rely on netlink operations.
- Eliminating the neighbors slice from the Namespace struct.
- Updating callers in the overlay driver to match the new function signatures.
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| libnetwork/osl/neigh_linux.go | Refactored neighbor add/delete functions and error messaging. |
| libnetwork/osl/namespace_linux.go | Removed neighbor state field from the Namespace struct. |
| libnetwork/osl/interface_linux.go | Simplified interface removal by directly using n.nlHandle. |
| libnetwork/drivers/overlay/peerdb.go | Updated neighbor API calls to match the new function signatures. |
Comments suppressed due to low confidence (2)
libnetwork/osl/neigh_linux.go:89
- [nitpick] Consider renaming the variable 'nlnh' to a more descriptive name (e.g., 'neighEntry') to better reflect its content and improve code clarity.
nlnh, linkName, err := n.nlNeigh(dstIP, dstMac, options...)
libnetwork/osl/interface_linux.go:831
- Confirm that accessing 'n.isDefault' without a lock remains safe; if 'n.isDefault' is mutable and accessed concurrently, consider using synchronization or atomic variables.
} else if !n.isDefault {
e0d5d62 to
0d6e7cd
Compare
thaJeztah
reviewed
May 27, 2025
Comment on lines
+23
to
+26
| func (n NeighborSearchError) Error() string { | ||
| var b strings.Builder | ||
| b.WriteString("neighbor entry ") | ||
| if n.present { |
Member
There was a problem hiding this comment.
This was the only part I had a comment on in the other PR. Non-blocking (from my perspective), but reposting here for others; #50081 (comment)
Not a blocker, but was mostly looking here for trade-offs between performance-optimisation (strings.Builder) and discoverability (being able to grep for the (partial) error message); wasn't sure how much this error is in a "hot path".
Contributor
Author
There was a problem hiding this comment.
I actually used the strings.Builder approach for readability rather than optimization. Note that there are two branches. To achieve something similar with fmt.Sprintf is not much more greppable. E.g.:
s := fmt.Sprintf("neighbor entry %s for IP %v, mac %v", map[bool]string{true: "already exists", false: "not found"}, n.ip, n.mac)
if n.linkName != "" {
s += fmt.Sprintf(", link %v", n.linkname)
}
return s
Member
There was a problem hiding this comment.
Fair point. I guess I was comparing to the old;
return fmt.Sprintf("Search neighbor failed for IP %v, mac %v, present in db:%t", n.ip, n.mac, n.present)grepping for neighbor entry gave me many results, but perhaps there's no good option for that.
robmry
approved these changes
May 27, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
- What I did
The Namespace keeps some state for each inserted neighbor-table entry which is used to delete the entry (and any related entries) given only the IP and MAC address of the entry to delete. This state is not strictly required as the retained data is a pure function of the parameters passed to AddNeighbor(), and the kernel can inform us whether an attempt to add a neighbor entry would conflict with an existing entry. Get rid of the neighbor state in Namespace. It's just one more piece of state that can cause lots of grief if it falls out of sync with ground truth.
- How I did it
Require callers to call DeleteNeighbor() with the same aguments as they had passed to AddNeighbor(). Push the responsibility for detecting attempts to insert conflicting entries into the neighbor table onto the kernel by using (*netlink.Handle).NeighAdd() instead of
NeighSet().
- How to verify it
The overlay network driver is the only consumer of the AddNeighbor/DeleteNeighbor API so to verify it, test that overlay networks are still capable of forwarding traffic between containers on different nodes.
docker service create --mode global -p 80:8080 nginxdemos/hello:plain-text- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)