Date: Sun, 16 Mar 2014 14:21:06 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Hooman Fazaeli <hoomanfazaeli@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Rui Paulo <rpaulo@freebsd.org>, Ian Lepore <ian@freebsd.org> Subject: Re: mbuf question Message-ID: <20140316212106.GF32089@funkthat.com> In-Reply-To: <5325BC99.2060703@gmail.com> References: <53230214.7010501@gmail.com> <BBAFAB2A-F496-46A2-8FE0-224BE562EAA7@FreeBSD.org> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> <5324DAC0.9020508@gmail.com> <1394925228.1149.558.camel@revolution.hippie.lan> <BEA4D691-6405-4D5B-B437-DAEB655D45EF@FreeBSD.org> <5325BC99.2060703@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hooman Fazaeli wrote this message on Sun, Mar 16, 2014 at 19:30 +0430:
> On 3/16/2014 9:01 AM, Rui Paulo wrote:
> >On 15 Mar 2014, at 16:13, Ian Lepore <ian@FreeBSD.org> wrote:
> >>How about an optimization that puts tags in that area when it's
> >>available to avoid the allocation overhead? I don't know much about the
> >>network code, so maybe that's not a sensible idea.
> >The problem with mbuf tags is that they are not fixed size, so they can't
> >easily use UMA (although they use malloc which is backed by UMA, but the
> >performance is lower). If tags are not an option, I suppose Hooman could
> >use fields from struct pkthdr, but this might come with risks if the code
> >is not in the tree.
> >
> >--
> >Rui Paulo
>
> pkthdrdoes not seem to have any spare area for custom use.
>
> I wanted to add L2 filtering capabilities to pf(4) firewall, and the first
> problem
> I faced was how to make L2 headers (src/dst ethernet addresses) available
> to pf.
> That (seemingly) unused part of mbuf+cluster seemed a good place to store
> ethernet
> headers.
>
> We already have vlan tag (a sort of L2 data) in pkthdr. What do you think
> about the idea of having a dedicated area for L2 information in mbufs?
Why do we need this info in another location? Isn't this already in
the packet? How else did we get it then? Or are you dealing w/ the
fact that the L2 information was stripped by an upper layer, and if
that is the case, shouldn't you be getting the packet soon then?
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140316212106.GF32089>