...
All policies are stored in kernel space. All logic to add, delete and match policies will be implmented implemented in user space. This complicates the kernel space processing. Arguably, policy maintenance logic is not core to LNet functionality. What is core is the ability to select source and destination networks and NIDs in accordance with user definitions.
...
In this approach all the policy parsing and storage happens in user space. The kernel API is kept very simple. It'll just provide a way to set actions on LNet constructs, IE networks, NIDs and routers. A user space utility, lnetctl, will parse policies and store them in a persistent file. Whenver Whenever lnetctl is used to add a net or a peer explicitly, then it will read the policy file and apply policy actions on construct being created in the kernel.
However, since the kernel has no concept of policies, if peers are created internally, as they usually are, then these policies can not be applied. One method to get around this issue to implement uevents. Whenever a peer is created a a uevent is fired to userspaceuser space. This This uevent results in the policy file being read and if there is a match against one of the policies in the file, then the peer is updated appropriately. There is a period of time between the creation of the peer and the handling of the the uevent in userspace user space where the policy is not applied and therefore traffic patterns might not conform to user specified behavior definition until the peer is updated.
...