From owner-svn-src-user@FreeBSD.ORG Fri Nov 23 14:59:19 2012 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C797EC9 for ; Fri, 23 Nov 2012 14:59:19 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id DA5468FC16 for ; Fri, 23 Nov 2012 14:59:18 +0000 (UTC) Received: (qmail 16875 invoked from network); 23 Nov 2012 16:31:38 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Nov 2012 16:31:38 -0000 Message-ID: <50AF8F3E.9050902@freebsd.org> Date: Fri, 23 Nov 2012 15:59:10 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Subject: Re: svn commit: r243414 - user/andre/tcp_workqueue/sys/net References: <201211222043.qAMKh9Zs060179@svn.freebsd.org> <50AEA39D.4080704@freebsd.org> <50AEB2CF.3040904@freebsd.org> <20121123064413.GG84121@FreeBSD.org> <50AF2B0F.7000002@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Gleb Smirnoff , src-committers@freebsd.org, svn-src-user@freebsd.org X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 14:59:19 -0000 On 23.11.2012 12:40, Ermal Luçi wrote: > On Fri, Nov 23, 2012 at 8:51 AM, Andre Oppermann > wrote: > On 23.11.2012 07:44, Gleb Smirnoff wrote: > On Fri, Nov 23, 2012 at 12:18:39AM +0100, Andre Oppermann wrote: > A> > On Thu, Nov 22, 2012 at 11:13 PM, Andre Oppermann >> wrote: > A> > > A> > Hello Andre, > A> > you plan to introduce pfil(9) at layer2 as well? > A> > > A> > We already have that in net/if_ethersubr.c for ethernet at least. > A> > > A> > Hmm have missed the addition of that one. > A> > I would have liked that with that hook all the special cases(bridge/netgraph/carp/... > to go away. > A> > A> Indeed. Lets make it happen. :-) > > It is impossible to convert netgraph to be a pfil, since netgraph isn't > just a function call. It doesn't return processed packet immediately. > > > That's why I added the pfil cookies. You can re-inject a packet after a > particular hook after deferred processing. > > Oh this is on your branch. > I see the usability of it. > What would have been more interesting is to split all function where pfil hook is called in two. > I.e taking into consideration ip_output. > Split the function into two parts at the pfil hook call and pass to the pfil_hook call the next step > as a callback. > 1) ip_output_start() > 2) Call pfil hook(callback ip_output_do()) > 3) pfil consumer does its own processing/looping/or choose a different output path > 4) Default method after pfil return call callback That would be very bad and totally break hook chaining. > This even resolves the issues of implementation of pf(4) route-to/reply-to or whatever other > implementation. That isn't a problem. It's just poorly implemented as is. It should do the same thing as ipfw does and return a correctly tagged mbuf with the new nexthop. ip_output() then handles the rest. > This is similar to how crypto currently does this. > That way you avoid locking and deferring issues and simplify functionality. > > > The carp(4) isn't a layer 2 protocol, but is IP protocol, so I > don't understand how can it be converted to a pfil hook. > > > Obviously not everything can be a layer 2 pfil hook. Where it can, we > should at least investigate it to limit the number of special cases in > the path. > > Surely carp(4) is a hybrid approach. Though it hooks into at least the ethernet layer to do some > rewriting of packet information. > If it can be integrated into the pfil hook why not go that route. Yes, it can be tried. > While the better solution would be support for stacked interfaces, incremental is better in general > for this part of system. > > A potential issue is the cpu pinning of the pfil rmlock. We'll have to > see whether this is an immediate problem, and if yes, what we can do about > it. > > Also it would be nice to have some locality information on the pfil per interface to avoid > 'overhead' of going into the pfil chain call. > This is an optimization which would remove the special fields in the ifnet structure and allow to > have the pfil hook per interface. > Also it avoids sending every packet to a hook consumer that is interested on packets from only a > specific source. > > So the subsystems can implement their own optimizations and be self contained. They can already do that. -- Andre