stenographer

I really like this DESIGN.md[1]. Might not be as code specific as what tfa is talking. I find design decisions really helpful when evaluating if a tool or solution is useful for my needs. Especially if it elaborates on priorities made in the project. [1] https://github.com/google/stenographer/blob/master/DESIGN.md

I've worked at Google for a while, and a few years ago I wanted to release an open-source project. Since the code was going on Git, it made sense to throw the design there too, so I just added a DESIGN.md to the top-level of the project. This has had a remarkably nice effect: sometimes, when people make large changes to the project, they update the design to reflect the changes! See this lovely commit as an example: https://github.com/google/stenographer/commit/d678531a3e5a87...

Some think it's very appropriate for high performance networking: https://github.com/google/stenographer Granted, that uses pfring pretty substantially, but still...

I'm aware of libpcap's ability to share memory with a user buffer, but I didn't find any mention that tcpdump utility is actually written to exploit it for extra fast writes. Look here how they handle this in stenographer: https://github.com/google/stenographer/blob/65fb928e6bce276c... I guess that in principle they could have patched tcpdump, but it's probably easier to have a smaller software written to do exactly what you want rather than extend a general purpose mature complex tool such as tcpdump.

The design document is a good read and includes high-level details of how they're grabbing packets (AF_PACKET), the packet index format (leveldb), and defensive action they took (fuzz testing via AFL, setcap, setcomp): https://github.com/google/stenographer/blob/master/DESIGN.md