From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 17:49:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FB7D9BA; Sun, 16 Mar 2014 17:49:17 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE30BDB; Sun, 16 Mar 2014 17:49:16 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id t61so3810586wes.31 for ; Sun, 16 Mar 2014 10:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wFO6T7PQZkqbksCSfj4sQlCPK+Qa2lg/JaNbIE9qqmY=; b=hxfza0mmrO2Xxru4N4ZkgBzESmbA0j4+rGhWGp/VZyWI1rP5fYww5anxowNfkfDR8B qYCtXCds/TeTs2YJGJc46rFKSU4tciNXHiJjL0s1s+pV3DOKJ2/4WP7DbzSUGHWokMrY NnAF0VIJ6NbrtZ2pZv07HGGgFgKDU2QdOKc+MzGOQ+OC2cXPBrMYIL8JOqgmygz47EjG qc4umpfnpQzMqm900cbDBDql+Vt5AzDJVLV2cWXTMbEgAVtjHZW6GzFIWvN2d7QDvB5w o7YUKlGcwHgEMkOhVv/MXv+e+aG51EA8F2ok0qxqKGX0r3+vi4nPm9jz704h2BTJPSUm SkOA== X-Received: by 10.194.90.196 with SMTP id by4mr2152684wjb.45.1394992155028; Sun, 16 Mar 2014 10:49:15 -0700 (PDT) Received: from [192.168.2.30] ([2.176.141.45]) by mx.google.com with ESMTPSA id ju6sm31237469wjc.1.2014.03.16.10.49.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 10:49:14 -0700 (PDT) Message-ID: <5325E416.2040906@gmail.com> Date: Sun, 16 Mar 2014 22:19:10 +0430 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Rui Paulo Subject: Re: mbuf question 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> <6302F517-EA46-47C0-85F1-625383DA9EBF@FreeBSD.org> In-Reply-To: <6302F517-EA46-47C0-85F1-625383DA9EBF@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:49:17 -0000 On 3/16/2014 9:58 PM, Rui Paulo wrote: > 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. >>> >>> -- >>> 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? >> Something like: >> >> 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 I havereallyno problems with tags. After all, they have been created for such use casesas mine from the first place. I was just thinking about making things faster and came with the idea of using that unused space in mbufs. When you do something per-packet, It is good to make it as cheap as possible. And no. I have not yet measured the performance of tags vs. no-tags. -- Best regards. Hooman Fazaeli