Well, I still think the simplest thing is to make a new netlink protocol to maintain a cache table in the kernel and then a simple user space program that uses the user space RMPP interface (and trap subscription..) to do GetTable queries and uses netlink to groom the kernel cache. Basically exactly what you have now but seperated into two halfs.
This makes more sense to me. I thought you were suggesting that the entire implementation be in user space.
The main thing is to pick the kernel's table structure so that it can be extended to support future things like multipath, QOS and routers..
Multipath is already supported, but I'm storing path records, not creating them from tables currently. QoS support is a more immediate concern, but I believe we can have a fairly simple set of tables to support that. Routers will present more of a challenge.
I don't like the notion of communicating with the kernel using MADs, it doesn't seem like it fits with the rest of the kernel networking model. When/if a network component to SA distribution is built it should be handled in user space and the kernel should be completely unrelated..
I was trying to say that the interface to the local SAs that keeps them in sync with the master SA should be MAD based. (It doesn't have to be, but that's how I would implement it.) I would not use MADs to program the tables.
I will see about separating the two parts of the local SA. - Sean _______________________________________________ general mailing list general@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
