Hello there: Upstream TIPC's SOCK_STREAM implementation resembles SOCK_SEQPACKET; indeed, tipc_send_packet literally calls tipc_sendstream to do its job! I wonder whether the following stream protocol bandwidth issues are by design, or we could solve some or all of them:
* Lack of write coalescing usually introduces overhead in form of a small extra network frame for each send(2) unless buf_len is divisible by link MTU minus headers. * Fragmentation for SOCK_STREAM writes caused by upper record boundary set to TIPC_MAX_USER_MSG_SIZE [1] instead of (link MTU - SHORT_H_SIZE) [2]. * pktmax - INT_H_SIZE in msg.c effectively reduces link MTU by 40 even though the accounted space is left unused. [1] net/tipc/socket.c: send = min_t(size_t, dlen - sent, TIPC_MAX_USER_MSG_SIZE); [2] Drawing a parallel with TCP, which does not preserve record boundaries, (link MTU - SHORT_H_SIZE) is equivalent to TCP_MAXSEG, maximum segment size. P.S. Looks like someone saw the second issue more than a dozen years earlier, and his mail somehow slipped below the project's radar. https://sourceforge.net/p/tipc/mailman/message/7248018/ [tipc-discussion] TIPC SOCK_STREAM performance improvement idea From: Stephens, Allan <allan.stephens@wi...> - 2006-08-09 18:50:08 _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
