Date: Sun, 16 Mar 2014 10:28:47 -0700 From: Rui Paulo <rpaulo@FreeBSD.org> To: Hooman Fazaeli <hoomanfazaeli@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@FreeBSD.org>, Ian Lepore <ian@FreeBSD.org> Subject: Re: mbuf question Message-ID: <6302F517-EA46-47C0-85F1-625383DA9EBF@FreeBSD.org> 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
On 16 Mar 2014, at 08:00, Hooman Fazaeli <hoomanfazaeli@gmail.com> =
wrote:
> 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.
>>=20
>> --
>> Rui Paulo
>=20
> pkthdrdoes not seem to have any spare area for custom use.
>=20
> 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.
>=20
> 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?
> Something like:
>=20
> struct pkthdr {
> ...
> struct {
> int link_type;
> uint8_t link_hdr[LINKHDR_MAXLEN];
> uint16_t link_vtag;
> ...
> } link;
> ...
> }
I don't understand your reluctance to use mbuf tags because pf itself is =
already using mbuf tags. Why can't you use a PF tag like the ones =
defined in pf_mtag.h? Have you measured the performance impact?
--
Rui Paulo
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6302F517-EA46-47C0-85F1-625383DA9EBF>