[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180507.115036.2237866742963204693.davem@davemloft.net>
Date: Mon, 07 May 2018 11:50:36 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: laforge@...monks.org
Cc: ast@...nel.org, daniel@...earbox.net,
torvalds@...ux-foundation.org, gregkh@...uxfoundation.org,
luto@...capital.net, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, kernel-team@...com
Subject: Re: [PATCH v2 net-next 2/4] net: add skeleton of bpfilter kernel
module
From: Harald Welte <laforge@...monks.org>
Date: Mon, 7 May 2018 17:24:35 +0200
> But if the ruleset loads but behaves different than before (because e.g.
> it's executed from a completely different place in the stack), that's
> IMHO an absolute no-go that must be avoided at all cost.
That's not what we are doing nor proposing. I'm sorry if you are
confused on this matter.
The base implementation we strive for will execute the BPF programs
from the existing netfilter hook points.
However, if semantically the effect is equal if we execute the BPF
program from XDP, we will allow that to happen as an optimization.
The BPF exection is where it is in these patches for the purposes of
bootstrapping the bpfilter project and easy testing/benchmarking/hacking.
I hope this clears up your confusion.
If you would like to become involved in hacking on bpfilter to help us
ensure more accurate compatability between existing iptables and what
bpfilter will execute for the same rule sets, we very much look
forward to your contributions and expertiece.
Thank you.
Powered by blists - more mailing lists