svn commit: r243414 - user/andre/tcp_workqueue/sys/net

[Andre Oppermann]

On 23.11.2012 12:40, Ermal Luçi wrote:
> On Fri, Nov 23, 2012 at 8:51 AM, Andre Oppermann <andre at freebsd.org <mailto:andre at 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 at freebsd.org
>         <mailto:andre at freebsd.org> <mailto:andre at freebsd.org <mailto:andre at 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