...
- when it's first added to the system.
- The problem with this is it doesn't work if the router is not up yet. You fail to discover it when its added, so when would you try to discover it again?
- When it's first used - This is the option which will be implemented
- This is the most reasonable solution, since we check if the router has already been discovered when we first attempt to use and if it has not we initiate discovery. We will need to deal with this as we would discovery final destination in the sense that we'll need to queue the message to be sent once we finish discovery the router.
Different routes can be added using different NIDs of the same gateway. When the gateway is discovered on first use there will be a need to consolidate the routing information.
For example, let's take the scenario where SET-A of routes were entered through the gateway using GW-NID-A and SET-B of routes were entered through the gateway using GW-NID-B. This will create the following structure:
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
When the GW is discovered three scenarios are possible:
- GW-NID-A is the primary NID
- GW-NID-B is the primary NID
- GW-NID-X is the primary NID
In all these cases we will need to consolidate the routing information as follows:
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
In the discovery code the consolidation of the peer information is driven from: lnet_peer_data_present()
The change is tracked under: Option 2 will be implemented.
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
...