[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160328054210.GA30968@DHCP.thefacebook.com>
Date: Sun, 27 Mar 2016 22:42:10 -0700
From: Martin KaFai Lau <kafai@...com>
To: Yuchung Cheng <ycheng@...gle.com>
CC: Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Network Development <netdev@...r.kernel.org>,
Kernel Team <kernel-team@...com>,
Eric Dumazet <edumazet@...gle.com>,
Neal Cardwell <ncardwell@...gle.com>,
Willem de Bruijn <willemb@...gle.com>,
Soheil Hassas Yeganeh <soheil@...gle.com>
Subject: Re: [RFC PATCH] tcp: Add SOF_TIMESTAMPING_TX_EOR and allow MSG_EOR
in tcp_sendmsg
On Fri, Mar 25, 2016 at 04:05:51PM -0700, Yuchung Cheng wrote:
> Looks like an interesting and useful patch. Since HTTP2 allows
> multiplexing data stream frames from multiple logical streams on a
> single socket,
> how would you instrument to measure the latency of each stream? e.g.,
>
> sendmsg of data_frame_1_of_stream_a
> sendmsg of data_frame_1_of_stream_b
> sendmsg of data_frame_2_of_stream_a
> sendmsg of data_frame_1_of_stream_c
> sendmsg of data_frame_2_of_stream_b
A quick recall from the end of the commit message:
"One of our use case is at the webserver. The webserver tracks
the HTTP2 response latency by measuring when the webserver
sends the first byte to the socket till the TCP ACK of the last byte
is received."
It is the server side perception on how long does it take to deliver
the whole response/stream to the client. Hence, the number of
interleaved streams does not matter.
Some sample use cases are,
comparing TCP sysctl/code changes,
observing encoding/compression impact (e.g. HPACK in HTTP2).
Assuming frame_2 is the end stream for 'a' and 'b':
sendmsg of data_frame_1_of_stream_a
sendmsg of data_frame_1_of_stream_b
sendmsg of data_frame_2_of_stream_a MSG_EOR
sendmsg of data_frame_1_of_stream_c
sendmsg of data_frame_2_of_stream_b MSG_EOR
Are you suggesting other useful ways/metrics should be measured in
this case?
Powered by blists - more mailing lists