From owner-svn-src-user@FreeBSD.ORG Fri Nov 23 11:40:35 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 4DF65400; Fri, 23 Nov 2012 11:40:35 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id B30B08FC08; Fri, 23 Nov 2012 11:40:34 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so8022859qcs.13 for ; Fri, 23 Nov 2012 03:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7/y5aWn9gxuOUGrf+Wa/wFqgTTPeMM83DoOuevaAePE=; b=rl+8bNkrdvHrDuj1Hp9lmo5ciplwKbxcQhpuGVnhYlfWsSf0Z98nC5VIiae4Qst+yB W59hjdulg5dREWO9T8Bd7JqVXtBKhBcVIG6mdMcmR4ioNXMwi2IJTuVQmTpq14JO9nM9 0b+x/+jZW7lyNCemVxwZq8JhfBH+BOXI0DCIjVHKKnaS/9gu2Ff8twYkrD/KS89dRR2j Qs58vJvZJH0Pr1h98V9h3R+zIMPDeMADkVxKgBI3mj/ANltjsB3YcSVBdsMeZp3G3iUV y5Hf8GxA5+LyTYjs5I+3MNjbwQhee5ASGKNsNeRn6kEU5lCuwMM0y7V3bqMSKuic0wK4 JIKQ== MIME-Version: 1.0 Received: by 10.224.53.5 with SMTP id k5mr4021061qag.20.1353670834012; Fri, 23 Nov 2012 03:40:34 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.49.121.163 with HTTP; Fri, 23 Nov 2012 03:40:33 -0800 (PST) In-Reply-To: <50AF2B0F.7000002@freebsd.org> References: <201211222043.qAMKh9Zs060179@svn.freebsd.org> <50AEA39D.4080704@freebsd.org> <50AEB2CF.3040904@freebsd.org> <20121123064413.GG84121@FreeBSD.org> <50AF2B0F.7000002@freebsd.org> Date: Fri, 23 Nov 2012 12:40:33 +0100 X-Google-Sender-Auth: aBoBO2ut9ZZVzzC2Mz_yF37UpJQ Message-ID: Subject: Re: svn commit: r243414 - user/andre/tcp_workqueue/sys/net From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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 11:40:35 -0000 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 > 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