From owner-svn-src-head@freebsd.org Wed Oct 14 02:33:53 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B42EDA12E2A; Wed, 14 Oct 2015 02:33:53 +0000 (UTC) (envelope-from hiren@FreeBSD.org) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 971161B37; Wed, 14 Oct 2015 02:33:53 +0000 (UTC) (envelope-from hiren@FreeBSD.org) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 4890A10962B; Tue, 13 Oct 2015 19:33:52 -0700 (PDT) Date: Tue, 13 Oct 2015 19:33:52 -0700 From: Hiren Panchasara To: Bryan Drewery , 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> References: <201510140035.t9E0ZbXS030094@repo.freebsd.org> <561DB6CB.8060208@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mFHiwr52TKrxpkjc" Content-Disposition: inline In-Reply-To: <561DB6CB.8060208@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 02:33:53 -0000 --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--