On Tue, 2014-12-16 at 16:02 -0500, rapier wrote: > I understand where you are coming from. I do believe that our > methodology provides some advantages over a tcp_info solution. I'll > provide some information on that tomorrow after I've had a chance to > talk about this in more depth with our dev team. That being said, we > only really care about the instrument set being incorporated as such we > will take a closer look tcp_info shortly. Hmm... There is very little chance web10g ~3000 lines of code are added into linux TCP stack, by people who did not submit netdev changes in last years. At Google, we tried the web10g route, but reverted it (today !) in favor of tcp_info extensions (ss command from iproute2 can also grab/display these), after too many bugs being filled. Researchers love/want to have hundred of metrics. This does not mean linux has to provide them natively, unless we can prove it is really damn useful. Sorry, but someone had to raise some reality concerns. tcp_info _is_ extensible, granted you do not try to push 127 new metrics in it. http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=977cb0ecf82eb6d15562573c31edebf90db35163 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html