Date: Fri, 23 Nov 2012 12:40:33 +0100 From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org> To: Andre Oppermann <andre@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: <CAPBZQG3UE0NPyksRApgshBLW_d=AXwJELk-aD8%2B7Rnn2K9N54w@mail.gmail.com> In-Reply-To: <50AF2B0F.7000002@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Nov 23, 2012 at 8:51 AM, Andre Oppermann <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>> 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 This even resolves the issues of implementation of pf(4) route-to/reply-to or whatever other implementation. 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. 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. > -- > Andre > > -- Ermal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPBZQG3UE0NPyksRApgshBLW_d=AXwJELk-aD8%2B7Rnn2K9N54w>