lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 25 Jun 2014 17:11:01 -0400 From: Willem de Bruijn <willemb@...gle.com> To: Richard Cochran <richardcochran@...il.com> Cc: netdev@...r.kernel.org, Eric Dumazet <eric.dumazet@...il.com>, David Miller <davem@...emloft.net> Subject: Re: net-timestamp: MSG_TSTAMP flags and bytestream support Thanks for taking a look, Richard. I will reply inline to the individual emails. On Wed, Jun 25, 2014 at 3:32 AM, Richard Cochran <richardcochran@...il.com> wrote: > On Tue, Jun 24, 2014 at 11:43:45AM -0400, Willem de Bruijn wrote: >> This patchset extends socket timestamping in a number of related ways. >> Most notably: >> >> 2 MSG_TSTAMP: request a single tx timestamp by passing a flag on send >> 6 MSG_TSTAMP_ENQ: request a tx timestamp before traffic shaping. >> 5 MSG_TSTAMP_ACK: request a tx timestamp after acknowledgements (TCP) >> 4 TCP support for all three flags > > Can you tell us a bit about the use case? It sounds like that this is > for performance monitoring. There are a couple of use cases: 24/7 sampled background monitoring, detailed analysis of (tail) latency and application delivery notifications, for example. The MSG flags enable sampled measurement, both random sampling for the first use case, and explicit communication of application data unit delimiters to the kernel in the case of bytestreams. It is quite common to embed discrete message protocols in a TCP stream to gain reliability, flow control, ... In that case, only the send() call that writes the final byte of a message will generate a timestamp that is relevant to the application. The new measurement points are indeed for performance monitoring, specifically for debugging of tail latency root causes. Traffic shaping, TCP pacing, byte queue limits and other queuing can affect latency. Measurement points along the skb lifecycle help pinpoint the specific root cause. >> Each individual patch commit message gives more detail about the >> specific feature. >> >> The other patches support the main feature: >> 1 explicitly define the timestamp response API >> 3 optionally avoid looping large packets onto the socket error queue. >> 7 documentation and an example test. > > I think #2 and #3 could be improvements to the so_timestamping api. > > The others probably need their own, separate api. I can't imagine > wanting to mix so_timestamping with these new tcp time stamps, but > maybe you want to explain the expected scenario? I think that a single coherent timestamping API would be better than a fragmented experience with disjoint feature set. Both depend internally on the same SKBTX_.. flags and the same skb_tstamp_tx plumbing. I think that they should also implement the same set feature set and return timestamps in the same format (where possible given legacy API constraints). This requires extensions to both to cover the other's feature set, e.g., MSG_TSTAMP_HW and SOF_TIMESTAMPING_TX_ENQUEUE. But those are minor changes. I'd be happy to work on those as follow on work. > > Thanks, > Richard -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists