On 10/30/19 4:11 AM, Jon Maloy wrote:
> We introduce a feature that works like a combination of TCP_NAGLE and
> TCP_CORK, but without some of the weaknesses of those. In particular,
> we will not observe long delivery delays because of delayed acks, since
> the algorithm itself decides if and when
From: Hoang Le
Date: Tue, 29 Oct 2019 07:51:21 +0700
> Currently, TIPC transports intra-node user data messages directly
> socket to socket, hence shortcutting all the lower layers of the
> communication stack. This gives TIPC very good intra node performance,
> both regarding throughput and
Hi Ying,
You're right. I'll fix this. Anyway, I just realized another improvement I
could make, so I'll send a new version with both changes.
Regards
///jon
> -Original Message-
> From: Ying Xue
> Sent: 29-Oct-19 06:24
> To: Jon Maloy ; Jon Maloy
> Cc: Mohan Krishna Ghanta
On 10/29/19 1:37 AM, Jon Maloy wrote:
> @@ -3007,6 +3068,9 @@ static int tipc_setsockopt(struct socket *sock, int
> lvl, int opt,
> case TIPC_GROUP_LEAVE:
> res = tipc_sk_leave(tsk);
> break;
> + case TIPC_NODELAY:
> + tsk->nodelay = true;
> +
On 10/25/19 12:28 AM, Jon Maloy wrote:
> 1) TIPC_NODELAY might be a good option, although I fear people might misuse
> it in the belief that TIPC nagle has the same disadvantages as TCP nagle,
> which it doesn't.
> But ok, I'll add it.
>
> 2) CONN_PROBE/CONN_PROBE_REPLY are not considered
