From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 17:28:48 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90A393AC; Sun, 16 Mar 2014 17:28:48 +0000 (UTC) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id 77B19EE1; Sun, 16 Mar 2014 17:28:48 +0000 (UTC) Received: from [10.0.1.3] (c-24-6-115-18.hsd1.ca.comcast.net [24.6.115.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 61C3939841; Sun, 16 Mar 2014 10:28:47 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: mbuf question From: Rui Paulo In-Reply-To: <5325BC99.2060703@gmail.com> Date: Sun, 16 Mar 2014 10:28:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6302F517-EA46-47C0-85F1-625383DA9EBF@FreeBSD.org> References: <53230214.7010501@gmail.com> <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> <5325BC99.2060703@gmail.com> To: Hooman Fazaeli X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Hackers , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Mar 2014 17:28:48 -0000 On 16 Mar 2014, at 08:00, Hooman Fazaeli = wrote: > On 3/16/2014 9:01 AM, Rui Paulo wrote: >> On 15 Mar 2014, at 16:13, Ian Lepore 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