Hi All,
As you may remember, I've been working with Randy MacLeod on virtualizing
TIPC so that two TIPC stacks can be run on a cluster, where each node has a
separate connection to a control plane LAN and a data plane LAN.
I have a working prototype of a virtualized tipc stack.
I call it vtipc. Patches are appended, with build instructions for
tipc-1.5.12 included in the README.vtipc file.
Comments are appreciated. Sorry it's an older version of tipc.
I've tested:
Connectionless communication
Connection-oriented communication
Topology server
Multicast messaging
for both tipc and vtipc.
It all seems to work fine! ;-)
Here is the output of lsmod:
[EMAIL PROTECTED] multicast_demo]# lsmod |grep tipc
vtipc 245704 0
tipc 233504 1 vtipc
[EMAIL PROTECTED] multicast_demo]#
Here is the output of tipc-config [-P=1] -l
[EMAIL PROTECTED] tools]# ./tipc-config -P=1 -l
the args value is 1 protocol is 1
Links:
multicast-link: up
1.1.31:eth1-1.1.41:eth1: up
[EMAIL PROTECTED] tools]#
The changes required were related to:
1. socket registration,
2. netlink registration,
3. tipc-config stack selection.
1. Socket selection:
In tipc-1.5.12, provide APIs to allow vtipc to register a callback function
such that when the protocol from
socket(x,y,protocol) != 0 then the callback method in the vticp stack can be
called. This means that once a vtipc socket is created, the callback
functions go directly to vtipc.
All a user has to do is change the protocol parameter to the number that
corresponds to the vtipc stack (change 0 to 1).
2. Netlink Registration:
In tipc-1.5.12, provide an API to allow vtipc to register a callback
function. When tipc-config sets the netlink message element ->nlmsg_flags to
1, the tipc-config command gets passed to the vtipc stack.
3. tipc-config stack selection:
Added a parameter -P=x (x = 0 or 1 currently)
We haven't had to change AF_TIPC or the TIPC ethertype.
The code works but of course could be improved.
One change that I may make based on feedback from this list is to be able to
optionally separate the tipc code into two kernel modules:
1. A module to register AF_TIPC and NETLINK_TIPC callbacks with the kernel -
call it tipc_base.
2. A parameterized tipc module that doesn't include the code provided by
module 1. It would require a protocol id to be passed in when the module is
loaded so that it could register with tipc_base. I believe but haven't
proven that loading such a module twice would work just fine.
However our initial code changes and testing showed some kind of collisions
in kmem_cache_create(), also we see there to be atleast a few other
potential issues.
It would likely be possible to provide this module split as a kernel config
option.
We await comments on this prototype - don't worry about comments or minor
bugs in the code, etc but rather look at how vtipc has been designed and
coded.
P.S. the patches,demo programs and readme files will be sent by Randy in a
later mail..
Thanks,
Ravi & Randy
-------------------------------------------------------------------------
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
