All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <simon.horman@netronome.com>
To: David Miller <davem@davemloft.net>, Jiri Pirko <jiri@mellanox.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>,
	Cong Wang <xiyou.wangcong@gmail.com>,
	netdev@vger.kernel.org, oss-drivers@netronome.com,
	Simon Horman <simon.horman@netronome.com>
Subject: [PATCH v2 net-next 0/2] net/sched: support tunnel options in cls_flower and act_tunnel_key
Date: Wed, 27 Sep 2017 10:16:32 +0200	[thread overview]
Message-ID: <1506500194-17637-1-git-send-email-simon.horman@netronome.com> (raw)

Allow the flower classifier to match on tunnel options and the
tunnel key action to set them.

Tunnel options are a bytestring of up to 256 bytes.
The flower classifier matching with an optional bitwise mask.
Tunnel implementations may support more or less options,
or none at all.


Discussion stemming from review of RFC:

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.


Changes since RFC:
* Drop RFC prefix
* Correct changelogs and enhance cover letter.


Simon Horman (2):
  net/sched: add tunnel option support to act_tunnel_key
  net/sched: allow flower to match tunnel options

 include/net/flow_dissector.h              | 13 ++++++++++++
 include/uapi/linux/pkt_cls.h              |  3 +++
 include/uapi/linux/tc_act/tc_tunnel_key.h |  1 +
 net/sched/act_tunnel_key.c                | 26 ++++++++++++++++++-----
 net/sched/cls_flower.c                    | 35 ++++++++++++++++++++++++++++++-
 5 files changed, 72 insertions(+), 6 deletions(-)

-- 
2.1.4

             reply	other threads:[~2017-09-27  8:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-27  8:16 Simon Horman [this message]
2017-09-27  8:16 ` [PATCH v2 net-next 1/2] net/sched: add tunnel option support to act_tunnel_key Simon Horman
2017-09-27  8:16 ` [PATCH v2 net-next 2/2] net/sched: allow flower to match tunnel options Simon Horman
2017-09-27  9:10   ` Jiri Pirko
2017-09-27  9:27     ` Simon Horman
2017-09-27 11:08       ` Jiri Pirko
2017-09-27 11:54         ` Simon Horman
2017-09-27 12:52         ` Simon Horman
2017-09-27 12:56           ` Jiri Pirko
2017-09-27 13:37             ` Simon Horman
2017-09-27 13:47               ` Jiri Pirko
2017-09-27 13:50                 ` Simon Horman
2017-09-27 14:00                   ` Jiri Pirko
2017-09-27 14:09                     ` Simon Horman
2017-09-27 14:19                       ` Jiri Pirko
2017-09-27 15:46 ` [PATCH v2 net-next 0/2] net/sched: support tunnel options in cls_flower and act_tunnel_key Jiri Benc
2017-09-29  4:54 ` David Miller
2017-10-02  7:50   ` Simon Horman
2017-10-05 12:51     ` Jiri Benc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1506500194-17637-1-git-send-email-simon.horman@netronome.com \
    --to=simon.horman@netronome.com \
    --cc=davem@davemloft.net \
    --cc=jhs@mojatatu.com \
    --cc=jiri@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=oss-drivers@netronome.com \
    --cc=xiyou.wangcong@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.