Date: Tue, 13 Oct 2015 19:33:52 -0700 From: Hiren Panchasara <hiren@FreeBSD.org> To: Bryan Drewery <bdrewery@FreeBSD.org>, jlooney@juniper.net Cc: 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: <20151014023352.GI87252@strugglingcoder.info> In-Reply-To: <561DB6CB.8060208@FreeBSD.org> References: <201510140035.t9E0ZbXS030094@repo.freebsd.org> <561DB6CB.8060208@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--mFHiwr52TKrxpkjc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/13/15 at 06:58P, Bryan Drewery wrote: > 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 > >=20 > > 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 hel= p 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. > > =20 > > It saves copies of the last N packets in a list in the tcpcb. When th= e 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. > > =20 > > To enable the feature, you will need to compile a kernel with the TCP= PCAP > > option. Even then, the feature defaults to being deactivated. You can= activate > > it by setting a positive value for the number of captured packets. Yo= u can do > > that on either a global basis or on a per-socket basis (via a setsock= opt call). > > =20 > > 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/priva= cy concerns > > regarding such a feature. However, it should be possible to add a fut= ure effort > > to export them in PCAP format. > > =20 > > I tested this at low scale, and found that there were no mbuf leaks a= nd the peak > > mbuf usage appeared to be unchanged with and without the feature. > > =20 > > The main performance concern I can envision is the number of mbufs th= at would be > > used on systems with a large number of sockets. If you save five pack= ets per > > direction per socket and have 3,000 sockets, that will consume at lea= st 30,000 > > mbufs just to keep these packets. I tried to reduce the concerns asso= ciated with > > this by limiting the number of clusters (not mbufs) that could be use= d for this > > feature. Again, in my testing, that appears to work correctly. > > =20 > > Differential Revision: D3100 >=20 > You're supposed to use the full URL here which will auto close the review. Okay. It did pick up the commit though. What more does it need to know?=20 >=20 > I also replied to the review with style findings just now. > I'll ask Jonathan to look at it. Cheers, Hiren --mFHiwr52TKrxpkjc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWHb8NXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lih8H/jdkLUaGUPTs35aJM2S+8vnJ c+3uR4qlWHNbaz3PMut+sODixhxo44j4HqDlU3cv1Yl+hvtCXLexjxMf5FbzZ+fy 1WMei/LT6pcLc81bZVNrLwF1leiqIXPk8JDHBZk5c8D3NuzPamBTJSp9LZZAMgZ0 aBCHl0UcFCVKAglsH2R1ybCpTJk5daOaadnPXb9pxDvnyPGSBFqkwqMz6VSqDg3R s7kJVwB7rGI0S66U90Mrkf2YLgrkOacaFBW2D+D4lTbtE7B4mEnv+ytzbm74t19M d37ep7/r0RY9wys70lXfwEBeTJD2NEuW+unkSkpe6I5uQ+rlie3093IEdfpGLHw= =E3F4 -----END PGP SIGNATURE----- --mFHiwr52TKrxpkjc--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151014023352.GI87252>