net: initial flow API support for headers and tables

In order to manage hardware flow tables managing agents must be
able learn the hardware capabilities and resource contraints.

Because hardware can have very different capabilities and resource
support depending on the paticular device and even skew of the
device it does not seem possible to write reasonable user space
applications without this.

To support this, the following patch exposes a set of netlink
attributes and driver ndo operations which can be used to get
the hardwares capabilities. For example consider a traditional
NIC device with support for dropping packets using a 5-tuple
match compared with a high-end switch device.

The patch can be broken into three components a 'Headers'
section a 'Tables' component and driver callbacks.

The 'Headers' components is used to expose what headers and
fields can be matched in a packet. A very basic header spec
to include ethernet, and 802.1q  may look like the following,

  header_type ethernet {
	fields {
		src_mac : 6 byte
		dst_mac : 6 byte
		ethtype : 2 byte
	}
  }

  header_type vlan_tag {
	fields {
		pcp : 3 bit
		cfi : 1 bit
		vid : 12 bit
		ethertype : 16 bit
	}
  }

This can be encoded in a set user visible structures and
netlink attributes in if_flow.h see, sw_hw_field_ref() struct
and IFLA_SW_HW_HEADERS netlink attribute.

--PARSE GRAPH TBD--
How headers are interpreted is a result of the hardware
parse graph. This needs to be exported for software to
learn valid packet layouts. For example hardware may be
able to handle only a single 802.1Q tag but not Q'in'Q
tags. Or in the tunnel case only use a set of actions on
the outer tags but not the inner tags. By inspecting the
parse graph software can learn these subtle differences
between hardware devices when it needs this level of
control.
--PARSE GRAPH TBDD--

Finally this interface represents each table as a
hw_flow_table structure. These can be encoded into netlink
using the HW_FLOW_TABLE identifiers. A flow table is
constrained by its size and the subset of headers and actions
its supports.

--FlowTable Graph TBD--
Flow tables are arranged in a topoligy as described by
the xxx structure. [...]
--FlowTable Graph TBD--

TBD:
 - add support for parse graph and table graphs, for simple
   ixgbe like devices this is not very interesting. But
   for tunnel support and multiple table it is required.
 - Understand when actions are applied. Current model
   assumes actions are applied @ the table. Is this OK?
 - Error handling is completely missing sorry its a prototype
   at best at the moment.

Signed-off-by: John Fastabend <john.fastabend@intel.com>
net: implement ixgbe getlink/setlink support for hw_flow tables

This enables ixgbe to suport the flow table gets and flow
additions. Driving this code via iproute bridge tool gives
the following output.

# ./bridge/bridge flow show dev p3p2
8: p3p2
headers:
  0: ethernet {
         src_mac:48  dst_mac:48  ethertype:16
         }
  1: vlan {
         pcp:3  cfi:1  vid:1  ethertype:16
         }
  2: ipv4 {
         version:4  ihl:4  dscp:6  ecn:2  length:8
         identification:8  flags:3  fragment_offset:13  ttl:1  protocol:8
         csum:8  src_ip:32  dst_ip:32  options:*
         }
  3: tcp {
         src_port:16  dst_port:16  seq:32  ack:32  offset:4
         reserved:3  flags:9  window:8  csum:16  urgent:16
         }
  4: metadata_t {
         egress_port:32  egress_queue:32
         }

table 0:1 - l2_table:0 src 0 size 128
  matches:
         field: ethernet [dst_mac]
  actions:
         0: set_egress_port ( u32 port_id  )
  flows:
         id: 99  prio: 98
           matches:
                 ethernet.dst_mac = 00:1b:21:69:9f:09 (0000000069211b00)  <-- driver mask reporting broke
           actions:
         0: set_egress_port ( u32 port  )
table 1:1 - fdir_table:1 src 0 size 2000
  matches:
         field: vlan [vid ethertype]
         field: ipv4 [src_ip dst_ip]
         field: tcp [src_port dst_port flags]
  actions:
         0: set_egress_queue ( u32 queue  )
         1: drop_packet (  )
  flows:

# ./bridge/bridge flow add dev p3p2 \
  table l2_fwd match eth.dst 00:1b:21:69:9f:10 -1 action ingress 1

Here the show command lists the available headers the device
supports in this case, ethernet, vlan, ipv4, tcp and some metadata
to set the egress port and egress queue.

The pipeline is organized into two tables the first table supports
using the destination MAC address to forward to a port. Where a
port index is either VMDQ index or a Virtual Function (VF) associated
with SR-IOV. The index' values _should_ be reported via the standard
'ip link' command set. At the moment this may need a bit of work to
clean up the accelerated MACVLAN and SR-IOV indexing.

Tables support a set of matches which must be a subset of the
supported headers and a set of actoins. The flow listing gives
the current entries in the table.

For ixgbe the parser/pipeline is statically configured at the
moment we don't have support for creating/removing tables at
any rate. Becuase the parser is static (normal case for devices
targeted @ end hosts?) the pipline is statically defined in
the ixgbe_pipeline.h file. The flow_table API is used to generate
the netlink encoding.

Signed-off-by: John Fastabend <john.fastabend@intel.com>