Re: [oss-drivers] Re: [PATCH/RFC net-next 2/2] net/sched: allow flower to match tunnel options

On Wed, Sep 13, 2017 at 2:59 PM, Simon Horman
[off-list ref] wrote:

On Wed, Sep 13, 2017 at 01:03:43PM +0300, Or Gerlitz wrote:

quoted

On Wed, Sep 13, 2017 at 12:25 PM, Simon Horman
[off-list ref] wrote:

quoted

On Tue, Sep 12, 2017 at 11:23:55PM +0300, Or Gerlitz wrote:

quoted

On Tue, Sep 12, 2017 at 5:20 PM, Simon Horman
[off-list ref] wrote:

quoted

Allow matching on options in tunnel headers.
This makes use of existing tunnel metadata support.

Simon,

This patch is about matching on tunnel options, right? but

quoted

Options are a bytestring of up to 256 bytes.
Tunnel implementations may support less or more options,
or no options at all.

 # ip link add name geneve0 type geneve dstport 0 external
 # tc qdisc add dev eth0 ingress
 # tc qdisc del dev eth0 ingress; tc qdisc add dev eth0 ingress
 # tc filter add dev eth0 protocol ip parent ffff: \
     flower indev eth0 \
        ip_proto udp \
        action tunnel_key \
            set src_ip 10.0.99.192 \
            dst_ip 10.0.99.193 \
            dst_port 4789 \
            id 11 \
            opts 0102800100800022 \
    action mirred egress redirect dev geneve0

the example here is on how to use tunnel options in the tunnel set key actions..

And the other way around in the other patch... the patch is about the
tunnel key set action and the example shows how to match that in
flower... I guess you want to swap the relevant of the change log.

Yes, it seems so. Sorry about that.

no worries, you can do the swap, but before that

quoted

quoted

Anyway, is there any human readable/understandable representation of
these options? e.g what does 0102800100800022 means for geneve?

quoted

Thanks, I had not thought of that. My feeling is that could
be added to the tc tool as follow-up work.

could you spend few words on the nature of these options now when we review
the kernel patches? I guess this is somehow related to protocols such
as geneve and vxlan-gpe  -- it would be good if you elaborate on that
a bit, does
the kernel does any usage with these options beyond matching on them or stiching
them to packet headers?

This feature is to be used in conjunction with tunnels in collect metadata
(external) mode. As I understand it there are three tunnel netdevs that use
options metadata in the kernel at this time.

* Geneve

  In the case of Geneve options are TLVs[1]. My reading is that in collect
  metadata mode the kernel does not appear to do anything other than pass
  them around as a bytestring.

  [1] https://tools.ietf.org/html/draft-ietf-nvo3-geneve-05#section-3.5

* VXLAN-GBP

  In the case of VXLAN-GBP on RX in collect metadata mode options are used
  to carry information parsed in vxlan_parse_gbp_hdr() from the VXLAN Group
  Based Policy Extension[2]. On RX the options data is used to create an
  extension (header) by vxlan_build_gbp_hdr().

  [2] https://tools.ietf.org/html/draft-smith-vxlan-group-policy-03#section-2.1

* ERSPAN (GRE)

  In the case of ERSPAN, which is a variant of GRE, on RX in collect
  metadata mode options are used to carry the index parsed from the ERSPAN
  Type II feature header[3] in erspan_rcv().  The converse is true on TX
  and is handled by erspan_fb_xmit().

  [3] https://tools.ietf.org/html/draft-foschiano-erspan-03#section-4.2

Users of options:

* There are eBPF hooks to allow getting on and setting tunnel metadata:
  bpf_skb_set_tunnel_opt, bpf_skb_get_tunnel_opt.

* Open vSwitch is able to match and set Geneve and VXLAN-GBP options.

Neither of the above appear to assume any structure for the data.

I hope the above is the kind of information you are after.

yeah, this helps, do we expect HW offloads to be able to work with
these options? e.g place/match on packets
or even do something beyond that?