Page History

...

Performance needs to be taken into account with this feature. It is not feasible to traverse the policy lists on every send operation. This will add unnecessary overhead. When rules are applied they have to be "flattened" to the constructs they impact. For example, a Network Rule is added as follows: o2ib priority 0. This rule gives priority for using o2ib network for sending. A priority field in the network will be added. This will be set to 0 for the o2ib network. As we traverse the networks in the selection algorithm, which is part of the current code, the priority field will be compared. This is a more optimal approach than examining the policies on every send to see if it we get any matches.

Order of Operations

It is important to define the order of rule operations, when there are multiple rules that apply to the same construct.

The order is defined by the selection algorithm logical flow:

1. iterate over all the networks that a peer can be reached on and select the best local network
   1. The remote network with the highest priority is examined
      1. Network Rule
   2. The local network with the highest priority is selected
      1. Network Rule
2. If the peer is a remote peer and has no local networks,
   1. then select the remote peer network with the highest priority
      1. Network Rule
   2. Select the highest priority remote peer_ni on the network selected
      1. NID Rule
   3. Now that the peer's network and NI are decided select the router in round robin from the peer NI's preferred router list
      1. Router Rule
3. Otherwise for local peers, select the peer_ni from the peer.
   1. highest priority peer NI is selected
      1. NID Rule
4. Select the local NI to send from
   1. If the peer has a set of preferred local NIs select the highest priority from them. Otherwise select in round robin
      1. NID Pair Rule

DLC APIs

The DLC library will provide the outlined APIs to expose a way to create, delete and show rules.

...