On 10/13/2015 7:33 PM, Hiren Panchasara wrote: > 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 >>> >>> 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. > > Okay. It did pick up the commit though. What more does it need to know? >>
Hm true. It seems that it will auto-close if you use the full URL only. I swear a decision was made on the "proper" way to relate these, but the fact that both methods touch the system and act different is odd. -- Regards, Bryan Drewery
signature.asc
Description: OpenPGP digital signature
