summaryrefslogtreecommitdiffstats
path: root/sys/sys/mbuf.h
diff options
context:
space:
mode:
authorhiren <hiren@FreeBSD.org>2015-10-14 00:35:37 +0000
committerhiren <hiren@FreeBSD.org>2015-10-14 00:35:37 +0000
commit0d123061888740d00bc717c489bb0efd082eb2aa (patch)
treee9407f4691ef839048652676e32597147028fc78 /sys/sys/mbuf.h
parent891ebb5d1c21174bf8603121556ff1f9ef13d49a (diff)
downloadFreeBSD-src-0d123061888740d00bc717c489bb0efd082eb2aa.zip
FreeBSD-src-0d123061888740d00bc717c489bb0efd082eb2aa.tar.gz
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 Submitted by: Jonathan Looney <jlooney at juniper dot net> Reviewed by: gnn, hiren
Diffstat (limited to 'sys/sys/mbuf.h')
-rw-r--r--sys/sys/mbuf.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/sys/sys/mbuf.h b/sys/sys/mbuf.h
index 8d33550..119bb6d 100644
--- a/sys/sys/mbuf.h
+++ b/sys/sys/mbuf.h
@@ -524,6 +524,7 @@ extern uma_zone_t zone_jumbo9;
extern uma_zone_t zone_jumbo16;
extern uma_zone_t zone_ext_refcnt;
+void mb_dupcl(struct mbuf *, const struct mbuf *);
void mb_free_ext(struct mbuf *);
int m_pkthdr_init(struct mbuf *, int);
OpenPOWER on IntegriCloud