From: Amir Vadai <hidden> Date: 2016-08-22 14:39:04
Hi,
This patchset introduces iptunnel support using the TC subsystem.
In the decap flow, it enables the user to redirect packets from a shared tunnel
device and classify by outer and inner headers. The outer headers are extracted
from the metadata and used by the flower filter. A new action act_iptunnel,
releases the metadata.
In the encap flow, act_iptunnel creates a metadata object to be used by the
shared tunnel device. The actual redirection to the tunnel device is done using
act_mirred.
For example:
$ tc qdisc add dev vnet0 ingress
$ tc filter add dev vnet0 protocol ip parent ffff: \
flower \
ip_proto 1 \
action iptunnel encap \
src_ip 11.11.0.1 \
dst_ip 11.11.0.2 \
id 11 \
action mirred egress redirect dev vxlan0
$ tc qdisc add dev vxlan0 ingress
$ tc filter add dev vxlan0 protocol ip parent ffff: \
flower \
enc_src_ip 11.11.0.2 \
enc_dst_ip 11.11.0.1 \
enc_key_id 11 \
action iptunnel decap \
action mirred egress redirect dev vnet0
note: Current implementation supports ipv4 only, but it should be easy to add
ipv6 later on.
Amir
Changes from RFC:
- Add a new action instead of making mirred too complex
- No need to specify UDP port in action - it is already in the tunnel device
configuration
- Added a decap operation to drop tunnel metadata
Amir Vadai (3):
net/ip_tunnels: Introduce tunnel_id_to_key32() and
key32_to_tunnel_id()
net/sched: cls_flower: Classify packet in ip tunnels
net/sched: Introduce act_iptunnel
drivers/net/vxlan.c | 4 +-
include/net/ip_tunnels.h | 19 +++
include/net/tc_act/tc_iptunnel.h | 24 +++
include/net/vxlan.h | 18 --
include/uapi/linux/pkt_cls.h | 11 ++
include/uapi/linux/tc_act/tc_iptunnel.h | 40 +++++
net/ipv4/ip_gre.c | 23 +--
net/sched/Kconfig | 11 ++
net/sched/Makefile | 1 +
net/sched/act_iptunnel.c | 292 ++++++++++++++++++++++++++++++++
net/sched/cls_flower.c | 59 ++++++-
11 files changed, 459 insertions(+), 43 deletions(-)
create mode 100644 include/net/tc_act/tc_iptunnel.h
create mode 100644 include/uapi/linux/tc_act/tc_iptunnel.h
create mode 100644 net/sched/act_iptunnel.c
--
2.9.0
From: Amir Vadai <hidden> Date: 2016-08-22 14:39:05
Add utility functions to convert a 32 bits key into a 64 bits tunnel and
vice versa.
These functions will be used instead of cloning code in GRE and VXLAN,
and in tc act_iptunnel which will be introduced in a following patch in
this patchset.
Signed-off-by: Amir Vadai <redacted>
---
drivers/net/vxlan.c | 4 ++--
include/net/ip_tunnels.h | 19 +++++++++++++++++++
include/net/vxlan.h | 18 ------------------
net/ipv4/ip_gre.c | 23 ++---------------------
4 files changed, 23 insertions(+), 41 deletions(-)
From: Amir Vadai <hidden> Date: 2016-08-22 14:39:05
Introduce classifying by metadata extracted by the tunnel device.
Outer header fields - source/dest ip and tunnel id, are extracted from
the metadata when classifying.
For example, the following will add a filter on the ingress Qdisc of shared
vxlan device named 'vxlan0'. To forward packets with outer src ip
11.11.0.2, dst ip 11.11.0.1 and tunnel id 11. The packets will be
forwarded to tap device 'vnet0' (after metadata is released):
$ filter add dev vxlan0 protocol ip parent ffff: \
flower \
enc_src_ip 11.11.0.2 \
enc_dst_ip 11.11.0.1 \
enc_key_id 11 \
dst_ip 11.11.11.1 \
action iptunnel decap \
action mirred egress redirect dev vnet0
The action iptunnel, will be introduced in the next patch in this
series.
Signed-off-by: Amir Vadai <redacted>
---
include/uapi/linux/pkt_cls.h | 11 +++++++++
net/sched/cls_flower.c | 59 ++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 68 insertions(+), 2 deletions(-)
@@ -35,6 +38,8 @@ struct fl_flow_key {structflow_dissector_key_ipv6_addrsipv6;};structflow_dissector_key_portstp;+structflow_dissector_key_ipv4_addrsenc_ipv4;+structflow_dissector_key_keyidenc_key_id;}__aligned(BITS_PER_LONG/8);/* Ensure that we can do comparisons as longs. */structfl_flow_mask_range{
@@ -124,11 +129,22 @@ static int fl_classify(struct sk_buff *skb, const struct tcf_proto *tp,structcls_fl_filter*f;structfl_flow_keyskb_key;structfl_flow_keyskb_mkey;+structip_tunnel_info*info;if(!atomic_read(&head->ht.nelems))return-1;fl_clear_masked_range(&skb_key,&head->mask);++info=skb_tunnel_info(skb);+if(info){+structip_tunnel_key*key=&info->key;++skb_key.enc_ipv4.src=key->u.ipv4.src;+skb_key.enc_ipv4.dst=key->u.ipv4.dst;+skb_key.enc_key_id.keyid=tunnel_id_to_key32(key->tun_id);+}+skb_key.indev_ifindex=skb->skb_iif;/* skb_flow_dissect() does not set n_proto in case an unknown protocol,*sodoitratherhere.
@@ -345,7 +365,6 @@ static int fl_set_key(struct net *net, struct nlattr **tb,mask->indev_ifindex=0xffffffff;}#endif-fl_set_key_val(tb,key->eth.dst,TCA_FLOWER_KEY_ETH_DST,mask->eth.dst,TCA_FLOWER_KEY_ETH_DST_MASK,sizeof(key->eth.dst));
@@ -408,6 +427,29 @@ static int fl_set_key(struct net *net, struct nlattr **tb,sizeof(key->tp.dst));}+if(tb[TCA_FLOWER_KEY_ENC_IPV4_SRC]||+tb[TCA_FLOWER_KEY_ENC_IPV4_DST]||+tb[TCA_FLOWER_KEY_ENC_KEY_ID]){+fl_set_key_val(tb,&key->enc_ipv4.src,+TCA_FLOWER_KEY_ENC_IPV4_SRC,+&mask->enc_ipv4.src,+TCA_FLOWER_KEY_ENC_IPV4_SRC_MASK,+sizeof(key->enc_ipv4.src));+fl_set_key_val(tb,&key->enc_ipv4.dst,+TCA_FLOWER_KEY_ENC_IPV4_DST,+&mask->enc_ipv4.dst,+TCA_FLOWER_KEY_ENC_IPV4_DST_MASK,+sizeof(key->enc_ipv4.dst));+fl_set_key_val(tb,+&key->enc_key_id.keyid,TCA_FLOWER_KEY_ENC_KEY_ID,+&mask->enc_key_id.keyid,TCA_FLOWER_KEY_ENC_KEY_ID,+sizeof(key->enc_key_id.keyid));+}++if(tb[TCA_FLOWER_KEY_ENC_IPV6_SRC]||+tb[TCA_FLOWER_KEY_ENC_IPV6_DST])+return-ENOTSUPP;+return0;}
@@ -815,6 +857,19 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, unsigned long fh,sizeof(key->tp.dst))))gotonla_put_failure;+if(fl_dump_key_val(skb,&key->enc_ipv4.src,+TCA_FLOWER_KEY_ENC_IPV4_SRC,&mask->enc_ipv4.src,+TCA_FLOWER_KEY_ENC_IPV4_SRC_MASK,+sizeof(key->enc_ipv4.src))||+fl_dump_key_val(skb,&key->enc_ipv4.dst,+TCA_FLOWER_KEY_ENC_IPV4_DST,&mask->enc_ipv4.dst,+TCA_FLOWER_KEY_ENC_IPV4_DST_MASK,+sizeof(key->enc_ipv4.dst))||+fl_dump_key_val(skb,&key->enc_key_id,TCA_FLOWER_KEY_ENC_KEY_ID,+&mask->enc_key_id,TCA_FLOWER_KEY_ENC_KEY_ID,+sizeof(key->enc_key_id)))+gotonla_put_failure;+nla_put_u32(skb,TCA_FLOWER_FLAGS,f->flags);if(tcf_exts_dump(skb,&f->exts))
From: Amir Vadai <hidden> Date: 2016-08-22 14:39:05
This action could be used before redirecting packets to a shared tunnel
device, or when redirecting packets arriving from a such a device
The action will release the metadata created by the tunnel device
(decap), or set the metadata with the specified values for encap
operation.
For example, the following flower filter will forward all ICMP packets
destined to 11.11.11.2 through the shared vxlan device 'vxlan0'. Before
redirecting, a metadata for the vxlan tunnel is created using the
iptunnel action and it's arguments:
$ filter add dev net0 protocol ip parent ffff: \
flower \
ip_proto 1 \
dst_ip 11.11.11.2 \
action iptunnel encap \
src_ip 11.11.0.1 \
dst_ip 11.11.0.2 \
id 11 \
action mirred egress redirect dev vxlan0
Signed-off-by: Amir Vadai <redacted>
---
include/net/tc_act/tc_iptunnel.h | 24 +++
include/uapi/linux/tc_act/tc_iptunnel.h | 40 +++++
net/sched/Kconfig | 11 ++
net/sched/Makefile | 1 +
net/sched/act_iptunnel.c | 292 ++++++++++++++++++++++++++++++++
5 files changed, 368 insertions(+)
create mode 100644 include/net/tc_act/tc_iptunnel.h
create mode 100644 include/uapi/linux/tc_act/tc_iptunnel.h
create mode 100644 net/sched/act_iptunnel.c
On Mon, 22 Aug 2016 17:38:33 +0300, Amir Vadai wrote:
+ if (tb[TCA_FLOWER_KEY_ENC_IPV6_SRC] ||
+ tb[TCA_FLOWER_KEY_ENC_IPV6_DST])
+ return -ENOTSUPP;
Please add also support for IPv6. We've had enough of half-implemented
stuff in tunneling and we need to really treat IPv6 as a first class
citizen. There should be no IPv4 only submissions anymore.
Thanks,
Jiri
On Mon, 22 Aug 2016 17:38:34 +0300, Amir Vadai wrote:
This action could be used before redirecting packets to a shared tunnel
device, or when redirecting packets arriving from a such a device
The action will release the metadata created by the tunnel device
(decap), or set the metadata with the specified values for encap
operation.
I understand the motivation for the decap action. However, what would
happen if someone does not include it?
Borrowing your example from the cover letter and modifying it, what
would happen in the following case?
$ tc filter add dev vxlan0 protocol ip parent ffff: \
flower \
enc_src_ip 11.11.0.2 \
enc_dst_ip 11.11.0.1 \
enc_key_id 11 \
action mirred egress redirect dev vnet0
Thanks,
Jiri
On Mon, Aug 22, 2016 at 07:05:23PM +0200, Jiri Benc wrote:
On Mon, 22 Aug 2016 17:38:33 +0300, Amir Vadai wrote:
quoted
+ if (tb[TCA_FLOWER_KEY_ENC_IPV6_SRC] ||
+ tb[TCA_FLOWER_KEY_ENC_IPV6_DST])
+ return -ENOTSUPP;
Please add also support for IPv6. We've had enough of half-implemented
stuff in tunneling and we need to really treat IPv6 as a first class
citizen. There should be no IPv4 only submissions anymore.
+1
As IPv6 only shop we cannot stress enough importance of supporting IPv6
from day one for any new features.
Jiri B > I understand the motivation for the decap action. However, what would
Jiri B > happen if someone does not include it?
The MD set by the (say) vxlan device will not be "consumed" (cleared)
and would be keep travelling with the SKB
+
+ break;
+ default:
+ BUG();
no, please, scream if you want to go beyond warning but don't kill and don't die
On Mon, 22 Aug 2016 21:15:41 +0300, Or Gerlitz wrote:
Jiri B > I understand the motivation for the decap action. However, what would
Jiri B > happen if someone does not include it?
The MD set by the (say) vxlan device will not be "consumed" (cleared)
and would be keep travelling with the SKB
Of course it would. That's not what I meant by the question :-)
There are three options:
1. It does not matter, as the metadata_dst will be freed anyway before
it reaches tx path. This means we do not need the 'decap' action.
2. We may run into problems like tx path seeing the metadata_dst that
it should not see. This means either this situation or such
configuration must be prevented somehow.
3. The metadata_dst can reach the tx path but it doesn't matter, as it
would just mean the packet is encapsulated into the same outer
headers it was received with or the metadata_dst would be ignored
(for non-tunnel interfaces).
Which one is it? Quickly looking into the code, tcf_mirred calls
dev_queue_xmit which indicates it's either 2 or 3. If it's 3., it
should be explained in the patch description (especially the non-tunnel
interface case) and documented.
Jiri
From: Tom Herbert <hidden> Date: 2016-08-22 22:24:09
On Mon, Aug 22, 2016 at 7:38 AM, Amir Vadai [off-list ref] wrote:
Hi,
This patchset introduces iptunnel support using the TC subsystem.
In the decap flow, it enables the user to redirect packets from a shared tunnel
device and classify by outer and inner headers. The outer headers are extracted
from the metadata and used by the flower filter. A new action act_iptunnel,
releases the metadata.
In the encap flow, act_iptunnel creates a metadata object to be used by the
shared tunnel device. The actual redirection to the tunnel device is done using
act_mirred.
For example:
$ tc qdisc add dev vnet0 ingress
$ tc filter add dev vnet0 protocol ip parent ffff: \
flower \
ip_proto 1 \
action iptunnel encap \
src_ip 11.11.0.1 \
dst_ip 11.11.0.2 \
id 11 \
action mirred egress redirect dev vxlan0
Is the device required to be a tunnel device? Consider that with LWT
we can perform this sort of encapsulation without requiring a special
device...
Tom
$ tc qdisc add dev vxlan0 ingress
$ tc filter add dev vxlan0 protocol ip parent ffff: \
flower \
enc_src_ip 11.11.0.2 \
enc_dst_ip 11.11.0.1 \
enc_key_id 11 \
action iptunnel decap \
action mirred egress redirect dev vnet0
note: Current implementation supports ipv4 only, but it should be easy to add
ipv6 later on.
Amir
Changes from RFC:
- Add a new action instead of making mirred too complex
- No need to specify UDP port in action - it is already in the tunnel device
configuration
- Added a decap operation to drop tunnel metadata
Amir Vadai (3):
net/ip_tunnels: Introduce tunnel_id_to_key32() and
key32_to_tunnel_id()
net/sched: cls_flower: Classify packet in ip tunnels
net/sched: Introduce act_iptunnel
drivers/net/vxlan.c | 4 +-
include/net/ip_tunnels.h | 19 +++
include/net/tc_act/tc_iptunnel.h | 24 +++
include/net/vxlan.h | 18 --
include/uapi/linux/pkt_cls.h | 11 ++
include/uapi/linux/tc_act/tc_iptunnel.h | 40 +++++
net/ipv4/ip_gre.c | 23 +--
net/sched/Kconfig | 11 ++
net/sched/Makefile | 1 +
net/sched/act_iptunnel.c | 292 ++++++++++++++++++++++++++++++++
net/sched/cls_flower.c | 59 ++++++-
11 files changed, 459 insertions(+), 43 deletions(-)
create mode 100644 include/net/tc_act/tc_iptunnel.h
create mode 100644 include/uapi/linux/tc_act/tc_iptunnel.h
create mode 100644 net/sched/act_iptunnel.c
--
2.9.0
From: Amir Vadai <hidden> Date: 2016-08-23 10:15:58
On Mon, Aug 22, 2016 at 03:23:45PM -0700, Tom Herbert wrote:
On Mon, Aug 22, 2016 at 7:38 AM, Amir Vadai [off-list ref] wrote:
quoted
Hi,
This patchset introduces iptunnel support using the TC subsystem.
In the decap flow, it enables the user to redirect packets from a shared tunnel
device and classify by outer and inner headers. The outer headers are extracted
from the metadata and used by the flower filter. A new action act_iptunnel,
releases the metadata.
In the encap flow, act_iptunnel creates a metadata object to be used by the
shared tunnel device. The actual redirection to the tunnel device is done using
act_mirred.
For example:
$ tc qdisc add dev vnet0 ingress
$ tc filter add dev vnet0 protocol ip parent ffff: \
flower \
ip_proto 1 \
action iptunnel encap \
src_ip 11.11.0.1 \
dst_ip 11.11.0.2 \
id 11 \
action mirred egress redirect dev vxlan0
Is the device required to be a tunnel device? Consider that with LWT
we can perform this sort of encapsulation without requiring a special
device...
Tom
Yes and no. This action is relevant only for a shared tunnel device.
like the one you get with:
$ ip link add vxlan0 type vxlan dstport 4789 external
A user can add metadata using this action and redirect to any netdev,
but only the shared tunnel netdev will do something with it.
Regarding LWT, in our use case we need to have classification in
addition to the routing, have both encap and decap operations and be
ready to add offloading to the API. For that, TC subsystem looked
the most suiteable.
Thanks,
Amir
[...]
From: Jamal Hadi Salim <jhs@mojatatu.com> Date: 2016-08-23 12:37:11
On 16-08-22 10:38 AM, Amir Vadai wrote:
This action could be used before redirecting packets to a shared tunnel
device, or when redirecting packets arriving from a such a device
The action will release the metadata created by the tunnel device
(decap), or set the metadata with the specified values for encap
operation.
For example, the following flower filter will forward all ICMP packets
destined to 11.11.11.2 through the shared vxlan device 'vxlan0'. Before
redirecting, a metadata for the vxlan tunnel is created using the
iptunnel action and it's arguments:
$ filter add dev net0 protocol ip parent ffff: \
flower \
ip_proto 1 \
dst_ip 11.11.11.2 \
action iptunnel encap \
src_ip 11.11.0.1 \
dst_ip 11.11.0.2 \
id 11 \
action mirred egress redirect dev vxlan0
The noun "ip tunnel" is a little misleading. Unless you can use
this for other types of tunnels (ipip, etc). If this is specific
for just vxlan and metadata setting then some name like vxlanmeta
or something else that signifies both metadata de/encap + vxlan would
be helpful.
Can you rename this function to something more grep-able
like tcf_iptunnel_run or tcf_iptunnel_exec?
You already have a data structure called tcf_iptunnel
More grep-ability tun_info sounds and i think is used by tun netdev.
Otherwise looks good (although i still think this wouldve scaled better
if you didnt depend on presence of vxlan dev).
cheers,
jamal
From: Amir Vadai <hidden> Date: 2016-08-23 15:28:24
On Mon, Aug 22, 2016 at 08:51:37PM +0200, Jiri Benc wrote:
On Mon, 22 Aug 2016 21:15:41 +0300, Or Gerlitz wrote:
quoted
Jiri B > I understand the motivation for the decap action. However, what would
Jiri B > happen if someone does not include it?
The MD set by the (say) vxlan device will not be "consumed" (cleared)
and would be keep travelling with the SKB
Of course it would. That's not what I meant by the question :-)
There are three options:
1. It does not matter, as the metadata_dst will be freed anyway before
it reaches tx path. This means we do not need the 'decap' action.
2. We may run into problems like tx path seeing the metadata_dst that
it should not see. This means either this situation or such
configuration must be prevented somehow.
3. The metadata_dst can reach the tx path but it doesn't matter, as it
would just mean the packet is encapsulated into the same outer
headers it was received with or the metadata_dst would be ignored
(for non-tunnel interfaces).
Which one is it? Quickly looking into the code, tcf_mirred calls
dev_queue_xmit which indicates it's either 2 or 3. If it's 3., it
should be explained in the patch description (especially the non-tunnel
interface case) and documented.
First, as you suspected it is (2) or (3). AFAIK the skb is injected by
act_mirred as is, with the metadata into the tx path.
I couldn't find a case where having the metadata on the skb matters.
Still, I would be very happy to hear what other people have to say about
it.
Anyway, this issue is orthogonal to this patchset...
On Tue, 23 Aug 2016 18:28:05 +0300, Amir Vadai wrote:
On Mon, Aug 22, 2016 at 08:51:37PM +0200, Jiri Benc wrote:
quoted
2. We may run into problems like tx path seeing the metadata_dst that
it should not see. This means either this situation or such
configuration must be prevented somehow.
[...]
Anyway, this issue is orthogonal to this patchset...
Not really. If it's indeed (2) then such configuration needs to be
rejected. Or metadata_dst freed at an appropriate place. Thus it's
something that needs to be handled by this patchset before the uAPI is
set in stone.
Jiri
On Tue, 23 Aug 2016 19:05:37 +0300, Amir Vadai wrote:
It is already there - user can use act_mirred and redirect skb's with
metadata since shared tunnel devices introduced.
You're right, I haven't thought of that.
The only thing that was added here, is to enable the user to drop the
metadata, which I think we agree is the ok.
Absolutely. It would be even better if the metadata could be dropped
automatically but I don't see any good place to do it.
But I agree with you, that I must understand the life cycle of the metadata and dst
better. I will try to understand it better and explain/fix accordingly.
From: Amir Vadai <hidden> Date: 2016-08-23 16:24:41
On Tue, Aug 23, 2016 at 05:33:49PM +0200, Jiri Benc wrote:
On Tue, 23 Aug 2016 18:28:05 +0300, Amir Vadai wrote:
quoted
On Mon, Aug 22, 2016 at 08:51:37PM +0200, Jiri Benc wrote:
quoted
2. We may run into problems like tx path seeing the metadata_dst that
it should not see. This means either this situation or such
configuration must be prevented somehow.
[...]
quoted
Anyway, this issue is orthogonal to this patchset...
Not really. If it's indeed (2) then such configuration needs to be
rejected.
The configuration that needs to be rejected is when act_iptunnel is not
used. So, I guess the fix won't be part of it...
Or metadata_dst freed at an appropriate place. Thus it's
something that needs to be handled by this patchset before the uAPI is
set in stone.
It is already there - user can use act_mirred and redirect skb's with
metadata since shared tunnel devices introduced.
The only thing that was added here, is to enable the user to drop the
metadata, which I think we agree is the ok.
But I agree with you, that I must understand the life cycle of the metadata and dst
better. I will try to understand it better and explain/fix accordingly.
Again, would be happy if someone will chime in and give some hints if it
was a bug, that a user could redirect skb's with metadata, or something
harmless.
Thanks,
Amir
From: Amir Vadai <hidden> Date: 2016-08-23 16:39:47
On Tue, Aug 23, 2016 at 08:37:07AM -0400, Jamal Hadi Salim wrote:
On 16-08-22 10:38 AM, Amir Vadai wrote:
quoted
This action could be used before redirecting packets to a shared tunnel
device, or when redirecting packets arriving from a such a device
The action will release the metadata created by the tunnel device
(decap), or set the metadata with the specified values for encap
operation.
For example, the following flower filter will forward all ICMP packets
destined to 11.11.11.2 through the shared vxlan device 'vxlan0'. Before
redirecting, a metadata for the vxlan tunnel is created using the
iptunnel action and it's arguments:
$ filter add dev net0 protocol ip parent ffff: \
flower \
ip_proto 1 \
dst_ip 11.11.11.2 \
action iptunnel encap \
src_ip 11.11.0.1 \
dst_ip 11.11.0.2 \
id 11 \
action mirred egress redirect dev vxlan0
The noun "ip tunnel" is a little misleading. Unless you can use
this for other types of tunnels (ipip, etc). If this is specific
for just vxlan and metadata setting then some name like vxlanmeta
or something else that signifies both metadata de/encap + vxlan would
be helpful.
Yeh, this name is not the best...
The action is not vxlan specific, it should be good for all the
ip tunnel interfaces that use metadata for the outer headers.
I will rename it to something like mdtunnel - unless someone has a
better suggestion.
Can you rename this function to something more grep-able
like tcf_iptunnel_run or tcf_iptunnel_exec?
You already have a data structure called tcf_iptunnel
So the real decap is going to be at the vxlan dev?
yes, the action here will just cleanup after the tunnel device will peel
off the outer headers and place it in the metadata. This metadata was
used by the classifier and now can be released.
More grep-ability tun_info sounds and i think is used by tun netdev.
ack
Otherwise looks good (although i still think this wouldve scaled better
if you didnt depend on presence of vxlan dev).
now I start to have some regrets :)
But I don't see a good enough reason to duplicate code, since I can't
point my finger on a performance problem with using the existing code.
Thanks,
Amir
Hi,
On Tue, 23 Aug 2016 19:21:41 +0300 Amir Vadai [off-list ref] wrote:
On Tue, Aug 23, 2016 at 08:37:07AM -0400, Jamal Hadi Salim wrote:
quoted
The noun "ip tunnel" is a little misleading. Unless you can use
this for other types of tunnels (ipip, etc). If this is specific
for just vxlan and metadata setting then some name like vxlanmeta
or something else that signifies both metadata de/encap + vxlan would
be helpful.
Yeh, this name is not the best...
The action is not vxlan specific, it should be good for all the
ip tunnel interfaces that use metadata for the outer headers.
I will rename it to something like mdtunnel - unless someone has a
better suggestion.
Well, in bpf we have BPF_FUNC_skb_set_tunnel_key.
How about "action tunnel_key" as the noun?
Another decent alternative might be "action tunnel_info".
Not sure about the verbs though.. "action tunnel_key set/unset"?
Regards,
Shmulik