[ovs-dev] [PATCH ovn v2] controller: Allow specifying tos option for tunnel interface

2021-09-22 Thread venugopali--- via dev
From: Venugopal Iyer Currently, OVN tunnel interface supports the csum option along with remote_ip and key. There are applications (e.g. RoCE) that rely on setting the DSCP bits and expect it to be moved to the outer/ tunnel header as well. This commit adds an "ovn-encap-tos" external-id that ca

[ovs-dev] [PATCH ovn] ovn-controller: Allow specifying tos option for tunnel interface

2021-09-21 Thread venugopali--- via dev
From: Venugopal Iyer Currently, OVN tunnel interface supports the csum option along with remote_ip and key. There are applications (e.g. RoCE) that rely on setting the DSCP bits and expect it to be moved to the outer/ tunnel header as well. This commit adds an "ovn-encap-tos" external-id that ca

[ovs-dev] [PATCH ovn v3 1/1] controller: Check for tunnel change in multi-vtep case is incorrect

2020-09-25 Thread venugopali
From: venu iyer Prior to multi-vtep, there was one tunnel for each type, since there was only one encap-ip. So, the check in chassis_tunnels_changed(): sset_count(encap_type_set) != encap_type_count worked. However, with multiple IPs per tunnel type, the above check won't work. So, once mul

[ovs-dev] [PATCH ovn v2 1/1] controller: Check for tunnel change in multi-vtep case is incorrect

2020-09-24 Thread venugopali
From: venu iyer Prior to multi-vtep, there was one tunnel for each type, since there was only one encap-ip. So, the check in chassis_tunnels_changed(): sset_count(encap_type_set) != encap_type_count worked. However, with multiple IPs per tunnel type, the above check won't work. So, once

[ovs-dev] [PATCH ovn 1/1] ovn-controller: Check for tunnel change in multi-vtep case is incorrect

2020-09-23 Thread venugopali
From: venu iyer Prior to multi-vtep, there was one tunnel for each type, since there was only one encap-ip. So, the check in chassis_tunnels_changed(): sset_count(encap_type_set) != encap_type_count worked. However, with multiple IPs per tunnel type, the above check won't work. So, once m

[ovs-dev] [PATCH ovn v3] ovn-northd: ls_*_acl behavior not consistent for untracked flows

2019-12-19 Thread venugopali
From: venu iyer If one creates a port group and a MAC address set, and an ACL that prevents packets being output to a port in that Port Group from any MAC address in that address set, the outcome is not consistent. The outcome depends on whether there is a stateful rule on the switch or not. Sp

[ovs-dev] [PATCH ovn v2] ovn-northd: ls_*_acl behavior not consistent for untracked flows

2019-11-19 Thread venugopali
From: venu iyer If one creates a port group and a MAC address set, and an ACL that prevents packets being output to a port in that Port Group from any MAC address in that address set, the outcome is not consistent. The outcome depends on whether there is a stateful rule on the switch or not. Sp

[ovs-dev] [PATCH ovn] ovn-northd: ls_*_acl behavior not consistent for untracked flows

2019-11-19 Thread venugopali
From: venu iyer If one creates a port group and a MAC address set, and an ACL that prevents packets being output to a port in that Port Group from any MAC address in that address set, the outcome is not consistent. The outcome depends on whether there is a stateful rule on the switch or not. Sp

[ovs-dev] [RFC ovn] ovn-northd: ls_*_acl behavior not consistent for untracked flows

2019-11-14 Thread venugopali
From: venu iyer If one creates a port group and a MAC address set, and create an ACL that prevents packets being output to a port in the Port Group from any MAC address in the address set, the outcome is not consistent. The outcome depends on whether there is a stateful rule on the switch or not