Date: Tue, 13 Oct 2015 18:58:35 -0700 From: Bryan Drewery <bdrewery@FreeBSD.org> To: Hiren Panchasara <hiren@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r289276 - in head/sys: conf kern netinet sys Message-ID: <561DB6CB.8060208@FreeBSD.org> In-Reply-To: <201510140035.t9E0ZbXS030094@repo.freebsd.org> References: <201510140035.t9E0ZbXS030094@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 10/13/2015 5:35 PM, Hiren Panchasara wrote: > Author: hiren > Date: Wed Oct 14 00:35:37 2015 > New Revision: 289276 > URL: https://svnweb.freebsd.org/changeset/base/289276 > > Log: > There are times when it would be really nice to have a record of the last few > packets and/or state transitions from each TCP socket. That would help with > narrowing down certain problems we see in the field that are hard to reproduce > without understanding the history of how we got into a certain state. This > change provides just that. > > It saves copies of the last N packets in a list in the tcpcb. When the tcpcb is > destroyed, the list is freed. I thought this was likely to be more > performance-friendly than saving copies of the tcpcb. Plus, with the packets, > you should be able to reverse-engineer what happened to the tcpcb. > > To enable the feature, you will need to compile a kernel with the TCPPCAP > option. Even then, the feature defaults to being deactivated. You can activate > it by setting a positive value for the number of captured packets. You can do > that on either a global basis or on a per-socket basis (via a setsockopt call). > > There is no way to get the packets out of the kernel other than using kmem or > getting a coredump. I thought that would help some of the legal/privacy concerns > regarding such a feature. However, it should be possible to add a future effort > to export them in PCAP format. > > I tested this at low scale, and found that there were no mbuf leaks and the peak > mbuf usage appeared to be unchanged with and without the feature. > > The main performance concern I can envision is the number of mbufs that would be > used on systems with a large number of sockets. If you save five packets per > direction per socket and have 3,000 sockets, that will consume at least 30,000 > mbufs just to keep these packets. I tried to reduce the concerns associated with > this by limiting the number of clusters (not mbufs) that could be used for this > feature. Again, in my testing, that appears to work correctly. > > Differential Revision: D3100 You're supposed to use the full URL here which will auto close the review. I also replied to the review with style findings just now. > Submitted by: Jonathan Looney <jlooney at juniper dot net> > Reviewed by: gnn, hiren -- Regards, Bryan Drewery [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWHbbLAAoJEDXXcbtuRpfPB/4H/3P1hZB1isrORq4mgN9YQAOQ TMM88kjMNpVs3od6IZsRDufOZKd5sXIK0x4ergVgk8UrGBYIKWxjd9u+svX+Wq5t JrxEyQLIdJXbpgD3LEPwDjTJyIOWcnIs80Kxnaa1+USQqMc75tKBr/lvjS78kLsy eSoUlYH67cWqiz8s+/6jtjiCqjzgy9JlqyZmlwF4rOfmUQizAnXWdQspfHaZMAUM KXEEc4+FjSDIlZHZAXwTxuns0JdgFsXT7N2DgY6sIaUa9feagDbK1tDOFt6x8vkS S+T1W+l40SoGhcZ10dR2Yv7PvWyCeRWhDDiuYCceuU7DNVGTu/HrelOf6Py15J4= =z4aT -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?561DB6CB.8060208>