Date: Tue, 25 Apr 2000 19:29:49 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: louie@TransSys.COM (Louis A. Mamakos) Cc: archie@whistle.com (Archie Cobbs), 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: <200004260229.TAA56138@bubba.whistle.com> In-Reply-To: <200004260211.WAA61401@whizzo.transsys.com> from "Louis A. Mamakos" at "Apr 25, 2000 10:11:28 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Louis A. Mamakos writes:
> 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.
Good point.. we could just use a struct m_hdr.. and in any case
it should be able to be a static variable.. we're at splnet().
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
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?200004260229.TAA56138>