Date: Fri, 23 Nov 2012 15:59:10 +0100 From: Andre Oppermann <andre@freebsd.org> To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r243414 - user/andre/tcp_workqueue/sys/net Message-ID: <50AF8F3E.9050902@freebsd.org> In-Reply-To: <CAPBZQG3UE0NPyksRApgshBLW_d=AXwJELk-aD8%2B7Rnn2K9N54w@mail.gmail.com> References: <201211222043.qAMKh9Zs060179@svn.freebsd.org> <CAPBZQG1kYUNBhX5=P=Ja9rPuT45rizXP6sq%2BZP0fv13mD7nJUw@mail.gmail.com> <50AEA39D.4080704@freebsd.org> <CAPBZQG2O4hdLM6mKGQo75Eo-oDo%2BriG9Q%2BM7TjY2zJVmBnYfLA@mail.gmail.com> <50AEB2CF.3040904@freebsd.org> <20121123064413.GG84121@FreeBSD.org> <50AF2B0F.7000002@freebsd.org> <CAPBZQG3UE0NPyksRApgshBLW_d=AXwJELk-aD8%2B7Rnn2K9N54w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23.11.2012 12:40, Ermal Luçi wrote: > On Fri, Nov 23, 2012 at 8:51 AM, Andre Oppermann <andre@freebsd.org <mailto:andre@freebsd.org>> 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 <andre@freebsd.org > <mailto:andre@freebsd.org> <mailto:andre@freebsd.org <mailto:andre@freebsd.org>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50AF8F3E.9050902>