Hi Jon: Recently, a couple of us here at Wind River did an experiment to see if we could improve the performance of TIPC. We modified TIPC on VxWorks to enhance the "unreliable" nature of SOCK_DGRAM traffic by instructing TIPC not to clone messages that were marked as "source droppable" in the TIPC message header. This made the traffic more UDP-like, and resulted in 20% improvement in throughput. I'm not sure if we would see similar gains with Linux TIPC, but the non-trivial nature of skb_clone() suggests that we would see some measurable improvement.
Before going any further, I'd like to get your approval on the way in which this change would work. I'm proposing the following behavior: 1) A message marked as "source droppable" is assigned a sequence number, but is NOT added to the link's outbound message queue. 2) The bearer's send routine clones an outgoing message only if it is sent in a reliable manner. 3) If a link endpoint is asked to retransmit a message that is not present in its outbound message queue, it creates and sends a "header-only" message with the required sequence number. The message will contain invalid destination information that will cause the receiving node to silently discard the message after successfully satisfying the receiving link endpoint's sequence number validation. [Note: I know that this approach differs somewhat from suggestions you've made in the past for doing this sort of optimization, in that it requires the link to retransmit (fake) traffic if an "unreliable" message is lost, but I don't see that it is a significant difference since message loss is supposed to be very infrequent in TIPC anyway.] The main points in favour of this change are (in no particular order): 1) It should be easy to implement. 2) It should improve the performance on SOCK_DGRAM traffic by a non-trivial amount. 3) It makes the distinction between SOCK_DGRAM traffic and SOCK_RDM traffic much clearer than it currently is. 4) The change will inter-operate with existing TIPC 1.5/1.6/1.7 systems, because it is entirely local to the sending node's link endpoint. 5) It does not preclude us from adding other mechanisms to improve performance in the future. Please let me know what you think. (Comments from other TIPC folks are also welcome.) Regards, Al ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
