Sebastien Roy wrote: > In addition to the responses that Sangeeta already provided in the > issues file, the relevant parts of today's Inception review were: > > * Regarding djr-00 and the general interaction with filtering hooks: > > There isn't very much ILB specific code in the ip kernel module itself. > Only the hooks are part of the IP datapath code, and those don't > comprise very much code.
Thanks for the clairification. The design document didn't give that impression. > Erik Nordmark gave an overview of the reasons why filtering hooks aren't > a good fit for load balancing. Specifically, there are requirements on > the location of the hooks which the filtering hooks don't meet, as well > as issues regarding the ordering of the hook callbacks. There are also > semantic requirements of the load balancing hooks (the ability to change > the next hop on output for example) that the filtering hooks don't > provide in an efficient way. What I am looking for is a new packet event, not the reuse of an existing one, that has different semantics to those used for packet filtering (firewall.) A load balancr needs to interact with the packet in a different way to a firewall/NAT, so I see no reason why hooks designed to support those specific features should be reused for load balancing or as the template from which to create a load balancing packet event. > There were concerns raised that the lack of a general-purpose hook > mechanism (despite the claims that there is already such a mechanism, it > doesn't appear to be the case) is leading to exploding complexity in the > IP implementation. Erik noted that the existence of a general-purpose > hook mechanism would not necessarily address the complexity problem due > to the sensitive nature of the interactions between the different hook > consumers. If the general purpose mechanism isn't general purpose enough then it behooves us to document what its failings are and try to improve it. Additionally, we should make a better attempt to use existing interfaces and improve them as required (especially when the idea is to promote them for external use) rather than baking new, private, ones every time we have a slightly different programming task. Darren
