Add UMA for the kernel's TCP RTT estimate.

net/socket/tcp_socket_libevent.h

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef NET_SOCKET_TCP_SOCKET_LIBEVENT_H_
 #define NET_SOCKET_TCP_SOCKET_LIBEVENT_H_
 
 #include "base/basictypes.h"
 #include "base/callback.h"
 #include "base/compiler_specific.h"
 #include "base/memory/scoped_ptr.h"
+#include "base/time/time.h"
 #include "net/base/address_family.h"
 #include "net/base/completion_callback.h"
 #include "net/base/net_export.h"
 #include "net/log/net_log.h"
 
 namespace net {
 
 class AddressList;
 class IOBuffer;
 class IPEndPoint;
@@ skipping 34 matching lines @@
   // The commonly used options for client sockets and accepted sockets:
   // - SetNoDelay(true);
   // - SetKeepAlive(true, 45).
   void SetDefaultOptionsForClient();
   int SetAddressReuse(bool allow);
   int SetReceiveBufferSize(int32 size);
   int SetSendBufferSize(int32 size);
   bool SetKeepAlive(bool enable, int delay);
   bool SetNoDelay(bool no_delay);
 
+  // Gets the estimated RTT. Returns false if the RTT is
+  // unavailable. May also return false when estimated RTT is 0.
+  bool GetEstimatedRoundTripTime(base::TimeDelta* out_rtt) const;

[Jana, 2015/07/08 12:33:29]

Since 0 is a special case that indicates failure, why not simply return 0 on
failure and non-zero values for all legit out values?

[Bryan McQuade, 2015/07/08 13:26:07]

Thanks Jana! I'll defer to Matt on the decision here, but my thought is that
with a signature like 'RetVal Fn();' it's easy for callers to miss that zero
indicates failure, which means they end up incorrectly using the zero value as
the estimated RTT. This is really undesirable and could lead to bugs.

We can document this behavior in a comment in the header file, but devs don't
always consult headers - many times they see a method used elsewhere in the code
and start using it without consulting the header, so I think it's important for
the method's signature alone to clearly explain method behavior as much as
possible.

The 'bool Fn(Param* out)' signature is a little more cumbersome, but I claim
it's much harder for callers to mistakenly miss the failure case with a
signature like this.

I'm actually inclined to go a step further and add WARN_UNUSED_RESULT to the
signature, to make sure callers always observe the return value. I see this
pattern used elsewhere in net:
https://code.google.com/p/chromium/codesearch#search/&q=bool%5C%20.*WARN_UNUS...

What do you think?

+
   void Close();
 
   // Setter/Getter methods for TCP FastOpen socket option.
   bool UsingTCPFastOpen() const;
   void EnableTCPFastOpenIfSupported();
 
   bool IsValid() const;
 
   // Marks the start/end of a series of connect attempts for logging purpose.
   //
@@ skipping 129 matching lines @@
   bool logging_multiple_connect_attempts_;
 
   BoundNetLog net_log_;
 
   DISALLOW_COPY_AND_ASSIGN(TCPSocketLibevent);
 };
 
 }  // namespace net
 
 #endif  // NET_SOCKET_TCP_SOCKET_LIBEVENT_H_