On Tue, Aug 7, 2018 at 6:36 PM, Simon Horman <simon.hor...@netronome.com> wrote: > From: Pieter Jansen van Vuuren <pieter.jansenvanvuu...@netronome.com> > > Allow matching on options in Geneve tunnel headers. > This makes use of existing tunnel metadata support. > > The options can be described in the form > CLASS:TYPE:DATA/CLASS_MASK:TYPE_MASK:DATA_MASK, where CLASS is > represented as a 16bit hexadecimal value, TYPE as an 8bit > hexadecimal value and DATA as a variable length hexadecimal value. > > e.g. > # ip link add name geneve0 type geneve dstport 0 external > # tc qdisc add dev geneve0 ingress > # tc filter add dev geneve0 protocol ip parent ffff: \ > flower \ > enc_src_ip 10.0.99.192 \ > enc_dst_ip 10.0.99.193 \ > enc_key_id 11 \ > geneve_opts 0102:80:1122334421314151/ffff:ff:ffffffffffffffff \ > ip_proto udp \ > action mirred egress redirect dev eth1 > > This patch adds support for matching Geneve options in the order > supplied by the user. This leads to an efficient implementation in > the software datapath (and in our opinion hardware datapaths that > offload this feature). It is also compatible with Geneve options > matching provided by the Open vSwitch kernel datapath which is > relevant here as the Flower classifier may be used as a mechanism > to program flows into hardware as a form of Open vSwitch datapath > offload (sometimes referred to as OVS-TC). The netlink > Kernel/Userspace API may be extended, for example by adding a flag, > if other matching options are desired, for example matching given > options in any order. This would require an implementation in the > TC software datapath. And be done in a way that drivers that > facilitate offload of the Flower classifier can reject or accept > such flows based on hardware datapath capabilities. > > This approach was discussed and agreed on at Netconf 2018 in Seoul.
2017, please fix 2018 was in Montreal
