svn commit: r289276 - in head/sys: conf kern netinet sys
Bryan Drewery
bdrewery at FreeBSD.org
Wed Oct 14 02:39:34 UTC 2015
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20151013/a466c8fa/attachment.bin>
More information about the svn-src-all
mailing list