[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20160226.122657.1472671063151796590.davem@davemloft.net>
Date: Fri, 26 Feb 2016 12:26:57 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: pablo@...filter.org
Cc: john.fastabend@...il.com, netdev@...r.kernel.org, jiri@...nulli.us,
horms@...ge.net.au
Subject: Re: [PATCH RFC 0/3] intermediate representation for jit and
cls_u32 conversion
From: Pablo Neira Ayuso <pablo@...filter.org>
Date: Fri, 26 Feb 2016 12:47:14 +0100
> The frontend parser should be generic to everyone, it should be
> placed in the core, so everyone will take care of improving it.
Generic unfortunately means information loss and lots of wasted work.
And this is one of John's points I think.
If we have an existing abstraction that fits directly into what the
hardware can do, such as the u32 classifiers, translating this back
and forth into an intermediate representation is going to be at best
wasted work and sometimes missing cases that can be loaded into hardware.
I really see zero value in "generic" intermediate languages for this
kind of stuff.
I don't want to have to translate a set of u32 rules into some other
format if u32 is what lots of hardware can do directly already.
Pablo, you're coming at the from another angle, you're starting from
the perspective of nftables which has this nice abstraction and IR.
But no hardware directly offloads nftables IR. So as an offload
strategy nftables needs this IR to hardware translation layer.
But u32 and others absolutely will not, and we should not force them
to.
Powered by blists - more mailing lists