On Thu, Mar 15, 2018 at 06:00:22PM +0100, Florian Westphal wrote:
> Alexei Starovoitov wrote:
> > The way this IMR defined today looks pretty much like nft and
> > it feels a bit too low level than iptable conversion would need.
>
> It wasn't so much about a specific IMR but to avoid code duplica
Alexei Starovoitov wrote:
> The way this IMR defined today looks pretty much like nft and
> it feels a bit too low level than iptable conversion would need.
It wasn't so much about a specific IMR but to avoid code duplication
between nft and iptables translators.
> I think it would be simpler to
On Tue, Mar 06, 2018 at 06:18:04PM +, Edward Cree wrote:
> On 06/03/18 18:03, Florian Westphal wrote:
> > I don't know. I suspect we should go for naive algorithm only,
> > but I would defer such decision to Alexei/Daniel.
> >
> > f.e. i don't know if using llvm is a good idea or not,
> Yeah,
On 06/03/18 18:03, Florian Westphal wrote:
> I don't know. I suspect we should go for naive algorithm only,
> but I would defer such decision to Alexei/Daniel.
>
> f.e. i don't know if using llvm is a good idea or not,
Yeah, I wondered about that too. I think it's probably not a good idea,
since
Edward Cree wrote:
> On 06/03/18 16:42, Florian Westphal wrote:
> > I would also add 'highlevel' objects that are themselves translated into
> > basic operations. Most obvious example
> > are 'fetch 4 bytes x bytes into transport header'.
> >
> > Frontend should not need to bother with ipv4 detai
On 06/03/18 16:42, Florian Westphal wrote:
> I would also add 'highlevel' objects that are themselves translated into
> basic operations. Most obvious example
> are 'fetch 4 bytes x bytes into transport header'.
>
> Frontend should not need to bother with ipv4 details, such as ip
> options. Inste
Daniel Borkmann wrote:
> On 03/04/2018 08:40 PM, Florian Westphal wrote:
> > Its still in early stage, but I think its good enough as
> > a proof-of-concept.
>
> be the critical part in that it needs to be flexible enough to cover
> both front ends well enough without having to make compromises t
On 03/04/2018 08:40 PM, Florian Westphal wrote:
> These patches, which go on top of the 'bpfilter' RFC patches,
> demonstrate an nftables to ebpf translation (done in userspace).
> In order to not duplicate the ebpf code generation efforts, the rules
>
> iptables -i lo -d 127.0.0.2 -j DROP
> and
>