For those that weren't at the conference of the BoF Jamal and Harout were kind enough to make the video available. https://www.youtube.com/watch?v=6VuniIff9z0 We also have more than a few new people on this list so I'm reposting the first message. Skip this part if you've already read it: I want to thank you for taking the time to attend the instrumentation BoF at NetDev 0.1 and agreeing to join this list. I was pleased that there was a general consensus reached regarding the value of stack instrumentation. Determining how the community felt about that was the primary reason for organizing the BoF. Also, I'm a bit long winded so I'm sorry if this message is on the long side. Here is my takeaway from the discussion. There should be two sets of instruments. Operational and diagnostic. The operational instruments will be be used to extend TCP_INFO and will always be available. Google will be providing a patch for upstream with 8 instruments in this category. The diagnostic instruments will be enabled by the user on an as needed basis. These data from these instruments will be stored in a separate structure that is referenced by a pointer in the socket or some other mechanism. The ability to only enable a subset of these instruments should be a design goal. The results need to be made available as self defining binary data so that the addition of new diagnostic instruments won't break existing code. We may want to consider if there are other methods to do this as well. A couple of other points were also brought up regarding ebpf and netlink that, I have to admit, I'm blanking on at the moment. If people have their own impressions of what was discussed or have ideas, comments, etc please share them. The most important thing is that the framework needs to be established before the instruments. Once the framework is in place we can add instruments as needed. Ideally I'd love to have the framework be flexible enough to apply to non-TCP protocols in the future. Now, my team does have a program called Web10G that developed TCP_ESTATS (TCP Extended STATisticS). This code *may* be a useful place to start from as we've addressed a number of issues already. If anyone would like to review that code we have patches at http://www.web10g.org/ and a full tree at http://github.com/rapier1/web10g. If you checkout the git the KIS branch is the kernel instrument set and management code. The Web10G branch adds a kernel module. We also have an API and example code at web10g.org and at http://github.com/rapier1/web10g-userland Again, this is just what we've worked on and it may be useful. If it's not useful that's alright. I don't actually care about our code as much as just getting a decent set of instruments on to the stack. Lastly, I want to be honest with everyone - this is the first time I've worked in a setting like this with the Linux community. I'm sure I'm going to make some mistakes or just not get something. If I do please just let me know as I take criticism pretty well. Chris _______________________________________________ Tcpinst-wg mailing list Tcpinst-wg@xxxxxxx https://lists.psc.edu/mailman/listinfo/tcpinst-wg To UNSUBSCRIBE visit https://lists.psc.edu/mailman/unsubscribe/tcpinst-wg