Re: [PATCH RFC 3/3] net: convert tc_u32 to use the intermediate representation

[David Miller]

From: Pablo Neira Ayuso 
Date: Fri, 26 Feb 2016 17:02:22 +0100

> Just because you want to early microoptimize this thing by saving a
> little of extra code that runs from the control plane path.

I don't think that's what he is doing at all.

We have classes of classifier etc. offloads that need IR, and we have
those that don't.

There is nothing wrong with making this distinction and making our
design based upon that observation.

Re: [PATCH RFC 3/3] net: convert tc_u32 to use the intermediate representation

[David Miller]

From: John Fastabend 
Date: Fri, 26 Feb 2016 06:53:11 -0800

> sure but its easier for me to just consume u32 at the moment. And I
> am concerned about performance overhead with this IR. I'm going to need
> to have a performant solution eventually and I don't like converting
> into one IR only to go into another.

+1

Re: [PATCH RFC 3/3] net: convert tc_u32 to use the intermediate representation

[John Fastabend]

On 16-02-26 08:02 AM, Pablo Neira Ayuso wrote:
> On Fri, Feb 26, 2016 at 06:53:11AM -0800, John Fastabend wrote:
>> On 16-02-26 06:24 AM, Pablo Neira Ayuso wrote:
>>> On Thu, Feb 25, 2016 at 12:37:38PM -0800, John Fastabend wrote:
 On 16-02-25 09:37 AM, Pablo Neira Ayuso wrote:
> This patch moves the u32 parser from the ixgbe that John has made to the
> core u32. This parser has been adapted to build the intermediate
> representation.
>
> To store the parsing information, this patch introduces a parse table
> object, one per device, so we don't need to store the parsing states in
> the adapter, which is the major dependency with previous patches.
>
> Since u32 allows rules connected via links, the u32 parser tracks this
> links and then generates the intermediate representation that is passed
> to the ixgbe driver.

 It also supports hash tables and loops.
>>>
>>> Then, it is a matter of extending the tc-u32 parser and the IR to
>>> support whatever you need.
>>
>> sure but its easier for me to just consume u32 at the moment. And I
>> am concerned about performance overhead with this IR. I'm going to need
>> to have a performant solution eventually and I don't like converting
>> into one IR only to go into another.
> 
> Just because you want to early microoptimize this thing by saving a
> little of extra code that runs from the control plane path.

But the entire parser + hardware setup is only 149 lines of code plus
a header file. And 45 lines of it hardware specific code and 15 lines
of it are comments. So the entire piece that takes u32 to hardware is
less than 100 lines of code. I'm going to take that block of code and
share it across all my drivers and just write models for each one. After
I make some firmware changes I'll just read the model in from the
firmware and I wont even need that piece. If/when other driver writers
want to use that core loop I created I'll lift it into some helper
routine anyone can call.

I'll do the flower classifier with a static map from keys to u32 if
folks think that is valuable. And that will only be a handful of lines
of code.

So I guess your right I'm not arguing so much against some IR if its
warranted just that the IR proposed here with AST and all seems
unnecessary for offloading front-ends that are so simple when I have
one more or less already. It seems to push the notion of an AST from
nft onto 'tc' which IMO has no need for it.

> 
> New drivers will only have to implement the jit translation code based
> on the intermediate representation. With some extra work, I think it
> should be possible to generalize the existing tc specific ndo action so
> it can be used by other frontends.
>
> I tried to stick to John's original u32 frontend parser as much as
> possible, adapting it to build the intermediate representation.
>
> After this change, we don't expose the tc action structure layout and
> other similar frontend details to the backend anymore to the backend
> anymore. I think this is good since changes in the frontend should not
> need to be propagated to the 1..n drivers supporting u32 offloads. In
> that sense, this helps to keep the frontend software representation
> separated from low-level backend driver details.
>
> After this patch, it should be possible to put the tc_cls_u32_knode
> structure into diet since we only need the handle (as unique id) and the
> ast tree.
>

 On ixgbe this is true but going forward I can support hash functions
 so you need the divisor, prio, and handle minimally. I'm not sure how
 to do hash tables for example in this IR yet. Might be there I'm still
 trying to grok the IR details.
>>>
>>> We just need a description with the list elements that you want to
>>> place in the hashtable.
>>>
>>> The matching can be expressed in ast by adding a list of elements that
>>> are part of the hashtable:
>>>
>>>  relational
>>> / \
>>>/   \
>>>   / \
>>>payload  list of elements
>>>   (offset, base, len)   |
>>> \
>>>  --> e1 --> e2 --> ... --> en
>>
>> Sure it can be done but taking the u32 directly and flower directly is
>> so easy I don't see the need for the complexity.
> 
> You prefer to push the complexity on the driver side. Then, the
> complexity will spread all over the place.

As I noted above the complexity is small.

> 
> I couldn't send any more incremental changes to update previous work
> since the u32 parser and the internal representation were put together,
> that why this patch is slightly large.
>
> Signed-off-by: Pablo Neira Ayuso 
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe.h   |   4 -
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 216 

Re: [PATCH RFC 3/3] net: convert tc_u32 to use the intermediate representation

[Pablo Neira Ayuso]

On Fri, Feb 26, 2016 at 06:53:11AM -0800, John Fastabend wrote:
> On 16-02-26 06:24 AM, Pablo Neira Ayuso wrote:
> > On Thu, Feb 25, 2016 at 12:37:38PM -0800, John Fastabend wrote:
> >> On 16-02-25 09:37 AM, Pablo Neira Ayuso wrote:
> >>> This patch moves the u32 parser from the ixgbe that John has made to the
> >>> core u32. This parser has been adapted to build the intermediate
> >>> representation.
> >>>
> >>> To store the parsing information, this patch introduces a parse table
> >>> object, one per device, so we don't need to store the parsing states in
> >>> the adapter, which is the major dependency with previous patches.
> >>>
> >>> Since u32 allows rules connected via links, the u32 parser tracks this
> >>> links and then generates the intermediate representation that is passed
> >>> to the ixgbe driver.
> >>
> >> It also supports hash tables and loops.
> > 
> > Then, it is a matter of extending the tc-u32 parser and the IR to
> > support whatever you need.
> 
> sure but its easier for me to just consume u32 at the moment. And I
> am concerned about performance overhead with this IR. I'm going to need
> to have a performant solution eventually and I don't like converting
> into one IR only to go into another.

Just because you want to early microoptimize this thing by saving a
little of extra code that runs from the control plane path.

> >>> New drivers will only have to implement the jit translation code based
> >>> on the intermediate representation. With some extra work, I think it
> >>> should be possible to generalize the existing tc specific ndo action so
> >>> it can be used by other frontends.
> >>>
> >>> I tried to stick to John's original u32 frontend parser as much as
> >>> possible, adapting it to build the intermediate representation.
> >>>
> >>> After this change, we don't expose the tc action structure layout and
> >>> other similar frontend details to the backend anymore to the backend
> >>> anymore. I think this is good since changes in the frontend should not
> >>> need to be propagated to the 1..n drivers supporting u32 offloads. In
> >>> that sense, this helps to keep the frontend software representation
> >>> separated from low-level backend driver details.
> >>>
> >>> After this patch, it should be possible to put the tc_cls_u32_knode
> >>> structure into diet since we only need the handle (as unique id) and the
> >>> ast tree.
> >>>
> >>
> >> On ixgbe this is true but going forward I can support hash functions
> >> so you need the divisor, prio, and handle minimally. I'm not sure how
> >> to do hash tables for example in this IR yet. Might be there I'm still
> >> trying to grok the IR details.
> > 
> > We just need a description with the list elements that you want to
> > place in the hashtable.
> > 
> > The matching can be expressed in ast by adding a list of elements that
> > are part of the hashtable:
> > 
> >  relational
> > / \
> >/   \
> >   / \
> >payload  list of elements
> >   (offset, base, len)   |
> > \
> >  --> e1 --> e2 --> ... --> en
> 
> Sure it can be done but taking the u32 directly and flower directly is
> so easy I don't see the need for the complexity.

You prefer to push the complexity on the driver side. Then, the
complexity will spread all over the place.

> >>> I couldn't send any more incremental changes to update previous work
> >>> since the u32 parser and the internal representation were put together,
> >>> that why this patch is slightly large.
> >>>
> >>> Signed-off-by: Pablo Neira Ayuso 
> >>> ---
> >>>  drivers/net/ethernet/intel/ixgbe/ixgbe.h   |   4 -
> >>>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 216 
> >>>  drivers/net/ethernet/intel/ixgbe/ixgbe_model.h | 112 
> >>>  include/net/pkt_cls.h  |   3 +
> >>>  net/sched/cls_u32.c| 344 
> >>> +
> >>
> >> Feels like a lot of code to me when the original direct u32 to hw
> >> was reasonably small and the flower implementation is small as well.
> > 
> > This is your tc-u32 parser plus simple boiler plate code to build the
> > IR that will be common to everyone. Without this, other drivers will
> > have to track u32 links and so on.
> 
> But you lost the model piece which allows me to easily change the
> hardware underneath the driver.

You want to hide hardware capabilities behind that model.

> > Other than that, we'll end up with 1..N different u32 parsers in the
> > backend.
> 
> well if folks like the way I wrote the u32 parser we could standardize
> the model and header for u32 and give them helper functions.

I see, so now you agree with me that the u32 parser should be moved to
the core, that's good.

> But by writing your own model you can optimize it.

I see, but you mean you keep using this ugly IR 

Re: [PATCH RFC 3/3] net: convert tc_u32 to use the intermediate representation

[John Fastabend]

On 16-02-26 06:24 AM, Pablo Neira Ayuso wrote:
> On Thu, Feb 25, 2016 at 12:37:38PM -0800, John Fastabend wrote:
>> On 16-02-25 09:37 AM, Pablo Neira Ayuso wrote:
>>> This patch moves the u32 parser from the ixgbe that John has made to the
>>> core u32. This parser has been adapted to build the intermediate
>>> representation.
>>>
>>> To store the parsing information, this patch introduces a parse table
>>> object, one per device, so we don't need to store the parsing states in
>>> the adapter, which is the major dependency with previous patches.
>>>
>>> Since u32 allows rules connected via links, the u32 parser tracks this
>>> links and then generates the intermediate representation that is passed
>>> to the ixgbe driver.
>>
>> It also supports hash tables and loops.
> 
> Then, it is a matter of extending the tc-u32 parser and the IR to
> support whatever you need.

sure but its easier for me to just consume u32 at the moment. And I
am concerned about performance overhead with this IR. I'm going to need
to have a performant solution eventually and I don't like converting
into one IR only to go into another.

> 
>>> New drivers will only have to implement the jit translation code based
>>> on the intermediate representation. With some extra work, I think it
>>> should be possible to generalize the existing tc specific ndo action so
>>> it can be used by other frontends.
>>>
>>> I tried to stick to John's original u32 frontend parser as much as
>>> possible, adapting it to build the intermediate representation.
>>>
>>> After this change, we don't expose the tc action structure layout and
>>> other similar frontend details to the backend anymore to the backend
>>> anymore. I think this is good since changes in the frontend should not
>>> need to be propagated to the 1..n drivers supporting u32 offloads. In
>>> that sense, this helps to keep the frontend software representation
>>> separated from low-level backend driver details.
>>>
>>> After this patch, it should be possible to put the tc_cls_u32_knode
>>> structure into diet since we only need the handle (as unique id) and the
>>> ast tree.
>>>
>>
>> On ixgbe this is true but going forward I can support hash functions
>> so you need the divisor, prio, and handle minimally. I'm not sure how
>> to do hash tables for example in this IR yet. Might be there I'm still
>> trying to grok the IR details.
> 
> We just need a description with the list elements that you want to
> place in the hashtable.
> 
> The matching can be expressed in ast by adding a list of elements that
> are part of the hashtable:
> 
>  relational
> / \
>/   \
>   / \
>payload  list of elements
>   (offset, base, len)   |
> \
>  --> e1 --> e2 --> ... --> en

Sure it can be done but taking the u32 directly and flower directly is
so easy I don't see the need for the complexity.

> 
>>> I couldn't send any more incremental changes to update previous work
>>> since the u32 parser and the internal representation were put together,
>>> that why this patch is slightly large.
>>>
>>> Signed-off-by: Pablo Neira Ayuso 
>>> ---
>>>  drivers/net/ethernet/intel/ixgbe/ixgbe.h   |   4 -
>>>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 216 
>>>  drivers/net/ethernet/intel/ixgbe/ixgbe_model.h | 112 
>>>  include/net/pkt_cls.h  |   3 +
>>>  net/sched/cls_u32.c| 344 
>>> +
>>
>> Feels like a lot of code to me when the original direct u32 to hw
>> was reasonably small and the flower implementation is small as well.
> 
> This is your tc-u32 parser plus simple boiler plate code to build the
> IR that will be common to everyone. Without this, other drivers will
> have to track u32 links and so on.
> 

But you lost the model piece which allows me to easily change the
hardware underneath the driver.

> Other than that, we'll end up with 1..N different u32 parsers in the
> backend.
> 

well if folks like the way I wrote the u32 parser we could standardize
the model and header for u32 and give them helper functions. But by
writing your own model you can optimize it. Anyways at the moment it
looks like we will only have two the Intel and mlx ones I haven't
seen anyone else working on this yet.

>> [...]
>>
>>>  
>>> +static int ixgbe_tcp_jit(struct net_ir_jit_ctx *ctx,
>>> +const struct net_ir_expr *expr,
>>> +void *data)
>>> +{
>>> +   struct ixgbe_filter *f = (struct ixgbe_filter *)data;
>>> +   struct net_ir_expr *right = expr->relational.right;
>>> +   struct net_ir_expr *payload;
>>> +   u32 mask = 0x;
>>> +
>>> +   if (expr->relational.left->type == NET_IR_EXPR_BINOP) {
>>> +   payload = expr->relational.left->binop.left;
>>> +   mask = 

Re: [PATCH RFC 3/3] net: convert tc_u32 to use the intermediate representation

[Pablo Neira Ayuso]

On Thu, Feb 25, 2016 at 12:37:38PM -0800, John Fastabend wrote:
> On 16-02-25 09:37 AM, Pablo Neira Ayuso wrote:
> > This patch moves the u32 parser from the ixgbe that John has made to the
> > core u32. This parser has been adapted to build the intermediate
> > representation.
> > 
> > To store the parsing information, this patch introduces a parse table
> > object, one per device, so we don't need to store the parsing states in
> > the adapter, which is the major dependency with previous patches.
> > 
> > Since u32 allows rules connected via links, the u32 parser tracks this
> > links and then generates the intermediate representation that is passed
> > to the ixgbe driver.
> 
> It also supports hash tables and loops.

Then, it is a matter of extending the tc-u32 parser and the IR to
support whatever you need.

> > New drivers will only have to implement the jit translation code based
> > on the intermediate representation. With some extra work, I think it
> > should be possible to generalize the existing tc specific ndo action so
> > it can be used by other frontends.
> > 
> > I tried to stick to John's original u32 frontend parser as much as
> > possible, adapting it to build the intermediate representation.
> > 
> > After this change, we don't expose the tc action structure layout and
> > other similar frontend details to the backend anymore to the backend
> > anymore. I think this is good since changes in the frontend should not
> > need to be propagated to the 1..n drivers supporting u32 offloads. In
> > that sense, this helps to keep the frontend software representation
> > separated from low-level backend driver details.
> > 
> > After this patch, it should be possible to put the tc_cls_u32_knode
> > structure into diet since we only need the handle (as unique id) and the
> > ast tree.
> > 
> 
> On ixgbe this is true but going forward I can support hash functions
> so you need the divisor, prio, and handle minimally. I'm not sure how
> to do hash tables for example in this IR yet. Might be there I'm still
> trying to grok the IR details.

We just need a description with the list elements that you want to
place in the hashtable.

The matching can be expressed in ast by adding a list of elements that
are part of the hashtable:

 relational
/ \
   /   \
  / \
   payload  list of elements
  (offset, base, len)   |
\
 --> e1 --> e2 --> ... --> en

> > I couldn't send any more incremental changes to update previous work
> > since the u32 parser and the internal representation were put together,
> > that why this patch is slightly large.
> > 
> > Signed-off-by: Pablo Neira Ayuso 
> > ---
> >  drivers/net/ethernet/intel/ixgbe/ixgbe.h   |   4 -
> >  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 216 
> >  drivers/net/ethernet/intel/ixgbe/ixgbe_model.h | 112 
> >  include/net/pkt_cls.h  |   3 +
> >  net/sched/cls_u32.c| 344 
> > +
> 
> Feels like a lot of code to me when the original direct u32 to hw
> was reasonably small and the flower implementation is small as well.

This is your tc-u32 parser plus simple boiler plate code to build the
IR that will be common to everyone. Without this, other drivers will
have to track u32 links and so on.

Other than that, we'll end up with 1..N different u32 parsers in the
backend.

> [...]
> 
> >  
> > +static int ixgbe_tcp_jit(struct net_ir_jit_ctx *ctx,
> > +const struct net_ir_expr *expr,
> > +void *data)
> > +{
> > +   struct ixgbe_filter *f = (struct ixgbe_filter *)data;
> > +   struct net_ir_expr *right = expr->relational.right;
> > +   struct net_ir_expr *payload;
> > +   u32 mask = 0x;
> > +
> > +   if (expr->relational.left->type == NET_IR_EXPR_BINOP) {
> > +   payload = expr->relational.left->binop.left;
> > +   mask = expr->relational.left->binop.right->value.data;
> > +   } else {
> > +   payload = expr->relational.left;
> > +   }
> > +
> > +   switch (payload->payload.offset) {
> 
> I don't like this because it hardcodes the offset pieces into the
> driver. The reason I used a model.h header file with its structures
> in ixgbe is the next step is to expose the parser so the model can be
> updated. So that when the hardware parser changes the data structure
> can be changed via firmware call. The style of coding here wont work
> for that so we still need the model.h file and for loop.

Model update via firmware?

I think it's been already several conference rounds insisting on the
fact that we don't want infrastructure that allows to insert binary
blobs/sdks.

I don't think this is the way to go.

> [...]
> 
> >  static int ixgbe_configure_clsu32(struct ixgbe_adapter *adapter,
> >   __be16 

Re: [PATCH RFC 3/3] net: convert tc_u32 to use the intermediate representation

[John Fastabend]

On 16-02-25 09:37 AM, Pablo Neira Ayuso wrote:
> This patch moves the u32 parser from the ixgbe that John has made to the
> core u32. This parser has been adapted to build the intermediate
> representation.
> 
> To store the parsing information, this patch introduces a parse table
> object, one per device, so we don't need to store the parsing states in
> the adapter, which is the major dependency with previous patches.
> 
> Since u32 allows rules connected via links, the u32 parser tracks this
> links and then generates the intermediate representation that is passed
> to the ixgbe driver.

It also supports hash tables and loops.

> 
> New drivers will only have to implement the jit translation code based
> on the intermediate representation. With some extra work, I think it
> should be possible to generalize the existing tc specific ndo action so
> it can be used by other frontends.
> 
> I tried to stick to John's original u32 frontend parser as much as
> possible, adapting it to build the intermediate representation.
> 
> After this change, we don't expose the tc action structure layout and
> other similar frontend details to the backend anymore to the backend
> anymore. I think this is good since changes in the frontend should not
> need to be propagated to the 1..n drivers supporting u32 offloads. In
> that sense, this helps to keep the frontend software representation
> separated from low-level backend driver details.
> 
> After this patch, it should be possible to put the tc_cls_u32_knode
> structure into diet since we only need the handle (as unique id) and the
> ast tree.
> 

On ixgbe this is true but going forward I can support hash functions
so you need the divisor, prio, and handle minimally. I'm not sure how
to do hash tables for example in this IR yet. Might be there I'm still
trying to grok the IR details.

> I couldn't send any more incremental changes to update previous work
> since the u32 parser and the internal representation were put together,
> that why this patch is slightly large.
> 
> Signed-off-by: Pablo Neira Ayuso 
> ---
>  drivers/net/ethernet/intel/ixgbe/ixgbe.h   |   4 -
>  drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 216 
>  drivers/net/ethernet/intel/ixgbe/ixgbe_model.h | 112 
>  include/net/pkt_cls.h  |   3 +
>  net/sched/cls_u32.c| 344 
> +

Feels like a lot of code to me when the original direct u32 to hw
was reasonably small and the flower implementation is small as well.

[...]

>  
> +static int ixgbe_tcp_jit(struct net_ir_jit_ctx *ctx,
> +  const struct net_ir_expr *expr,
> +  void *data)
> +{
> + struct ixgbe_filter *f = (struct ixgbe_filter *)data;
> + struct net_ir_expr *right = expr->relational.right;
> + struct net_ir_expr *payload;
> + u32 mask = 0x;
> +
> + if (expr->relational.left->type == NET_IR_EXPR_BINOP) {
> + payload = expr->relational.left->binop.left;
> + mask = expr->relational.left->binop.right->value.data;
> + } else {
> + payload = expr->relational.left;
> + }
> +
> + switch (payload->payload.offset) {

I don't like this because it hardcodes the offset pieces into the
driver. The reason I used a model.h header file with its structures
in ixgbe is the next step is to expose the parser so the model can be
updated. So that when the hardware parser changes the data structure
can be changed via firmware call. The style of coding here wont work
for that so we still need the model.h file and for loop.

> + case offsetof(struct tcphdr, source):
> + f->input->filter.formatted.src_port = right->value.data & 
> 0x;
> + f->mask.formatted.src_port = mask & 0x;
> + break;
> + case offsetof(struct tcphdr, dest):
> + f->input->filter.formatted.dst_port = right->value.data & 
> 0x;
> + f->mask.formatted.dst_port = mask & 0x;
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> + return 0;
> +}
> +
> +static struct net_ir_proto_desc ixgbe_tcp_desc = {
> + .base   = NET_IR_PAYLOAD_TRANSPORT_HDR,
> + .protonum   = IPPROTO_TCP,

hmm I'm having trouble tracking down how this is used but the point of
a lot of ongoing work is to not be dependent on any specific protocol
values. The IPPROTO_TCP here looks suspicious why do we need this? It
seems to imply I would need to define a IPPROTO_FOO if I wanted to add
a new protocol.

> + .jit= ixgbe_tcp_jit,
> +};
> +
> +static int ixgbe_ipv4_jit(struct net_ir_jit_ctx *ctx,
> +   const struct net_ir_expr *expr,
> +   void *data)
> +{
> + struct ixgbe_filter *f = (struct ixgbe_filter *)data;
> + struct net_ir_expr *right = expr->relational.right;
> + struct net_ir_expr *payload;
> +  

[PATCH RFC 3/3] net: convert tc_u32 to use the intermediate representation

[Pablo Neira Ayuso]

This patch moves the u32 parser from the ixgbe that John has made to the
core u32. This parser has been adapted to build the intermediate
representation.

To store the parsing information, this patch introduces a parse table
object, one per device, so we don't need to store the parsing states in
the adapter, which is the major dependency with previous patches.

Since u32 allows rules connected via links, the u32 parser tracks this
links and then generates the intermediate representation that is passed
to the ixgbe driver.

New drivers will only have to implement the jit translation code based
on the intermediate representation. With some extra work, I think it
should be possible to generalize the existing tc specific ndo action so
it can be used by other frontends.

I tried to stick to John's original u32 frontend parser as much as
possible, adapting it to build the intermediate representation.

After this change, we don't expose the tc action structure layout and
other similar frontend details to the backend anymore to the backend
anymore. I think this is good since changes in the frontend should not
need to be propagated to the 1..n drivers supporting u32 offloads. In
that sense, this helps to keep the frontend software representation
separated from low-level backend driver details.

After this patch, it should be possible to put the tc_cls_u32_knode
structure into diet since we only need the handle (as unique id) and the
ast tree.

I couldn't send any more incremental changes to update previous work
since the u32 parser and the internal representation were put together,
that why this patch is slightly large.

Signed-off-by: Pablo Neira Ayuso 
---
 drivers/net/ethernet/intel/ixgbe/ixgbe.h   |   4 -
 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c  | 216 
 drivers/net/ethernet/intel/ixgbe/ixgbe_model.h | 112 
 include/net/pkt_cls.h  |   3 +
 net/sched/cls_u32.c| 344 +
 5 files changed, 454 insertions(+), 225 deletions(-)
 delete mode 100644 drivers/net/ethernet/intel/ixgbe/ixgbe_model.h

diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h 
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 84fa28c..09c2d9b 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -796,10 +796,6 @@ struct ixgbe_adapter {
u8 default_up;
unsigned long fwd_bitmask; /* Bitmask indicating in use pools */
 
-#define IXGBE_MAX_LINK_HANDLE 10
-   struct ixgbe_mat_field *jump_tables[IXGBE_MAX_LINK_HANDLE];
-   unsigned long tables;
-
 /* maximum number of RETA entries among all devices supported by ixgbe
  * driver: currently it's x550 device in non-SRIOV mode
  */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c 
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 252e9ff..416be60 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -67,7 +67,6 @@
 #include "ixgbe_common.h"
 #include "ixgbe_dcb_82599.h"
 #include "ixgbe_sriov.h"
-#include "ixgbe_model.h"
 
 char ixgbe_driver_name[] = "ixgbe";
 static const char ixgbe_driver_string[] =
@@ -5548,9 +5547,6 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter)
 #endif /* CONFIG_IXGBE_DCB */
 #endif /* IXGBE_FCOE */
 
-   /* initialize static ixgbe jump table entries */
-   adapter->jump_tables[0] = ixgbe_ipv4_fields;
-
adapter->mac_table = kzalloc(sizeof(struct ixgbe_mac_addr) *
 hw->mac.num_rar_entries,
 GFP_ATOMIC);
@@ -8221,20 +8217,12 @@ static int ixgbe_configure_clsu32_add_hnode(struct 
ixgbe_adapter *adapter,
__be16 protocol,
struct tc_cls_u32_offload *cls)
 {
-   /* This ixgbe devices do not support hash tables at the moment
-* so abort when given hash tables.
-*/
-   if (cls->hnode.divisor > 0)
-   return -EINVAL;
-
-   set_bit(TC_U32_USERHTID(cls->hnode.handle), >tables);
return 0;
 }
 
 static int ixgbe_configure_clsu32_del_hnode(struct ixgbe_adapter *adapter,
struct tc_cls_u32_offload *cls)
 {
-   clear_bit(TC_U32_USERHTID(cls->hnode.handle), >tables);
return 0;
 }
 
@@ -8244,111 +8232,134 @@ struct ixgbe_filter {
u8 queue;
 };
 
+static int ixgbe_tcp_jit(struct net_ir_jit_ctx *ctx,
+const struct net_ir_expr *expr,
+void *data)
+{
+   struct ixgbe_filter *f = (struct ixgbe_filter *)data;
+   struct net_ir_expr *right = expr->relational.right;
+   struct net_ir_expr *payload;
+   u32 mask = 0x;
+
+   if (expr->relational.left->type == NET_IR_EXPR_BINOP) {
+   payload = expr->relational.left->binop.left;
+   mask =