[tipc-discussion] Comments on TIPC SOCK_STREAM protocol overhead?

[<lo...@ai...>]

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