A phone meeting of the TIPC working group was held on August 30, 2007. Attendees:
Al Stephens (Wind River) -- meeting chair; Elmer Horvath (Wind River); Randy MacLeod (Nortel); Jon Maloy (Ericsson); Ravi Rao (Nortel associate) Minutes: 1. Meeting opening The meeting was called to order at 11:07 AM (EDT). 2. TIPC virtualization update Randy outlined the major obstacles preventing the support of 2 (or more) TIPC stacks on the same node. a) Selection of stack by applications: Randy/Ravi's prototype utilizes a new socket address family, AF_TIPC_DATA, to access a 2nd stack. Al asked if it was a requirement that an application be able to access more than one stack; Randy was unsure, but thought that it was. Al observed that the prototype approach would not be acceptable to the Linux kernel team, and suggested using the unused "protocol" argument of the socket() routine to specify the desired stack. For example, socket(AF_TIPC, SOCK_STREAM, 1) could associate the socket with the 2nd stack, while socket(..., ..., 2) would tie it to the 3rd stack, etc.; it would be up to the application to know which stack it needed to use. The revised proposal was acceptable to Randy. Randy also asked for the ability to access multiple stacks from kernel space. Al pointed out that VxWorks TIPC provides a socket API to kernel applications, allowing the socket() technique to be used there, too; Randy thinks there may be a socket-like API that could be used in the Linux kernel, but this requires further investigation. Al suggested that the existing native API for TIPC could probably be adapted to support multiple stacks by encoding the stack ID into the port ID when the port was created (as part of the 32 bit "reference" value); this may in fact be necessary to allow the socket() technique to work properly. b) Routing incoming messages to the proper stack: Al asked if it was a requirement that different TIPC stacks be able to "share" the same physical interface; Randy said it was not a current requirement, but was desirable for a general purpose solution. Al suggested that an easy solution would be to continue associating a bearer with a specified interface (as is currently done), and achieve sharing through the use of multiple bearers (one for each stack) with each bearer using a separate Ethernet VLAN. c) Selection of stack by tipc-config: Al observed that, once issue a) was solved, commands could be directed to the desired TIPC stack (via the TIPC message API, rather than the Netlink API) by introducing a new option that identified the desired stack (similar to the existing "-dest" option). It was left open as to whether it was necessary to provide this capability using Netlink, too. Following the discussion on these issues, there was discussion about whether support for multiple stacks would involve duplication of the existing TIPC kernel module (as in the current prototype). Jon raised concerns that having multiple copies of the code would be undesirable, and suggested duplicating only the data portion of the module. Al asked if the size of the duplicated TIPC code (approx 100 KB per stack) was really significant for Linux systems having many MB (or GB!) of memory. Elmer also pointed out that having separate modules might make it easier to load/unload TIPC stacks on the fly, and also allow different stacks to run different versions of TIPC (which might be helpful to avoid having to re-test existing applications on existing TIPC stacks when a new TIPC stack is added). The issue was left for future study, as it was agreed that the separate module approach was acceptable for Randy's current needs. Randy indicated that he would create the second module using scripts that would duplicate & modify the code for the "standard" TIPC stack. Jon also suggested that there may be a need/opportunity to extend the current <Z.C.N> notation to allow it to indicate which network or IP stack was being used, perhaps as <network.Z.C.N> or <stack.Z.C.N>. This should be kept in mind as the virtualization work proceeds. Ravi and Randy will continue working on the virtualization effort, and keep the TIPC community informed of their progress via the TIPC mailing list. 3. Message buffer headroom It was agreed that the sk_buff headroom for Linux TIPC would be increased from 20 bytes to 24 bytes to accommodate the needs of the gianfar driver. Al will submit the change to TIPC 1.7.5; the change will also be carried into the mainstream Linux kernel when the TIPC 1.8 porting effort begins (hopefully in September). 4. Meeting close The meeting adjourned at 12:05. The next meeting is scheduled for Thursday, September 27 at 11:00 AM EDT. Please let me know of any errors or omissions. Regards, Al Stephens [END] ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ tipc-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tipc-discussion
