From owner-svn-src-head@freebsd.org Wed Oct 14 01:58:37 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 2B40DA12469; Wed, 14 Oct 2015 01:58:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0F1E41386; Wed, 14 Oct 2015 01:58:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 07C361F21; Wed, 14 Oct 2015 01:58:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id A60B31478B; Wed, 14 Oct 2015 01:58:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id IfHIpPjWOjLL; Wed, 14 Oct 2015 01:58:33 +0000 (UTC) Subject: Re: svn commit: r289276 - in head/sys: conf kern netinet sys DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 4017E14786 To: Hiren Panchasara , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201510140035.t9E0ZbXS030094@repo.freebsd.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <561DB6CB.8060208@FreeBSD.org> Date: Tue, 13 Oct 2015 18:58:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <201510140035.t9E0ZbXS030094@repo.freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0D5kKgEWArLKnGdWa4UEsafH2lo4Ff3Ag" 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 01:58:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0D5kKgEWArLKnGdWa4UEsafH2lo4Ff3Ag Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 You're supposed to use the full URL here which will auto close the review= =2E I also replied to the review with style findings just now. > Submitted by: Jonathan Looney > Reviewed by: gnn, hiren --=20 Regards, Bryan Drewery --0D5kKgEWArLKnGdWa4UEsafH2lo4Ff3Ag Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----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----- --0D5kKgEWArLKnGdWa4UEsafH2lo4Ff3Ag--