[Tcpinst-wg] TCP Instrumentation BoF Video

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


For those that weren't at the conference of the BoF Jamal and Harout 
were kind enough to make the video available.


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.

Tcpinst-wg mailing list

To UNSUBSCRIBE visit https://lists.psc.edu/mailman/unsubscribe/tcpinst-wg

[Index of Archives]     [Linux Kernel]     [Networking Development]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]