From owner-freebsd-net@FreeBSD.ORG Mon Apr 20 19:53:27 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1F592AF; Mon, 20 Apr 2015 19:53:27 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 932D09A3; Mon, 20 Apr 2015 19:53:27 +0000 (UTC) Received: by pacyx8 with SMTP id yx8so216493383pac.1; Mon, 20 Apr 2015 12:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=PwwbBcCo08VAdfbjjC5+9Lqry9EH9Vb3kiioPIrKOd8=; b=wpaWpPXpHiApQrB/xDCW9ZNC/uYUbP7H2DwyeQo2dU6kKrVDhaXx5JXZVE7puds7av BV+xe/bLndMMT2p1jontDFJyTNTaWPy1lhNH0ZuqxG/eE7mJYFQENaj8fDTTMEPwqk0v 1uHCIhVrbDYb+2JeiKCrPSnX4h6GuNymEiN1FqUx4mK2/NOKoDL94vjHp8jehF2vxvll 7Ab+W0YYWgsIVKNawqBZ8Dg2leD2zhcRPBV6/HSmfbaaLFfubFDjr/uTZffSeWfs+P+S uZ7iikvtob2eXRPVg95PlLlvLZjGzT5nrO5A6hpKxudgJyQQirrAiu66JJFW3ZH09QQ+ JoHg== X-Received: by 10.70.131.193 with SMTP id oo1mr15862318pdb.63.1429559607226; Mon, 20 Apr 2015 12:53:27 -0700 (PDT) Received: from muskytusk ([104.236.250.12]) by mx.google.com with ESMTPSA id nn6sm19000871pdb.79.2015.04.20.12.53.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 12:53:25 -0700 (PDT) Sender: Mark Johnston Date: Mon, 20 Apr 2015 19:52:33 +0000 From: Mark Johnston To: Gleb Smirnoff Cc: freebsd-net@FreeBSD.org Subject: Re: moving struct bpf_if to bpf.c Message-ID: <20150420195233.GA71166@muskytusk> References: <20150418210855.GA50409@charmander.west.isilon.com> <20150420192618.GY883@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420192618.GY883@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 19:53:27 -0000 On Mon, Apr 20, 2015 at 10:26:18PM +0300, Gleb Smirnoff wrote: > On Sat, Apr 18, 2015 at 02:08:56PM -0700, Mark Johnston wrote: > M> At the moment, bpf.h defines struct bpf_if differently depending on > M> whether BPF_INTERNAL is #defined. This causes problems with CTF, as it > M> results in a sort of bifurcation within the type graph: CTF sees two > M> different struct bpf_ifs, and so every struct/union containing a struct > M> bpf_if is duplicated, and so on. CTF currently imposes a limit of 2^15 > M> distinct types within a container, and several people have been running > M> into this limit. The type duplication exacerbates this problem. > M> > M> The change here fixes the issue by moving the definition of > M> struct bpf_if to bpf.c, and making its externally-used fields > M> available via struct bpf_if_ext: https://reviews.freebsd.org/D2319 > M> > M> In particular, the ext fields are at the same offsets within struct > M> bpf_if as before, so this change should have no functional impact. > M> Moreover, it reduces the number of types from 20879 to 15725 with my > M> (stripped-down) kernel config on amd64. Would anyone be willing to > M> review the proposed change? I've also placed the raw diff here: > M> https://people.freebsd.org/~markj/patches/bpf_entrails.diff > > What actual software needs to look at struct bpf_if? I wonder if > we can fix the software and hide the struct bpf_if into kernel > entirely. bpf_peers_present() is defined in bpf.h so that it can be inlined, and it needs access to the bif_dlist field of struct bpf_if. As far as I can see, this is the only reason for exposing part of struct bpf_if.