From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 16 15:00:51 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 723657B; Sun, 16 Mar 2014 15:00:51 +0000 (UTC) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B08C018E; Sun, 16 Mar 2014 15:00:50 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id x12so3680655wgg.6 for ; Sun, 16 Mar 2014 08:00:48 -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=7WKJEGXmS0ZzZM/Yam05eDelx8Asbi6GaSoCM7pnUuM=; b=KQLnBky/elZPN01H0pdGDYF0fGRs7At2sWKI4uQP3RtOJQWhdpvv9fWWciae6xZ7ay LoUuc72ZJDvzqc0BstWX26XtLK/Wrvwl1IaCSXB0UyZv4Sv4fhLw49imtgdykJYBqaz2 UwelmwD+RSRk76VfC3yHvLHViILB4e3+NYG8ySCM83Jvo0L94NcNVg8i5xE+wo5vQmgV 0oNiQuM+dmfu3hWub07aOuLrHq317FIEd1jxdltdsczVSqLpqXhG8rHOlUPil1EsavV8 eNSqAPdayyHgef7v9O0tO4FzOOTWzQPgWlNne2pJvHhhBBIJ5Qr69cE16RYV3Rd/rA88 s9OA== X-Received: by 10.194.240.7 with SMTP id vw7mr510299wjc.75.1394982048740; Sun, 16 Mar 2014 08:00:48 -0700 (PDT) Received: from [192.168.2.30] ([2.176.141.45]) by mx.google.com with ESMTPSA id ee5sm16007082wib.8.2014.03.16.08.00.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Mar 2014 08:00:47 -0700 (PDT) Message-ID: <5325BC99.2060703@gmail.com> Date: Sun, 16 Mar 2014 19:30:41 +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> In-Reply-To: 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 15:00:51 -0000 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; ... } -- Best regards. Hooman Fazaeli