Date: Tue, 25 Apr 2000 22:11:28 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Archie Cobbs <archie@whistle.com> Cc: luigi@FreeBSD.ORG, remy@boostworks.com, csg@waterspout.com, pavel@alum.mit.edu, nsayer@sftw.com, julian@elischer.org, freebsd-net@FreeBSD.ORG Subject: Re: Proposal for ethernet, bridging, netgraph Message-ID: <200004260211.WAA61401@whizzo.transsys.com> In-Reply-To: Your message of "Tue, 25 Apr 2000 17:55:05 PDT." <200004260055.RAA55462@bubba.whistle.com> References: <200004260055.RAA55462@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Just a thought while looking at this code - in if_ethersubr.c where
the bpf process has been moved, the same idiom is repeated that
was in the drivers:
/* Check for a BPF tap */
if (ifp->if_bpf != NULL) {
struct mbuf m0;
/* OK because BPF treats the mbuf as read-only */
m0.m_next = m;
m0.m_data = (char *)eh;
m0.m_len = ETHER_HDR_LEN;
bpf_mtap(ifp, &m0);
}
Now that mbufs are 256 bytes long, is this getting to be too much data
to stick on the kernel stack? It seems like it's not a problem now, but
this code is now going to be invoked deeper in the stack than before.
If this code is running at splnet(), then it ought to be safe to just
have a static mbuf laying about for this purpose, rather than allocating
a local on the kernel stack.
louie
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004260211.WAA61401>