[ovs-dev] [PATCH v2] Add VxLAN-GBP support for user space data path

[Johnson.Li]

From: Johnson Li 

In user space, only standard VxLAN was support. This patch will
add the VxLAN-GBP support for the user space data path.

How to use:
1> Create VxLAN port with GBP extension
  $ovs-vsctl add-port br-int vxlan0 -- set interface vxlan0 \
   type=vxlan options:dst_port=4789 \
   options:remote_ip=192.168.60.22 \
   options:key=1000 options:exts=gbp
2> Add flow for transmitting
  $ovs-ofctl add-flow br-int "table=0, priority=260, \
 in_port=LOCAL actions=load:0x100->NXM_NX_TUN_GBP_ID[], \
 output:1"
3> Add flow for receiving
  $ovs-ofctl add-flow br-int "table=0, priority=260, \
 in_port=1,tun_gbp_id=0x100 actions=output:LOCAL"

Check data path flow rules:
$ovs-appctl dpif/dump-flows br-int
  recirc_id(0),in_port(1),eth_type(0x0800),ipv4(tos=0/0x3,frag=no),
  packets:0, bytes:0, used:never, actions:tnl_push(tnl_port(2),
  header(size=50,type=4,eth(dst=90:e2:ba:48:7f:a4,src=90:e2:ba:48:7e:1c,
  dl_type=0x0800),ipv4(src=192.168.60.21,dst=192.168.60.22,proto=17,
  tos=0,ttl=64,frag=0x4000),udp(src=0,dst=4789,csum=0x0),
  vxlan(flags=0x88000100,vni=0x3e8)),out_port(3))
  tunnel(tun_id=0x3e8,src=192.168.60.22,dst=192.168.60.21,
  vxlan(gbp(id=256)),flags(-df-csum+key)),skb_mark(0),recirc_id(0),
  in_port(2),eth(dst=ae:1b:ed:1e:e3:4e),eth_type(0x0800),
  ipv4(dst=172.168.60.21,proto=1/0x10,frag=no), packets:0, bytes:0,
  used:never, actions:1

Change Log:
  v2: Set Each enabled bit for the VxLAN-GBP.

Signed-off-by: Johnson Li 

diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
index e398562..0ac449e 100644
--- a/lib/netdev-vport.c
+++ b/lib/netdev-vport.c
@@ -1286,6 +1286,7 @@ netdev_vxlan_pop_header(struct dp_packet *packet)
 struct flow_tnl *tnl = &md->tunnel;
 struct vxlanhdr *vxh;
 unsigned int hlen;
+uint32_t vxh_flags;
 
 pkt_metadata_init_tnl(md);
 if (VXLAN_HLEN > dp_packet_l4_size(packet)) {
@@ -1297,10 +1298,18 @@ netdev_vxlan_pop_header(struct dp_packet *packet)
 return EINVAL;
 }
 
-if (get_16aligned_be32(&vxh->vx_flags) != htonl(VXLAN_FLAGS) ||
-   (get_16aligned_be32(&vxh->vx_vni) & htonl(0xff))) {
-VLOG_WARN_RL(&err_rl, "invalid vxlan flags=%#x vni=%#x\n",
- ntohl(get_16aligned_be32(&vxh->vx_flags)),
+vxh_flags = get_16aligned_be32(&vxh->vx_flags);
+if (vxh_flags & htonl(VXLAN_HF_GBP)) {
+tnl->gbp_id = htons(ntohl(vxh_flags) & VXLAN_GBP_ID_MASK);
+vxh_flags &= (VXLAN_GBP_DONT_LEARN | VXLAN_GBP_POLICY_APPLIED);
+tnl->gbp_flags = vxh_flags >> 16;
+} else if (vxh_flags != htonl(VXLAN_FLAGS)) {
+VLOG_WARN_RL(&err_rl, "invalid vxlan flags=%#x\n",
+ ntohl(get_16aligned_be32(&vxh->vx_flags)));
+return EINVAL;
+}
+if (get_16aligned_be32(&vxh->vx_vni) & htonl(0xff)) {
+VLOG_WARN_RL(&err_rl, "invalid vxlan vni=%#x\n",
  ntohl(get_16aligned_be32(&vxh->vx_vni)));
 return EINVAL;
 }
@@ -1312,6 +1321,26 @@ netdev_vxlan_pop_header(struct dp_packet *packet)
 return 0;
 }
 
+static void
+netdev_vxlan_build_gbp_header(struct vxlanhdr *vxh,
+  const struct flow *tnl_flow)
+{
+uint32_t vxh_flags = VXLAN_FLAGS;
+
+/* G bit to indicates that the source TSI Group membership is being
+ * carried within the Group Policy ID field. */
+vxh_flags |= VXLAN_HF_GBP;
+
+/* Only D bit and A bit is valid in gbp_flags. Other bit which is
+ * set will be ignored. */
+vxh_flags |= (tnl_flow->tunnel.gbp_flags << 16)
+  & (VXLAN_GBP_DONT_LEARN | VXLAN_GBP_POLICY_APPLIED);
+
+vxh_flags |= ntohs(tnl_flow->tunnel.gbp_id);
+
+put_16aligned_be32(&vxh->vx_flags, htonl(vxh_flags));
+}
+
 static int
 netdev_vxlan_build_header(const struct netdev *netdev,
   struct ovs_action_push_tnl *data,
@@ -1328,7 +1357,11 @@ netdev_vxlan_build_header(const struct netdev *netdev,
 
 vxh = udp_build_header(tnl_cfg, tnl_flow, data, &hlen);
 
-put_16aligned_be32(&vxh->vx_flags, htonl(VXLAN_FLAGS));
+if (tnl_cfg->exts & (1 << OVS_VXLAN_EXT_GBP)) {
+netdev_vxlan_build_gbp_header(vxh, tnl_flow);
+} else {
+put_16aligned_be32(&vxh->vx_flags, htonl(VXLAN_FLAGS));
+}
 put_16aligned_be32(&vxh->vx_vni, htonl(ntohll(tnl_flow->tunnel.tun_id) << 
8));
 
 ovs_mutex_unlock(&dev->mutex);
diff --git a/lib/packets.h b/lib/packets.h
index 8139a6b..c78b053 100644
--- a/lib/packets.h
+++ b/lib/packets.h
@@ -1003,6 +1003,11 @@ struct vxlanhdr {
 
 #define VXLAN_FLAGS 0x0800  /* struct vxlanhdr.vx_flags required value. */
 
+#define VXLAN_HF_GBP 0x8000  /* Group Based Policy, BIT(31) */
+#define VXLAN_GBP_DONT_LEARN 0x40 /* Don't Learn, (BIT(6) << 16) */
+#define VXLAN_GBP_POLICY_APPLIED 0x8 /* Policy Applied, (BIT(3) << 16) */
+#define VXLAN_GBP_ID_MASK 0x /* GBP ID */
+
 void ipv6_format_addr(const struct in6_addr *addr, struct ds *);
 void ipv6_fo

Re: [ovs-dev] 答复: Reply: ovs + dpdk vhost-user match flows but cannot execute actions

[Mauricio Vásquez]

Hi lifuqion,

It appears to me that the problem is that port1 is dropping the packets. I
would suggest to create a simplified setup:
- One dpdk physical NIC
- One vhost-user port
- Remove the NORMAL flow
ovs-ofctl del-flows ovsbr0
- Add a pair of flows between the physical NIC and the VM (please check the
openflow numbers of the ports, you can use the ovs-ofctl show ovsbr0
command)
ovs-ofctl add-flow ovsbr0 "in_port=1 action=output:2"
ovs-ofctl add-flow ovsbr0 "in_port=2 action=output:1"

Try to ping, use the dump-flows and dump-ports commands to view the packets
counters,

Please let me know the results of that test.

Mauricio Vasquez,

On Wed, Apr 20, 2016 at 2:30 AM, lifuqiong  wrote:

> Hi Mauricio Vasquez:
>
>
>
> root@host52:~# ovs-vsctl show
>
> f2664a74-7523-4240-812a-4f022051346a
>
> Bridge "ovsbr0"
>
> Port "vhost-user-1"
>
> Interface "vhost-user-1"
>
> type: dpdkvhostuser
>
> Port "dpdk0"
>
> Interface "dpdk0"
>
> type: dpdk
>
> Port "ovsbr0"
>
> Interface "ovsbr0"
>
> type: internal
>
> Port "vhost-user-0"
>
> Interface "vhost-user-0"
>
> type: dpdkvhostuser
>
> Port "dpdk1"
>
> Interface "dpdk1"
>
> type: dpdk
>
>
>
> root@host52:~# ovs-ofctl dump-flows ovsbr0
>
> NXST_FLOW reply (xid=0x4):
>
> cookie=0x0, duration=291278.976s, table=0, n_packets=4414, n_bytes=392730,
> idle_age=65534, hard_age=65534, priority=0 actions=NORMAL
>
>
>
>
>
> root@host52:~# ovs-ofctl dump-ports ovsbr0
>
> OFPST_PORT reply (xid=0x2): 5 ports
>
>   port  4: rx pkts=2472, bytes=207008, drop=?, errs=0, frame=?, over=?,
> crc=?
>
>tx pkts=1893, bytes=181572, drop=49, errs=?, coll=?
>
>   port LOCAL: rx pkts=23, bytes=1278, drop=0, errs=0, frame=0, over=0,
> crc=0
>
>tx pkts=631, bytes=28750, drop=0, errs=0, coll=0
>
>   port  1: rx pkts=272, bytes=26283, drop=127396, errs=0, frame=?, over=?,
> crc=?
>
>tx pkts=0, bytes=0, drop=0, errs=0, coll=?
>
>   port  2: rx pkts=0, bytes=0, drop=0, errs=0, frame=?, over=?, crc=?
>
>tx pkts=0, bytes=0, drop=0, errs=0, coll=?
>
>   port  3: rx pkts=1919, bytes=184174, drop=?, errs=0, frame=?, over=?,
> crc=?
>
>tx pkts=2462, bytes=205658, drop=0, errs=?, coll=?
>
>
>
> Thank you.
>
> *发件人:* Mauricio Vásquez [mailto:mauricio.vasquezber...@studenti.polito.it]
>
> *发送时间:* 2016年4月19日 21:49
> *收件人:* lifuqiong
> *抄送:* dev@openvswitch.org
> *主题:* Re: Reply: [ovs-dev] ovs + dpdk vhost-user match flows but cannot
> execute actions
>
>
>
> Hi lifuqiong,
>
> Could you provide the output of the following commands in your setup?:
> ovs-vsctl show
> ovs-ofctl dump-flows
> ovs-ofctl dump-ports
>
> Mauricio Vasquez,
>
>
>
> On Sat, Apr 16, 2016 at 10:23 AM, lifuqiong 
> wrote:
>
> Hi Mauricio:
>
>  I changed my qemu version from 2.2.1 to 2.5.0 and the vms can
> communication with each other. But the VM cannot ping PC in the outside
> network. They in a same subnet.
>
>
>
> PC(192.168.0.103/24) ping vm(192.168.0.90);  vm’s host’s dpdk NIC and PC
> are in a L2 switch. And DPDK NIC connected to switch’s Port Eth1/0/8
>
> Investigation:
>
>  Binding VM’s IP and Mac in PC’s ARP table, and binding VM’s Mac
> in Port Eth1/0/8; PC is pinging vm, I can see Output packets of Eth1/0/8
> increasing regularly, which means the ping request packet has send to DPDK
> NIC.
>
>
>
> But the VM can not receive the packet?
>
>
>
>  My switch has NO vlan , the default VLAN is 1. But when I ping
> from vm1 to vm2 , showing MaC address in OVS which shows as follows:
>
> port  VLAN  MACAge
>
> 4 0  00:00:00:00:02:121
>
> 3 0  00:00:00:00:00:041
>
>
>
>
>
> What was the reason why VM cannot communication with the PC? Thank you
>
>
>
> *发件人:* lifuqiong [mailto:lifuqi...@cncloudsec.com]
> *发送时间:* 2016年4月15日 9:22
> *收件人:* 'Mauricio Vásquez'
> *抄送:* 'dev@openvswitch.org'
> *主题:* 答复: [ovs-dev] ovs + dpdk vhost-user match flows but cannot execute
> actions
>
>
>
> Hello Mauricio Vasquez:
>
> It works. Thank you very much.
>
>
>
>
>
> *发件人:* Mauricio Vásquez [mailto:mauricio.vasquezber...@studenti.polito.it
> ]
> *发送时间:* 2016年4月14日 14:55
> *收件人:* lifuqiong
> *抄送:* dev@openvswitch.org
> *主题:* Re: [ovs-dev] ovs + dpdk vhost-user match flows but cannot execute
> actions
>
>
>
> Hello lifuqiong,
>
> I faced the same problem some days ago (
> http://openvswitch.org/pipermail/dev/2016-March/068282.html), the bug is
> already fixed.
>
> Where are you downloading OVS from?, it appears that the bug is still
> present in the version on
> http://openvswitch.org/releases/openvswitch-2.5.0.tar.gz, please download
> ovs from git and switch to branch-2.5.
>
> Mauricio Vasquez,
>
>
>
> On Thu, Apr 14, 2016 at 4:28 AM, lifuqiong 
> wrote:
>
> I want to test dpdk vhost-user port on ovs to follow
> https://software.intel.com/en-us/blogs/2015/06/0

Re: [ovs-dev] [RFC PATCH] create vxlan device using rtnetlink interface

[Thadeu Lima de Souza Cascardo]

On Tue, Apr 19, 2016 at 04:25:32PM -0700, Jesse Gross wrote:
> On Mon, Apr 18, 2016 at 2:57 AM, Thadeu Lima de Souza Cascardo
>  wrote:
> > On Fri, Apr 15, 2016 at 08:36:51PM -0700, Jesse Gross wrote:
> >> On Fri, Apr 15, 2016 at 2:30 PM, Thadeu Lima de Souza Cascardo
> >>  wrote:
> >> > Hi, this is an RFC patch (could probably be 2 patches - more below), that
> >> > creates VXLAN devices in userspace and adds them as netdev vports, 
> >> > instead of
> >> > using the vxlan vport code.
> >> >
> >> > The reason for this change is that it has been mentioned in the past 
> >> > that some
> >> > of the vport code should be considered compat code, that is, it won't 
> >> > receive
> >> > new features or flags.
> >>
> >> Thanks for looking at this. I agree that this is definitely a
> >> necessary direction.
> >>
> >> > First is the creation of the device under a switch/case. I tried to make 
> >> > this a
> >> > netdev_class function, overriding the netdev class by 
> >> > dpif_port_open_type. That
> >> > required exporting a lot of the vport functions. I can still do it that 
> >> > way, if
> >> > that's preferrable, but this seems more simple.
> >>
> >> Can you give some examples of what would need to be exported? It would
> >> be nice to just set the open function for each type but if it is
> >> really horrible we can live with the switch statement.
> >>
> >
> > netdev_vport_{alloc, construct, destruct, dealloc}, get_tunnel_config,
> > set_tunnel_config, get_netdev_tunnel_config.
> >
> > We could also do it the other way around, write this code in netdev-vport.c 
> > and
> > export one or two functions from netdev-linux or dpif-netlink, and the 
> > create
> > function per tunnel type.
> 
> OK, thanks, I understand now. I think what you have currently is
> probably the best solution for the time being.
> 
> >> > The other problem is during port_del, that since we don't have a netdev, 
> >> > the
> >> > dpif_port type would not be vxlan, and deciding whether to remove it or 
> >> > not
> >> > could not be made. In fact, this is one of the main reasons why this is 
> >> > an RFC.
> >> >
> >> > The solution here is to decide on the type by the device's name, and 
> >> > there is
> >> > even a function for this, though it looks up for the netdev's already 
> >> > created,
> >> > those that probably come from the database. However, when OVS starts, it 
> >> > removes
> >> > ports from the datapath, and that information is not available, and may 
> >> > not even
> >> > be. In fact, since the dpif_port has a different name because it's a 
> >> > vport, it
> >> > won't match any netdev at all. So, I did the opposite of getting the 
> >> > type from
> >> > the dpif_port name, ie, if it contains vxlan_sys, it's of vxlan type. 
> >> > Even if we
> >> > make this more strict and use the port, we could still be in conflict 
> >> > with a
> >> > vxlan device created by the user with such name. This should have been 
> >> > one patch
> >> > by itself.
> >>
> >> What about using the driver name exposed through ethtool? I believe
> >> that all of the tunnel and internal devices expose this in a
> >> consistent way - i.e. a VXLAN device can be queried and get back the
> >> string "vxlan". Any driver other than the ones that we recognize can
> >> be assumed to be OVS_VPORT_TYPE_NETDEV.
> >>
> >
> > I don't see how this address the case when the user adds a vxlan interface
> > created by the system. Like:
> >
> > ip link add vxlan_sys_4789 type vxlan id 10 remote 192.168.123.1 dstport 
> > 4789
> > ovs-vsctl add-port br0 vxlan_sys_4789
> >
> > Its driver would be vxlan. That goes to vxlan0 too.
> 
> I think we can check the combination of device type and the options
> that are set on it (the same as what we need to do after we create the
> device). If all of those match then it doesn't matter whether we added
> it previously or the user added it - the device will work exactly the
> same either way. If there isn't a match then we should bail out
> without adding the port. This is pretty similar to the behavior of the
> current compat code in the kernel (in that case if a port already
> exists with the same name, it just aborts).
> 

As I pointed out in another message, vxlan_sys* is a reserved name, if
any port like that is added to the database, it's going to be rejected
by vswitchd. The same goes for other vports. So, I think it's sufficient
to check this name, then set the type appropriately, and depending on
the type, try to remove the interface. So vxlan0 is not going to be
removed, but vxlan_sys_4789 will.

> Two unresolved issues in my mind:
>  * How do we handle cleaning up ports (including in cases where
> userspace crashes)? In the kernel case, the port will stick around
> until either the module is removed or the port is explicitly deleted.
>  * How do we handle upgrade where the new version of OVS needs options
> that are different from the previous version? This is basically a
> special version of the port being crea

[ovs-dev] Reply: ovs + dpdk vhost-user match flows but cannot execute actions

[lifuqiong]

Hi Mauricio Vasquez:

Thank you for your good advice.

I changed my environment as you metioned, And try to ping from VM to pc, 
but they cannot still ping each other.

The result is still my dpdk physical NIC drop packets. Is my NIC problem?

 

Here is my configuration:

1.  ovs-ofctl dump-flows ovsbr0

NXST_FLOW reply (xid=0x4):

cookie=0x0, duration=364.902s, table=0, n_packets=0, n_bytes=0, idle_age=364, 
in_port=1 actions=output:3

cookie=0x0, duration=356.014s, table=0, n_packets=191, n_bytes=8334, 
idle_age=1, in_port=3 actions=output:1

 

2.  ovs-ofctl dump-ports ovsbr0

OFPST_PORT reply (xid=0x2): 3 ports

  port LOCAL: rx pkts=23, bytes=1278, drop=0, errs=0, frame=0, over=0, crc=0

   tx pkts=631, bytes=28750, drop=0, errs=0, coll=0

  port  1: rx pkts=272, bytes=26283, drop=188024, errs=0, frame=?, over=?, crc=?

   tx pkts=0, bytes=0, drop=0, errs=0, coll=?

  port  3: rx pkts=2110, bytes=192508, drop=?, errs=0, frame=?, over=?, crc=?

   tx pkts=2462, bytes=205658, drop=0, errs=?, coll=?

 

3.  ovs-ofctl show ovsbr0

OFPT_FEATURES_REPLY (xid=0x2): dpid:2c534a01cd5e

n_tables:254, n_buffers:256

capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP

actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src 
mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst

1(dpdk0): addr:2c:53:4a:01:cd:5e

 config: 0

 state:  0

 current:100MB-FD

 supported:  100MB-FD 1GB-HD 1GB-FD 10GB-FD AUTO_NEG AUTO_PAUSE_ASYM

 speed: 100 Mbps now, 1 Mbps max

3(vhost-user-0): addr:00:00:00:00:00:00

 config: PORT_DOWN

 state:  LINK_DOWN

 speed: 0 Mbps now, 0 Mbps max

LOCAL(ovsbr0): addr:2c:53:4a:01:cd:5e

 config: 0

 state:  0

 current:10MB-FD COPPER

 speed: 10 Mbps now, 0 Mbps max

OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0

发件人: Mauricio Vásquez [mailto:mauricio.vasquezber...@studenti.polito.it] 
发送时间: 2016年4月20日 18:00
收件人: lifuqiong
抄送: dev@openvswitch.org
主题: Re: 答复: Reply: [ovs-dev] ovs + dpdk vhost-user match flows but cannot 
execute actions

 

Hi lifuqion,

It appears to me that the problem is that port1 is dropping the packets. I 
would suggest to create a simplified setup:

- One dpdk physical NIC

- One vhost-user port

- Remove the NORMAL flow
ovs-ofctl del-flows ovsbr0

- Add a pair of flows between the physical NIC and the VM (please check the 
openflow numbers of the ports, you can use the ovs-ofctl show ovsbr0 command)
ovs-ofctl add-flow ovsbr0 "in_port=1 action=output:2"
ovs-ofctl add-flow ovsbr0 "in_port=2 action=output:1"

Try to ping, use the dump-flows and dump-ports commands to view the packets 
counters,

Please let me know the results of that test.

Mauricio Vasquez, 

 

On Wed, Apr 20, 2016 at 2:30 AM, lifuqiong  wrote:

Hi Mauricio Vasquez:

 

root@host52:~# ovs-vsctl show

f2664a74-7523-4240-812a-4f022051346a

Bridge "ovsbr0"

Port "vhost-user-1"

Interface "vhost-user-1"

type: dpdkvhostuser

Port "dpdk0"

Interface "dpdk0"

type: dpdk

Port "ovsbr0"

Interface "ovsbr0"

type: internal

Port "vhost-user-0"

Interface "vhost-user-0"

type: dpdkvhostuser

Port "dpdk1"

Interface "dpdk1"

type: dpdk

 

root@host52:~# ovs-ofctl dump-flows ovsbr0

NXST_FLOW reply (xid=0x4):

cookie=0x0, duration=291278.976s, table=0, n_packets=4414, n_bytes=392730, 
idle_age=65534, hard_age=65534, priority=0 actions=NORMAL

 

 

root@host52:~# ovs-ofctl dump-ports ovsbr0

OFPST_PORT reply (xid=0x2): 5 ports

  port  4: rx pkts=2472, bytes=207008, drop=?, errs=0, frame=?, over=?, crc=?

   tx pkts=1893, bytes=181572, drop=49, errs=?, coll=?

  port LOCAL: rx pkts=23, bytes=1278, drop=0, errs=0, frame=0, over=0, crc=0

   tx pkts=631, bytes=28750, drop=0, errs=0, coll=0

  port  1: rx pkts=272, bytes=26283, drop=127396, errs=0, frame=?, over=?, crc=?

   tx pkts=0, bytes=0, drop=0, errs=0, coll=?

  port  2: rx pkts=0, bytes=0, drop=0, errs=0, frame=?, over=?, crc=?

   tx pkts=0, bytes=0, drop=0, errs=0, coll=?

  port  3: rx pkts=1919, bytes=184174, drop=?, errs=0, frame=?, over=?, crc=?

   tx pkts=2462, bytes=205658, drop=0, errs=?, coll=?

 

Thank you.

发件人: Mauricio Vásquez [mailto:mauricio.vasquezber...@studenti.polito.it] 
发送时间: 2016年4月19日 21:49
收件人: lifuqiong
抄送: dev@openvswitch.org
主题: Re: Reply: [ovs-dev] ovs + dpdk vhost-user match flows but cannot execute 
actions

 

Hi lifuqiong, 

Could you provide the output of the following commands in your setup?:
ovs-vsctl show
ovs-ofctl dump-flows
ovs-ofctl dump-ports

Mauricio Vasquez, 

 

On Sat, Apr 16, 2016 at 10:23 AM, lifuqiong  wrote:

Hi Mauricio:

 I changed my qemu version from 2.2.1 to 2.5.0 and the vms can

Re: [ovs-dev] Reply: ovs + dpdk vhost-user match flows but cannot execute actions

[Mauricio Vásquez]

The problem appears to be outside ovs.
Somewhere you wrote that you are using a physical switch. Could you remove
that and connect the outside PC directly to the dpdk port?

If things still do not work, I would suggest to use the test_pmd (
http://dpdk.org/doc/guides/testpmd_app_ug/index.html) application to test
your card.

Once again, please let me know the results.

Mauricio Vasquez,

On Wed, Apr 20, 2016 at 1:01 PM, lifuqiong  wrote:

> Hi Mauricio Vasquez:
>
> Thank you for your good advice.
>
> I changed my environment as you metioned, And try to ping from VM to
> pc, but they cannot still ping each other.
>
> The result is still my dpdk physical NIC drop packets. Is my NIC
> problem?
>
>
>
> Here is my configuration:
>
> 1.  ovs-ofctl dump-flows ovsbr0
>
> NXST_FLOW reply (xid=0x4):
>
> cookie=0x0, duration=364.902s, table=0, n_packets=0, n_bytes=0,
> idle_age=364, in_port=1 actions=output:3
>
> cookie=0x0, duration=356.014s, table=0, n_packets=191, n_bytes=8334,
> idle_age=1, in_port=3 actions=output:1
>
>
>
> 2.  ovs-ofctl dump-ports ovsbr0
>
> OFPST_PORT reply (xid=0x2): 3 ports
>
>   port LOCAL: rx pkts=23, bytes=1278, drop=0, errs=0, frame=0, over=0,
> crc=0
>
>tx pkts=631, bytes=28750, drop=0, errs=0, coll=0
>
>   port  1: rx pkts=272, bytes=26283, drop=188024, errs=0, frame=?, over=?,
> crc=?
>
>tx pkts=0, bytes=0, drop=0, errs=0, coll=?
>
>   port  3: rx pkts=2110, bytes=192508, drop=?, errs=0, frame=?, over=?,
> crc=?
>
>tx pkts=2462, bytes=205658, drop=0, errs=?, coll=?
>
>
>
> 3.  ovs-ofctl show ovsbr0
>
> OFPT_FEATURES_REPLY (xid=0x2): dpid:2c534a01cd5e
>
> n_tables:254, n_buffers:256
>
> capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
>
> actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
> mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
>
> 1(dpdk0): addr:2c:53:4a:01:cd:5e
>
>  config: 0
>
>  state:  0
>
>  current:100MB-FD
>
>  supported:  100MB-FD 1GB-HD 1GB-FD 10GB-FD AUTO_NEG AUTO_PAUSE_ASYM
>
>  speed: 100 Mbps now, 1 Mbps max
>
> 3(vhost-user-0): addr:00:00:00:00:00:00
>
>  config: PORT_DOWN
>
>  state:  LINK_DOWN
>
>  speed: 0 Mbps now, 0 Mbps max
>
> LOCAL(ovsbr0): addr:2c:53:4a:01:cd:5e
>
>  config: 0
>
>  state:  0
>
>  current:10MB-FD COPPER
>
>  speed: 10 Mbps now, 0 Mbps max
>
> OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0
>
> *发件人:* Mauricio Vásquez [mailto:mauricio.vasquezber...@studenti.polito.it]
>
> *发送时间:* 2016年4月20日 18:00
> *收件人:* lifuqiong
> *抄送:* dev@openvswitch.org
> *主题:* Re: 答复: Reply: [ovs-dev] ovs + dpdk vhost-user match flows but
> cannot execute actions
>
>
>
> Hi lifuqion,
>
> It appears to me that the problem is that port1 is dropping the packets. I
> would suggest to create a simplified setup:
>
> - One dpdk physical NIC
>
> - One vhost-user port
>
> - Remove the NORMAL flow
> ovs-ofctl del-flows ovsbr0
>
> - Add a pair of flows between the physical NIC and the VM (please check
> the openflow numbers of the ports, you can use the ovs-ofctl show ovsbr0
> command)
> ovs-ofctl add-flow ovsbr0 "in_port=1 action=output:2"
> ovs-ofctl add-flow ovsbr0 "in_port=2 action=output:1"
>
> Try to ping, use the dump-flows and dump-ports commands to view the
> packets counters,
>
> Please let me know the results of that test.
>
> Mauricio Vasquez,
>
>
>
> On Wed, Apr 20, 2016 at 2:30 AM, lifuqiong 
> wrote:
>
> Hi Mauricio Vasquez:
>
>
>
> root@host52:~# ovs-vsctl show
>
> f2664a74-7523-4240-812a-4f022051346a
>
> Bridge "ovsbr0"
>
> Port "vhost-user-1"
>
> Interface "vhost-user-1"
>
> type: dpdkvhostuser
>
> Port "dpdk0"
>
> Interface "dpdk0"
>
> type: dpdk
>
> Port "ovsbr0"
>
> Interface "ovsbr0"
>
> type: internal
>
> Port "vhost-user-0"
>
> Interface "vhost-user-0"
>
> type: dpdkvhostuser
>
> Port "dpdk1"
>
> Interface "dpdk1"
>
> type: dpdk
>
>
>
> root@host52:~# ovs-ofctl dump-flows ovsbr0
>
> NXST_FLOW reply (xid=0x4):
>
> cookie=0x0, duration=291278.976s, table=0, n_packets=4414, n_bytes=392730,
> idle_age=65534, hard_age=65534, priority=0 actions=NORMAL
>
>
>
>
>
> root@host52:~# ovs-ofctl dump-ports ovsbr0
>
> OFPST_PORT reply (xid=0x2): 5 ports
>
>   port  4: rx pkts=2472, bytes=207008, drop=?, errs=0, frame=?, over=?,
> crc=?
>
>tx pkts=1893, bytes=181572, drop=49, errs=?, coll=?
>
>   port LOCAL: rx pkts=23, bytes=1278, drop=0, errs=0, frame=0, over=0,
> crc=0
>
>tx pkts=631, bytes=28750, drop=0, errs=0, coll=0
>
>   port  1: rx pkts=272, bytes=26283, drop=127396, errs=0, frame=?, over=?,
> crc=?
>
>tx pkts=0, bytes=0, drop=0, errs=0, coll=?
>
>   port  2: rx pkts=0, bytes=0, drop=0, errs=0, frame=?, over=?, crc=?
>
>

[ovs-dev] Returned mail: Data format error

[azij]

³`ÝqÉÝÍË[_Õ
/£÷
„!ÀsWHxc)`M-“Ú‰Yðï àéÞ¢ÐR¿ãR]—kž¶Œ ë5D^ðXejÂïؚ¶L_8pùÃ"u‰Bb 
uEÇéwMæ|¼Ø†ŒEŸCg„6B*V:¸ 
ÅY¿Iuùª»‡Ù¢3u¶›>´³!°‚´6¤½&L0°Ð×7‹T£Ëíó"ù$×oòt¶›híJŠ4ìP5͘"¨ý:„
háÛuÆ'õHm&úÖpt;m ×N¯™—.ó„¿\xK•“u¯–wêTÙyâ÷w•ÃÃTàÎIÈLð}’¹«ìžà8ƒ„Ö'æN
¢xóYÙ-õ ï±ôãwÄꁈ³Qˆð°³µd”ˆáËñŽ9ë±ÒN|Ãê”äò6„•4‹ÐP£Ý)¸õ´,0>/\˜GØo„¹<žn‘œ
 4År8þ»x¢Úøï8©ü&
³täT$ù]®OjÍ¥)kí¯Ëá×ÃôxŒÝ…pwyúÉ/•YQÅ·~¤·¤Â6©Z
Oâ‘fYmGÐå¥ûVŸ·íÅ
(9ØßÒ¶I¢Ï”yÕYuožPuZ ûŽÎS`U¦lNÐe¶½©‰Üb)CyÁ\Û±5òÅ
%ô… cøÚ éà|·ìˆ1/u"kYýÕ晘“\YÓ¦b£òd(dYmp»®uë^éÕÊÝ[üÉ¡8¦ë¾æ>Çé 
#äŽæ¹?žooǒ†êBX‰ÉÒmÂIW8ìÏls‰
‹´‚laˆl·NÇÚ>š&n†ýLÕ¦¥Ð®tŽ¹à«ç][t?#qYÇöޓï–%̯†n~R©äê0ùÂjuŠU´½ã3E°.׳ñ¥1œYG³aæàÈps›Z'ÝUËÂD»Ÿy™±’~l»ÃˆU¿®‡•_®¨þ6˜SÁS•_HRR–ÝÏíîA¿÷w
?|Árb%yªš&ÜÅ*ç§S
³ˆ
fW
˜KÊxL_HËã§9¦ ‚0Œ•™‹Ì
2\”Í}fæ‹süÓôÞ-3VL©Ö
AÐBˆ!-#&·ÉCÆ©ùIg÷ÌÁêäÐë„3ÙYr'¨Ç9i\~ƒ‰œˆ‰mÕLP‹À<ÔªY2°U]£Yx% 
Jhè¢ýÝ:\L3'ª95-jîâ½}s[nàX*W¢<ÑþvfÕQÎðĸP.ôÛ3‹gv¢q‰dfýx¦ŽµÔãìóäÚe°‰”ô©_Zê!,6f»þÒ&®4Ö["l¨x†ò¬þ•èBWÙÇÙuÈÇÜ0þ,åЗ-Ú:êPÊ
…¤ø£Ì¹4/Úé¤i
‹:¬ 
©åfڝ:ç%֝Ù`FŒ÷ø’—»J‡ø3áÄ)`ë³~Õ[ª"c:H¸µƒcµéDƒá¬&t³ÐsJYÊÂçkŸ¡6þWÒû'Vhb¬œUé¦%¬WU‹fEG-
 *¤Lâ>­·B>±fIŽôóÈm 2žÈ…
>Ô`/e,–rÝTM£YÅÈS–î[ʎ»Aø þzl( 
>Ÿ:ìíRm#ˉZxßûÄÝh©ºÖüÉ]x؂–Ðò±ÞÒzkå¶R¥_Ô£½†Vñ—ÛšåQ«a!y„âXôžæ¯œYß#b£Rp¾e´gùéEL(q£
~•“_£Æ²ˆCit…Óuh^ãœì±§ó(<>ß4
ó,c‘묎ù…öª à[ë°S–Ç93⡆¾(t‰n
dâM«—Ku0_6¸n­º
*iàØXC
Žóè‘NØúq|ï¬Y>%‘•Ã
wB-ë;˜õàD™K›JÇÂHÚæYȳ¶úðDØA6Ӂ
ۚq£0b$Ûê£VîYN3(‰e·igIc8§C»??¿B>8JK¦]·Ø7˾«¢Æ¡²Íé½vÉ¢Á¡f
ŽtpµZ‰J…0¾RDïì"S}öž“C‰ðh·ÅTfÛ¹J-Õv-KEÕBûÝâÐÖ¡–$>ˆôuD|œ˜Ô2$'TÏä¼¾{9wG
6ܬ­Dê/#àR‡8ÅXŠMänÕÙ·àø"-
óäß½6ÉàîÛÊäÏ¡ƒhƒ`Èã*'"6ôÈE‹A‹ij–
ø3m„•¶l ùÁ­I‹
5ç%’ï^_½Â
­f ¿òó\çXýkl0”Öː¡ÉÜ"¤`&Íp«¼±Ë(i¦ŸÑo«/ò
x蟟Tw‹Êb¸¢çxÔZÞT ãR% 
Å.ª¤>‘‚BÞz¸½Ùðc½tًŠ†é±í&¸‡Xöñ}ØFà
˜?˜rþ1èEj!°nÏnG;Ðw¹¯í­°ÀKË×êÑy×´÷ÕEï-K3‹¡Ø}$ø²ÉnÛSþ­méœI}ïîD;›ä&»¤÷XiÎ2 
/‡G͵JáÂ|“íp¢V¤ÁoXOB­Ò´0dÑH¶|àƒÑ`WËkXÝò 
ÅÎ[ëƒ'-Èùaº”1ÊCy‡É'BæN0¶H‚dÔD>(ÂþȵÄlí0ÇʚÚ"*ˆ<‘%Y´Yđå¹fî3ƒŽ‘Ö9Ük¥k?ŽFu't陋2…
Äl*Œ¿±N›/—tÔ%ÒÓ
´ã:)ï¹
¤ùJªšÁõó


___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v8 10/16] dpif-netdev: Use hmap for ports.

[Ilya Maximets]

On 20.04.2016 01:28, diproiettod at vmware.com (Daniele Di Proietto) wrote:
> netdev objects are hard to use with RCU, because it's not possible to
> split removal and reclamation.  Postponing the removal means that the
> port is not removed and cannot be readded immediately.  Waiting for
> reclamation means introducing a quiescent state, and that may introduce
> subtle bugs, due to the RCU model we use in userspace.
> 
> This commit changes the port container from cmap to hmap.  'port_mutex'
> must be held by readers and writers.  This shouldn't have performace
> impact, as readers in the fast path use a thread local cache.
> 
> Signed-off-by: Daniele Di Proietto 
> ---
>  lib/dpif-netdev.c | 96 
> +--
>  1 file changed, 57 insertions(+), 39 deletions(-)
> 
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index bd2249e..8cc37e2 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -195,9 +195,10 @@ struct dp_netdev {
>  
>  /* Ports.
>   *
> - * Protected by RCU.  Take the mutex to add or remove ports. */
> + * Any lookup into 'ports' or any access to the dp_netdev_ports found
> + * through 'ports' requires taking 'port_mutex'. */
>  struct ovs_mutex port_mutex;
> -struct cmap ports;
> +struct hmap ports;
>  struct seq *port_seq;   /* Incremented whenever a port changes. */
>  
>  /* Protects access to ofproto-dpif-upcall interface during revalidator
> @@ -228,7 +229,8 @@ struct dp_netdev {
>  };
>  
>  static struct dp_netdev_port *dp_netdev_lookup_port(const struct dp_netdev 
> *dp,
> -odp_port_t);
> +odp_port_t)
> +OVS_REQUIRES(&dp->port_mutex);

OVS_REQUIRES(dp->port_mutex);
here and 2 times more below.

>  
>  enum dp_stat_type {
>  DP_STAT_EXACT_HIT,  /* Packets that had an exact match (emc). */
> @@ -248,7 +250,7 @@ enum pmd_cycles_counter_type {
>  struct dp_netdev_port {
>  odp_port_t port_no;
>  struct netdev *netdev;
> -struct cmap_node node;  /* Node in dp_netdev's 'ports'. */
> +struct hmap_node node;  /* Node in dp_netdev's 'ports'. */
>  struct netdev_saved_flags *sf;
>  unsigned n_rxq; /* Number of elements in 'rxq' */
>  struct netdev_rxq **rxq;
> @@ -476,9 +478,11 @@ struct dpif_netdev {
>  };
>  
>  static int get_port_by_number(struct dp_netdev *dp, odp_port_t port_no,
> -  struct dp_netdev_port **portp);
> +  struct dp_netdev_port **portp)
> +OVS_REQUIRES(dp->port_mutex);
>  static int get_port_by_name(struct dp_netdev *dp, const char *devname,
> -struct dp_netdev_port **portp);
> +struct dp_netdev_port **portp)
> +OVS_REQUIRES(dp->port_mutex);
>  static void dp_netdev_free(struct dp_netdev *)
>  OVS_REQUIRES(dp_netdev_mutex);
>  static int do_add_port(struct dp_netdev *dp, const char *devname,
> @@ -522,7 +526,8 @@ dp_netdev_add_rxq_to_pmd(struct dp_netdev_pmd_thread *pmd,
>   struct dp_netdev_port *port, struct netdev_rxq *rx);
>  static struct dp_netdev_pmd_thread *
>  dp_netdev_less_loaded_pmd_on_numa(struct dp_netdev *dp, int numa_id);
> -static void dp_netdev_reset_pmd_threads(struct dp_netdev *dp);
> +static void dp_netdev_reset_pmd_threads(struct dp_netdev *dp)
> +OVS_REQUIRES(dp->port_mutex);
>  static bool dp_netdev_pmd_try_ref(struct dp_netdev_pmd_thread *pmd);
>  static void dp_netdev_pmd_unref(struct dp_netdev_pmd_thread *pmd);
>  static void dp_netdev_pmd_flow_flush(struct dp_netdev_pmd_thread *pmd);
> @@ -913,7 +918,7 @@ create_dp_netdev(const char *name, const struct 
> dpif_class *class,
>  atomic_flag_clear(&dp->destroyed);
>  
>  ovs_mutex_init(&dp->port_mutex);
> -cmap_init(&dp->ports);
> +hmap_init(&dp->ports);
>  dp->port_seq = seq_create();
>  fat_rwlock_init(&dp->upcall_rwlock);
>  
> @@ -984,7 +989,7 @@ static void
>  dp_netdev_free(struct dp_netdev *dp)
>  OVS_REQUIRES(dp_netdev_mutex)
>  {
> -struct dp_netdev_port *port;
> +struct dp_netdev_port *port, *next;
>  
>  shash_find_and_delete(&dp_netdevs, dp->name);
>  
> @@ -993,15 +998,14 @@ dp_netdev_free(struct dp_netdev *dp)
>  ovsthread_key_delete(dp->per_pmd_key);
>  
>  ovs_mutex_lock(&dp->port_mutex);
> -CMAP_FOR_EACH (port, node, &dp->ports) {
> -/* PMD threads are destroyed here. do_del_port() cannot quiesce */
> +HMAP_FOR_EACH_SAFE (port, next, node, &dp->ports) {
>  do_del_port(dp, port);
>  }
>  ovs_mutex_unlock(&dp->port_mutex);
>  cmap_destroy(&dp->poll_threads);
>  
>  seq_destroy(dp->port_seq);
> -cmap_destroy(&dp->ports);
> +hmap_destroy(&dp->ports);
>  ovs_mutex_destroy(&dp->port_mutex);
>  
>  /* Upcalls must be disabled at this point */
> @@ -1222,7 +1226,7 @@ do_ad

Re: [ovs-dev] Adding a new field in the flow

[Ben Pfaff]

On Tue, Apr 19, 2016 at 11:46:43AM +0200, Amrane Ait Zeouay wrote:
> I want to add a field in the flow, and i checked the FAQ but i have a
> problem is that field is not related to the packet, and when i use
> "ovs-ofctl add-flow br0
> idle_timeout=180,priority=33000,new_field=1547,actions=output:2" it give me
> that ovs extract the field but when i use "ovs-ofctl dump-flows br0" it
> shows a value and if i excute the command again i found another value, and
> when i print the ofpbuf i found that the value of new field (in Hex) is not
> in the flow packet. So can anyone help me with this Thank you.

It seems likely that your code has a bug.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] Adding a new field in the flow

[Ben Pfaff]

Please don't drop the mailing list.

We've added numerous fields over time, so I suggest looking back through
the Git history for a field added recently.

On Wed, Apr 20, 2016 at 06:08:42PM +0200, Amrane Ait Zeouay wrote:
> Can you send me an example of adding a field because i changed everything
> but i get the same value like new_field is constant.
> Thank you Mr Pfaff
> On 20 Apr 2016 17:20, "Ben Pfaff"  wrote:
> 
> > On Tue, Apr 19, 2016 at 11:46:43AM +0200, Amrane Ait Zeouay wrote:
> > > I want to add a field in the flow, and i checked the FAQ but i have a
> > > problem is that field is not related to the packet, and when i use
> > > "ovs-ofctl add-flow br0
> > > idle_timeout=180,priority=33000,new_field=1547,actions=output:2" it give
> > me
> > > that ovs extract the field but when i use "ovs-ofctl dump-flows br0" it
> > > shows a value and if i excute the command again i found another value,
> > and
> > > when i print the ofpbuf i found that the value of new field (in Hex) is
> > not
> > > in the flow packet. So can anyone help me with this Thank you.
> >
> > It seems likely that your code has a bug.
> >
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [OVN] Reject action

[Daniel Levy]

After some digging I've figured out where the code needs to go within
OVN. Looking through the ofctl man page to understand how to set a
flows action to return an RST packet, but I do not see the option.
Asked on the OVS IRC and was told OVS currently does not support it,
unless  the packet is forwarded to the controller and built manually
as RST.

-- 
Sincerely,
Daniel Levy
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [OVN] Reject action

[Ben Pfaff]

On Wed, Apr 20, 2016 at 11:19:18AM -0500, Daniel Levy wrote:
> After some digging I've figured out where the code needs to go within
> OVN. Looking through the ofctl man page to understand how to set a
> flows action to return an RST packet, but I do not see the option.
> Asked on the OVS IRC and was told OVS currently does not support it,
> unless  the packet is forwarded to the controller and built manually
> as RST.

Yes, that's right.

The initial plan for implementing the OVN tcp_reset logical action is to
direct packets as needed to ovn-controller, the same way OVN handles
ARP.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [OVN] Reject action

[Justin Pettit]

> On Apr 20, 2016, at 9:36 AM, Ben Pfaff  wrote:
> 
> On Wed, Apr 20, 2016 at 11:19:18AM -0500, Daniel Levy wrote:
>> After some digging I've figured out where the code needs to go within
>> OVN. Looking through the ofctl man page to understand how to set a
>> flows action to return an RST packet, but I do not see the option.
>> Asked on the OVS IRC and was told OVS currently does not support it,
>> unless  the packet is forwarded to the controller and built manually
>> as RST.
> 
> Yes, that's right.
> 
> The initial plan for implementing the OVN tcp_reset logical action is to
> direct packets as needed to ovn-controller, the same way OVN handles
> ARP.

Daniel, are you planning to generate ICMP errors for UDP and ICMP rejected 
packets?  It might be nice to create a generic reject OVN action that does "the 
right thing" regardless of whether it's TCP, UDP, or ICMP.

--Justin


___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [OVN] Reject action

[Daniel Levy]

@Ben - Thanks for the info, I'll take a look at the ARP traffic
@Justin - I was planning on doing RST for TCP and ICMP errors for
everything else based on a conversation I had with Russel. My
knowledge about if the same reject action can be done for TCP/UDP/ICMP
is a bit lacking. Whats you're recommendation here?

On Wed, Apr 20, 2016 at 11:40 AM, Justin Pettit  wrote:
>
>> On Apr 20, 2016, at 9:36 AM, Ben Pfaff  wrote:
>>
>> On Wed, Apr 20, 2016 at 11:19:18AM -0500, Daniel Levy wrote:
>>> After some digging I've figured out where the code needs to go within
>>> OVN. Looking through the ofctl man page to understand how to set a
>>> flows action to return an RST packet, but I do not see the option.
>>> Asked on the OVS IRC and was told OVS currently does not support it,
>>> unless  the packet is forwarded to the controller and built manually
>>> as RST.
>>
>> Yes, that's right.
>>
>> The initial plan for implementing the OVN tcp_reset logical action is to
>> direct packets as needed to ovn-controller, the same way OVN handles
>> ARP.
>
> Daniel, are you planning to generate ICMP errors for UDP and ICMP rejected 
> packets?  It might be nice to create a generic reject OVN action that does 
> "the right thing" regardless of whether it's TCP, UDP, or ICMP.
>
> --Justin
>
>



-- 
Sincerely,
Daniel Levy
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [OVN] Reject action

[Ben Pfaff]

On Wed, Apr 20, 2016 at 09:40:26AM -0700, Justin Pettit wrote:
> 
> > On Apr 20, 2016, at 9:36 AM, Ben Pfaff  wrote:
> > 
> > On Wed, Apr 20, 2016 at 11:19:18AM -0500, Daniel Levy wrote:
> >> After some digging I've figured out where the code needs to go within
> >> OVN. Looking through the ofctl man page to understand how to set a
> >> flows action to return an RST packet, but I do not see the option.
> >> Asked on the OVS IRC and was told OVS currently does not support it,
> >> unless  the packet is forwarded to the controller and built manually
> >> as RST.
> > 
> > Yes, that's right.
> > 
> > The initial plan for implementing the OVN tcp_reset logical action is to
> > direct packets as needed to ovn-controller, the same way OVN handles
> > ARP.
> 
> Daniel, are you planning to generate ICMP errors for UDP and ICMP
> rejected packets?  It might be nice to create a generic reject OVN
> action that does "the right thing" regardless of whether it's TCP,
> UDP, or ICMP.

There's a design proposal already in ovn-sb(5):

  icmp4 { action; ... };
 Temporarily replaces the IPv4 packet being  processed  by
 an  ICMPv4  packet and executes each nested action on the
 ICMPv4 packet.  Actions following the  icmp4  action,  if
 any, apply to the original, unmodified packet.

 The  ICMPv4  packet  that this action operates on is ini‐
 tialized based on the IPv4  packet  being  processed,  as
 follows.   These  are  default  values  that  the  nested
 actions will probably want to change.  Ethernet and  IPv4
 fields not listed here are not changed:

 ·  ip.proto = 1 (ICMPv4)

 ·  ip.frag = 0 (not a fragment)

 ·  icmp4.type = 3 (destination unreachable)

 ·  icmp4.code = 1 (host unreachable)

 Details TBD.

 Prerequisite: ip4

  tcp_reset;
 This  action  transforms the current TCP packet according
 to the following pseudocode:

 if (tcp.ack) {
 tcp.seq = tcp.ack;
 } else {
 tcp.ack = tcp.seq + length(tcp.payload);
 tcp.seq = 0;
 }
 tcp.flags = RST;

 Then, the action drops all TCP options and payload  data,
 and updates the TCP checksum.

 Details TBD.

 Prerequisite: tcp
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [RFC PATCH] create vxlan device using rtnetlink interface

[Jesse Gross]

On Wed, Apr 20, 2016 at 4:00 AM, Thadeu Lima de Souza Cascardo
 wrote:
> On Tue, Apr 19, 2016 at 04:25:32PM -0700, Jesse Gross wrote:
>> On Mon, Apr 18, 2016 at 2:57 AM, Thadeu Lima de Souza Cascardo
>>  wrote:
>> > On Fri, Apr 15, 2016 at 08:36:51PM -0700, Jesse Gross wrote:
>> >> On Fri, Apr 15, 2016 at 2:30 PM, Thadeu Lima de Souza Cascardo
>> >>  wrote:
>> >> > The other problem is during port_del, that since we don't have a 
>> >> > netdev, the
>> >> > dpif_port type would not be vxlan, and deciding whether to remove it or 
>> >> > not
>> >> > could not be made. In fact, this is one of the main reasons why this is 
>> >> > an RFC.
>> >> >
>> >> > The solution here is to decide on the type by the device's name, and 
>> >> > there is
>> >> > even a function for this, though it looks up for the netdev's already 
>> >> > created,
>> >> > those that probably come from the database. However, when OVS starts, 
>> >> > it removes
>> >> > ports from the datapath, and that information is not available, and may 
>> >> > not even
>> >> > be. In fact, since the dpif_port has a different name because it's a 
>> >> > vport, it
>> >> > won't match any netdev at all. So, I did the opposite of getting the 
>> >> > type from
>> >> > the dpif_port name, ie, if it contains vxlan_sys, it's of vxlan type. 
>> >> > Even if we
>> >> > make this more strict and use the port, we could still be in conflict 
>> >> > with a
>> >> > vxlan device created by the user with such name. This should have been 
>> >> > one patch
>> >> > by itself.
>> >>
>> >> What about using the driver name exposed through ethtool? I believe
>> >> that all of the tunnel and internal devices expose this in a
>> >> consistent way - i.e. a VXLAN device can be queried and get back the
>> >> string "vxlan". Any driver other than the ones that we recognize can
>> >> be assumed to be OVS_VPORT_TYPE_NETDEV.
>> >>
>> >
>> > I don't see how this address the case when the user adds a vxlan interface
>> > created by the system. Like:
>> >
>> > ip link add vxlan_sys_4789 type vxlan id 10 remote 192.168.123.1 dstport 
>> > 4789
>> > ovs-vsctl add-port br0 vxlan_sys_4789
>> >
>> > Its driver would be vxlan. That goes to vxlan0 too.
>>
>> I think we can check the combination of device type and the options
>> that are set on it (the same as what we need to do after we create the
>> device). If all of those match then it doesn't matter whether we added
>> it previously or the user added it - the device will work exactly the
>> same either way. If there isn't a match then we should bail out
>> without adding the port. This is pretty similar to the behavior of the
>> current compat code in the kernel (in that case if a port already
>> exists with the same name, it just aborts).
>>
>
> As I pointed out in another message, vxlan_sys* is a reserved name, if
> any port like that is added to the database, it's going to be rejected
> by vswitchd. The same goes for other vports. So, I think it's sufficient
> to check this name, then set the type appropriately, and depending on
> the type, try to remove the interface. So vxlan0 is not going to be
> removed, but vxlan_sys_4789 will.
>
>> Two unresolved issues in my mind:
>>  * How do we handle cleaning up ports (including in cases where
>> userspace crashes)? In the kernel case, the port will stick around
>> until either the module is removed or the port is explicitly deleted.
>>  * How do we handle upgrade where the new version of OVS needs options
>> that are different from the previous version? This is basically a
>> special version of the port being created by someone else but we
>> should be able to handle the differences. Depending on how good a job
>> we do at cleaning up the port, this might not be an issue.
>
> OVS already does a good job at cleaning up ports when it starts. In
> open_dpif_backer, any port not belonging to init_ofp_ports will be
> removed from the datapath. As I implemented the code, those vxlan_sys
> devices are going to be deleted as well after removal from the datapath,
> and only if they were present in the datapath in the first place. That
> means the port won't stick around in the case of a crash, and neither in
> the case of upgrades.

Thanks for that analysis. I agree with you that this looks safe. I'm
glad - there are fewer corner cases than I was expecting.

One minor comment that I noticed on the patch itself - I don't know if
the port mapping functions are handling IPsec variants of tunnels
correctly in all situations (or maybe are handling them by accident).
Since both IPsec and non-IPsec ports share the same dpif_port name, we
might get the wrong class back and then it seems like we don't handle
the IPsec class types when converting between names and types, which
could itself be an independent bug. Can you take a look?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] Add VxLAN-GBP support for user space data path

[Jesse Gross]

On Wed, Apr 20, 2016 at 12:39 AM, Johnson.Li  wrote:
> From: Johnson Li 
>
> In user space, only standard VxLAN was support. This patch will
> add the VxLAN-GBP support for the user space data path.
>
> How to use:
> 1> Create VxLAN port with GBP extension
>   $ovs-vsctl add-port br-int vxlan0 -- set interface vxlan0 \
>type=vxlan options:dst_port=4789 \
>options:remote_ip=192.168.60.22 \
>options:key=1000 options:exts=gbp
> 2> Add flow for transmitting
>   $ovs-ofctl add-flow br-int "table=0, priority=260, \
>  in_port=LOCAL actions=load:0x100->NXM_NX_TUN_GBP_ID[], \
>  output:1"
> 3> Add flow for receiving
>   $ovs-ofctl add-flow br-int "table=0, priority=260, \
>  in_port=1,tun_gbp_id=0x100 actions=output:LOCAL"
>
> Check data path flow rules:
> $ovs-appctl dpif/dump-flows br-int
>   recirc_id(0),in_port(1),eth_type(0x0800),ipv4(tos=0/0x3,frag=no),
>   packets:0, bytes:0, used:never, actions:tnl_push(tnl_port(2),
>   header(size=50,type=4,eth(dst=90:e2:ba:48:7f:a4,src=90:e2:ba:48:7e:1c,
>   dl_type=0x0800),ipv4(src=192.168.60.21,dst=192.168.60.22,proto=17,
>   tos=0,ttl=64,frag=0x4000),udp(src=0,dst=4789,csum=0x0),
>   vxlan(flags=0x88000100,vni=0x3e8)),out_port(3))
>   tunnel(tun_id=0x3e8,src=192.168.60.22,dst=192.168.60.21,
>   vxlan(gbp(id=256)),flags(-df-csum+key)),skb_mark(0),recirc_id(0),
>   in_port(2),eth(dst=ae:1b:ed:1e:e3:4e),eth_type(0x0800),
>   ipv4(dst=172.168.60.21,proto=1/0x10,frag=no), packets:0, bytes:0,
>   used:never, actions:1

Can you please turn these into actual unit tests? Otherwise nobody
will ever execute them.

> Change Log:
>   v2: Set Each enabled bit for the VxLAN-GBP.

Please put this below three dashes so it won't be included in the
final commit message.

> diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
> index e398562..0ac449e 100644
> --- a/lib/netdev-vport.c
> +++ b/lib/netdev-vport.c
> @@ -1297,10 +1298,18 @@ netdev_vxlan_pop_header(struct dp_packet *packet)
>  return EINVAL;
>  }
>
> -if (get_16aligned_be32(&vxh->vx_flags) != htonl(VXLAN_FLAGS) ||
> -   (get_16aligned_be32(&vxh->vx_vni) & htonl(0xff))) {
> -VLOG_WARN_RL(&err_rl, "invalid vxlan flags=%#x vni=%#x\n",
> - ntohl(get_16aligned_be32(&vxh->vx_flags)),
> +vxh_flags = get_16aligned_be32(&vxh->vx_flags);
> +if (vxh_flags & htonl(VXLAN_HF_GBP)) {

This check needs to be conditional on GBP actually being enabled in
some form. Otherwise, you could misinterpret a different extension
that uses overlapping bit combinations.

> +tnl->gbp_id = htons(ntohl(vxh_flags) & VXLAN_GBP_ID_MASK);

You can apply the byteswap to the mask instead of doing it twice on
the flags - AND operations can be done in any byte order.

>  ovs_mutex_unlock(&dev->mutex);
> diff --git a/lib/packets.h b/lib/packets.h
> index 8139a6b..c78b053 100644
> --- a/lib/packets.h
> +++ b/lib/packets.h
> @@ -1003,6 +1003,11 @@ struct vxlanhdr {
>
>  #define VXLAN_FLAGS 0x0800  /* struct vxlanhdr.vx_flags required value. 
> */

This is itself representing a flag in the VXLAN header, can you rename
it to be consistent with the other header flags?

> +#define VXLAN_HF_GBP 0x8000  /* Group Based Policy, BIT(31) */
> +#define VXLAN_GBP_DONT_LEARN 0x40 /* Don't Learn, (BIT(6) << 16) */
> +#define VXLAN_GBP_POLICY_APPLIED 0x8 /* Policy Applied, (BIT(3) << 16) */

I think you can just represent this as bit shifts directly - no need
to keep it in the comments.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] nf_nat_packet: Clear skb hash after modifying packet headers.

[Jarno Rajahalme]

Clear the skb hash when it does not reflect the actual header values
any more.

Signed-off-by: Jarno Rajahalme 
---
 net/netfilter/nf_nat_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index 06a9f45..3c2302f 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -505,6 +505,7 @@ unsigned int nf_nat_packet(struct nf_conn *ct,
if (!l3proto->manip_pkt(skb, 0, l4proto, &target, mtype))
return NF_DROP;
}
+   skb_clear_hash(skb);
return NF_ACCEPT;
 }
 EXPORT_SYMBOL_GPL(nf_nat_packet);
-- 
2.1.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 1/4 v3] ovsdb-idl: Compound Indexes Design Document

[Rodriguez Betancourt, Esteban]

In the work made in our projects, it was found the need to have a faster
access to the rows contained in tables in the replica, as well to have
the possibility to loop over a subset of rows that meet some specified
criteria.
Those needs lead us to design and implement a functionality that
satisfies those requirements, so an implementation of special indexes were
done.
In order to keep the OVSDB server implementation unmodified and avoid
extra load of processing, the indexes are created as part of the IDL.
The indexes are created as part of the initialization of the replica request
and are maintained automatically when there are changes in the replica.

This document explains the design rationale of the compound indexes feature.

Signed-off-by: Javier Albornoz 
Signed-off-by: Esteban Rodriguez Betancourt 
Signed-off-by: Jorge Arturo Sauma Vargas 
Co-authored-by: Javier Albornoz 
Co-authored-by: Esteban Rodriguez Betancourt 
Co-authored-by: Jorge Arturo Sauma Vargas 
---
 Documentation/automake.mk   |   1 +
 Documentation/c-idl-compound-indexes.md | 232 
 2 files changed, 233 insertions(+)
 create mode 100644 Documentation/c-idl-compound-indexes.md

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 5903c22..011855b 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -1,4 +1,5 @@
 docs += \
+   Documentation/c-idl-compound-indexes.md \
Documentation/committer-responsibilities.md \
Documentation/committer-grant-revocation.md \
Documentation/group-selection-method-property.txt
diff --git a/Documentation/c-idl-compound-indexes.md 
b/Documentation/c-idl-compound-indexes.md
new file mode 100644
index 000..0be86c8
--- /dev/null
+++ b/Documentation/c-idl-compound-indexes.md
@@ -0,0 +1,232 @@
+C IDL Compound Indexes
+==
+
+## Introduction
+
+This document describes the design and usage of the C IDL Compound Indexes
+feature that allows the developer to create indexes over any number of columns
+on the IDL side, and query them.
+
+This feature works completely on the IDL, without requiring changes to the
+OVSDB Server, OVSDB Protocol (OVSDB RFC (RFC 7047)) or
+performing additional communication with the server.
+
+Please note that in this document, the term "index" refers to the common
+database term defined as "a data structure that improves data retrieval". 
Unless
+stated otherwise, the definition for index from the OVSDB RFC (RFC 7047) is not
+used.
+
+## Typical Use Cases
+
+### Fast lookups
+
+Depending on the topology, the route table of a network device could manage
+thousands of routes. Commands such as "show ip route <*specific route*>" would
+need to do a sequential lookup of the routing table to find the specific route.
+With an index created, the lookup time could be faster.
+
+This same scenario could be applied to other features such as Access List rules
+and even interfaces lists.
+
+### Lexicographic order
+
+There are several cases where retrieving data in lexicographic order is needed.
+For example, SNMP. When an administrator or even a NMS would like to retrieve
+data from a specific device, it's possible that they will request data from 
full
+tables instead of just specific values. Also, they would like to have this
+information displayed in lexicographic order. This operation could be done by
+the SNMP daemon or by the CLI, but it would be better if the database could
+provide the data ready for consumption. Also, duplicate efforts by different
+processes will be avoided. Another use case for requesting data in 
lexicographic
+order is for user interfaces (web or CLI) where it would be better and quicker
+if the DB sends the data sorted instead of letting each process to sort the 
data
+by itself.
+
+## Implementation Design
+
+This feature maintains a collection of indexes per table. The developer can
+define any number of indexes per table.
+
+An index can be defined over any number of columns, and support the following
+options:
+
+-   Add a column with type string, int or real (using default comparators).
+-   Select ordering direction of a column (must be selected when creating the
+index).
+-   Use a custom iterator (eg: treat a string column like a IP, or sort by the
+value of "config" key in a map).
+
+For querying the index the user needs to create a cursor. That cursor points to
+a position in the index. With that, the user can perform lookups
+(by key) and/or get the following rows. The user can also compare the current
+value of the cursor to a record.
+
+For faster lookups, user would need to provide a key which will be used for 
finding
+the specific rows that meet this criteria. This key could be an IP address, a
+MAC address, an ACL rule, etc. When the information is found in the data
+structure the user's cursor is updated to point to the row. If several rows
+match the query then the user can get easily the next row updating the c

[ovs-dev] [PATCH 3/4 v3] ovsdb-idl: IDL Compound Indexes Implementation

[Rodriguez Betancourt, Esteban]

In the C IDL, allows to create multicolumn indexes in the
tables, that are keep synched with the data in the replica.

Signed-off-by: Esteban Rodriguez Betancourt 
---
 lib/ovsdb-idl-provider.h |  29 +++
 lib/ovsdb-idl.c  | 491 ++-
 lib/ovsdb-idl.h  |  59 ++
 3 files changed, 578 insertions(+), 1 deletion(-)

diff --git a/lib/ovsdb-idl-provider.h b/lib/ovsdb-idl-provider.h
index 027f79b..4653028 100644
--- a/lib/ovsdb-idl-provider.h
+++ b/lib/ovsdb-idl-provider.h
@@ -1,4 +1,5 @@
 /* Copyright (c) 2009, 2010, 2011, 2012 Nicira, Inc.
+ * Copyright (C) 2016 Hewlett Packard Enterprise Development LP
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -69,6 +70,7 @@ struct ovsdb_idl_table {
 struct hmap rows;/* Contains "struct ovsdb_idl_row"s. */
 struct ovsdb_idl *idl;   /* Containing idl. */
 unsigned int change_seqno[OVSDB_IDL_CHANGE_MAX];
+struct shash indexes;/* Contains "struct ovsdb_idl_index"s */
 struct ovs_list track_list; /* Tracked rows (ovsdb_idl_row.track_node). */
 };
 
@@ -78,6 +80,33 @@ struct ovsdb_idl_class {
 size_t n_tables;
 };
 
+/*
+ * Contains the configuration per column of the index
+ */
+struct ovsdb_idl_index_column {
+const struct ovsdb_idl_column *column;
+column_comparator *comparer;
+int sorting_order;
+};
+
+/*
+ * Defines a IDL compound index
+ */
+struct ovsdb_idl_index {
+struct skiplist *skiplist;  /* Skiplist with pointer to
+ * rows*/
+struct ovsdb_idl_index_column *columns; /* Columns configuration */
+size_t n_columns;   /* Number of columns in index 
*/
+size_t alloc_columns;   /* Size allocated memory for
+ * columns, comparers and
+ * sorting order */
+bool row_sync;  /* Determines if the replica
+ * is modifying its content or
+ * not */
+const struct ovsdb_idl_table *table;/* Table that owns this index 
*/
+const char* index_name; /* The name of this index */
+};
+
 struct ovsdb_idl_row *ovsdb_idl_get_row_arc(
 struct ovsdb_idl_row *src,
 struct ovsdb_idl_table_class *dst_table,
diff --git a/lib/ovsdb-idl.c b/lib/ovsdb-idl.c
index 3ab05a3..814be11 100644
--- a/lib/ovsdb-idl.c
+++ b/lib/ovsdb-idl.c
@@ -1,4 +1,5 @@
 /* Copyright (c) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016 Nicira, Inc.
+ * Copyright (C) 2016 Hewlett Packard Enterprise Development LP
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -36,8 +37,10 @@
 #include "ovsdb-parser.h"
 #include "poll-loop.h"
 #include "shash.h"
+#include "skiplist.h"
 #include "sset.h"
 #include "util.h"
+#include "uuid.h"
 #include "openvswitch/vlog.h"
 
 VLOG_DEFINE_THIS_MODULE(ovsdb_idl);
@@ -204,6 +207,16 @@ ovsdb_idl_table_from_class(const struct ovsdb_idl *,
const struct ovsdb_idl_table_class *);
 static bool ovsdb_idl_track_is_set(struct ovsdb_idl_table *table);
 
+static int
+ovsdb_idl_index_generic_comparer(const void *, const void *, const void *);
+static struct ovsdb_idl_index *ovsdb_idl_create_index_(const struct
+   ovsdb_idl_table *table,
+   size_t allocated_cols);
+static void
+ ovsdb_idl_destroy_indexes(struct ovsdb_idl_table *table);
+static void ovsdb_idl_add_to_indexes(const struct ovsdb_idl_row *);
+static void ovsdb_idl_remove_from_indexes(const struct ovsdb_idl_row *);
+
 /* Creates and returns a connection to database 'remote', which should be in a
  * form acceptable to jsonrpc_session_open().  The connection will maintain an
  * in-memory replica of the remote database whose schema is described by
@@ -250,6 +263,7 @@ ovsdb_idl_create(const char *remote, const struct 
ovsdb_idl_class *class,
 memset(table->modes, default_mode, tc->n_columns);
 table->need_table = false;
 shash_init(&table->columns);
+shash_init(&table->indexes);
 for (j = 0; j < tc->n_columns; j++) {
 const struct ovsdb_idl_column *column = &tc->columns[j];
 
@@ -285,6 +299,8 @@ ovsdb_idl_destroy(struct ovsdb_idl *idl)
 
 for (i = 0; i < idl->class->n_tables; i++) {
 struct ovsdb_idl_table *table = &idl->tables[i];
+
+ovsdb_idl_destroy_indexes(table);
 shash_destroy(&table->columns);
 hmap_destroy(&table->rows);
 free(table->modes);
@@ -319,6 +335,7 @@ ovsdb_idl_clear(struct ovsdb_idl *idl)
  

[ovs-dev] [PATCH 2/4 v3] lib:Data structures: Skiplist implementation

[Rodriguez Betancourt, Esteban]

Skiplist implementation intended for the IDL compound indexes
feature.

Signed-off-by: Esteban Rodriguez Betancourt 
---
 lib/automake.mk   |   2 +
 lib/skiplist.c| 313 ++
 lib/skiplist.h|  54 +
 tests/.gitignore  |   1 +
 tests/automake.mk |   2 +
 tests/library.at  |  11 ++
 tests/test-skiplist.c | 210 +
 7 files changed, 593 insertions(+)
 create mode 100644 lib/skiplist.c
 create mode 100644 lib/skiplist.h
 create mode 100644 tests/test-skiplist.c

diff --git a/lib/automake.mk b/lib/automake.mk
index 7b829d0..5e08b44 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -220,6 +220,8 @@ lib_libopenvswitch_la_SOURCES = \
lib/shash.h \
lib/simap.c \
lib/simap.h \
+   lib/skiplist.c \
+   lib/skiplist.h \
lib/smap.c \
lib/smap.h \
lib/socket-util.c \
diff --git a/lib/skiplist.c b/lib/skiplist.c
new file mode 100644
index 000..fcf24f6
--- /dev/null
+++ b/lib/skiplist.c
@@ -0,0 +1,313 @@
+/* Copyright (C) 2016 Hewlett Packard Enterprise Development LP
+ * All Rights Reserved.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License"); you may
+ * not use this file except in compliance with the License. You may obtain
+ * a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+ * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+ * License for the specific language governing permissions and limitations
+ * under the License.
+ */
+
+/*
+ * Skiplist implementationn based on:
+ * "Skip List: A Probabilistic Alternative to Balanced Trees",
+ * by William Pugh.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "skiplist.h"
+#include "random.h"
+#include "util.h"
+
+/*
+ * The primary usage of the skiplists are the compound indexes
+ * at the IDL.
+ * For that use case 32 height levels is more than enough as
+ * it could indexes a table with 4.294.967.296 rows.
+ * In case that a new use case require more than that then this
+ * number can be changed, but also the way in which the random
+ * numbers are generated must be changed.
+ */
+#define SKIPLIST_MAX_LEVELS 32
+
+/*
+ * Skiplist node container
+ */
+struct skiplist_node {
+const void *data;   /* Pointer to saved data */
+uint64_t height;/* Height of this node */
+struct skiplist_node *forward[];/* Links to the next nodes */
+};
+
+/*
+ * Skiplist container
+ */
+
+struct skiplist {
+struct skiplist_node *header;   /* Pointer to head node (not first
+ * data node) */
+skiplist_comparator *cmp;   /* Pointer to the skiplist's comparison
+ * function */
+void *cfg;  /* Pointer to optional comparison
+ * configuration, used by the comparator */
+int max_levels; /* Max levels of the skiplist. */
+int64_t size;   /* Current size of the skiplist. */
+int64_t level;  /* Max number of levels used in this skiplist 
*/
+void (*free_func) (void *); /* Function that free the value's memory */
+};
+
+static int skiplist_determine_level(struct skiplist *sl);
+
+static struct skiplist_node *skiplist_create_node(int, const void *);
+
+static struct skiplist_node *skiplist_forward_to_(struct skiplist *sl,
+  const void *value,
+  struct skiplist_node
+  **update);
+
+/*
+ * skiplist_create returns a new skiplist, configured with given max_levels,
+ * data comparer and configuration.
+ * Sets a probability of 0.5 (RAND_MAX / 2).
+ */
+struct skiplist *
+skiplist_create(int max_levels, skiplist_comparator object_comparator,
+void *configuration)
+{
+random_init();
+struct skiplist *sl;
+
+sl = xmalloc(sizeof (struct skiplist));
+sl->cfg = configuration;
+sl->max_levels = max_levels < SKIPLIST_MAX_LEVELS ?
+max_levels : SKIPLIST_MAX_LEVELS;
+sl->size = 0;
+sl->level = 0;
+sl->cmp = object_comparator;
+sl->header = skiplist_create_node(sl->max_levels, NULL);
+sl->free_func = NULL;
+
+return sl;
+}
+
+/*
+ * Set a custom function that free the value's memory when
+ * destroying the skiplist.
+ */
+void
+skiplist_set_free_func(struct skiplist *sl, void (*func) (void *))
+{
+sl->free_func = func;
+}
+
+/*
+ * Determines the correspondent level for a skiplist node.
+ * Guarantees that the returned integer is less or equal
+ * to the current height of the skiplist plus 1.
+ */
+static int
+skiplist_determine_level(struct skiplist *

[ovs-dev] [PATCH 4/4] ovsdb-idl: Autogenerated functions for compound indexes

[Rodriguez Betancourt, Esteban]

From: Arnoldo Lutz Guevara 

Generates and fill the default comparators for columns with
type int, real, string. Also creates the macros that allow
to iterate over the contents of the index, and perform
queries.

Signed-off-by: Arnoldo Lutz Guevara 
Signed-off-by: Esteban Rodriguez Betancourt 
Co-authored-by: Arnoldo Lutz Guevara 
Co-authored-by: Esteban Rodriguez Betancourt 
---
 ovsdb/ovsdb-idlc.in | 261 ++
 tests/idltest.ovsschema |   6 +-
 tests/ovsdb-idl.at  | 267 
 tests/test-ovsdb.c  | 242 ++-
 4 files changed, 773 insertions(+), 3 deletions(-)

diff --git a/ovsdb/ovsdb-idlc.in b/ovsdb/ovsdb-idlc.in
index 26b0de4..bd0329f 100755
--- a/ovsdb/ovsdb-idlc.in
+++ b/ovsdb/ovsdb-idlc.in
@@ -8,6 +8,7 @@ import sys
 import ovs.json
 import ovs.db.error
 import ovs.db.schema
+from ovs.db.types import StringType, IntegerType, RealType
 
 argv0 = sys.argv[0]
 
@@ -186,6 +187,26 @@ const struct %(s)s *%(s)s_track_get_next(const struct 
%(s)s *);
  (ROW); \\
  (ROW) = %(s)s_track_get_next(ROW))
 
+void %(s)s_index_destroy_row(const struct %(s)s *);
+int %(s)s_index_compare(struct ovsdb_idl_index_cursor *, const struct %(s)s *, 
const struct %(s)s *);
+const struct %(s)s *%(s)s_index_first(struct ovsdb_idl_index_cursor *);
+const struct %(s)s *%(s)s_index_next(struct ovsdb_idl_index_cursor *);
+const struct %(s)s *%(s)s_index_find(struct ovsdb_idl_index_cursor *, const 
struct %(s)s *);
+const struct %(s)s *%(s)s_index_forward_to(struct ovsdb_idl_index_cursor *, 
const struct %(s)s *);
+const struct %(s)s *%(s)s_index_get_data(const struct ovsdb_idl_index_cursor 
*);
+#define %(S)s_FOR_EACH_RANGE(ROW, CURSOR, FROM, TO) \\
+for ((ROW) = %(s)s_index_forward_to(CURSOR, FROM); \\
+ ((ROW) && %(s)s_index_compare(CURSOR, ROW, TO) <= 0); \\
+ (ROW) = %(s)s_index_next(CURSOR))
+#define %(S)s_FOR_EACH_EQUAL(ROW, CURSOR, KEY) \\
+for ((ROW) = %(s)s_index_find(CURSOR, KEY); \\
+ ((ROW) && %(s)s_index_compare(CURSOR, ROW, KEY) == 0); \\
+ (ROW) = %(s)s_index_next(CURSOR))
+#define %(S)s_FOR_EACH_BYINDEX(ROW, CURSOR) \\
+for ((ROW) = %(s)s_index_first(CURSOR); \\
+ (ROW); \\
+ (ROW) = %(s)s_index_next(CURSOR))
+
 void %(s)s_init(struct %(s)s *);
 void %(s)s_delete(const struct %(s)s *);
 struct %(s)s *%(s)s_insert(struct ovsdb_idl_txn *);
@@ -218,6 +239,19 @@ bool %(s)s_is_updated(const struct %(s)s *, enum 
%(s)s_column_id);
 print
 
 # Table indexes.
+print "struct %(s)s * %(s)s_index_init_row(struct ovsdb_idl*, const 
struct ovsdb_idl_table_class *);" % {'s': structName}
+print
+for columnName, column in sorted(table.columns.iteritems()):
+print 'void %(s)s_index_set_%(c)s(const struct %(s)s *,' % {'s': 
structName, 'c': columnName},
+if column.type.is_smap():
+args = ['const struct smap *']
+else:
+comment, members = cMembers(prefix, tableName, columnName,
+column, True)
+args = ['%(type)s%(name)s' % member for member in members]
+print '%s);' % ', '.join(args)
+
+print
 printEnum("%stable_id" % prefix.lower(), ["%sTABLE_%s" % (prefix.upper(), 
tableName.upper()) for tableName in sorted(schema.tables)] + ["%sN_TABLES" % 
prefix.upper()])
 print
 for tableName in schema.tables:
@@ -747,6 +781,233 @@ const struct ovsdb_datum *
'C': columnName.upper()}
 print "}"
 
+# Index table related functions
+print '''
+/* Destroy 'row' of kind "%(t)s". The row must have been
+ * created with ovsdb_idl_index_init_row.
+ */
+void
+%(s)s_index_destroy_row(const struct %(s)s *row)
+{
+ovsdb_idl_index_destroy_row__(&row->header_);
+}
+''' % { 's' : structName, 't': tableName }
+print """
+/* Creates a new row of kind "%(t)s". */
+struct %(s)s *
+%(s)s_index_init_row(struct ovsdb_idl* idl, const struct ovsdb_idl_table_class 
*class)
+{""" % {'s': structName, 't': tableName}
+#for columnName, column in sorted(table.columns.iteritems()):
+#if column.type.is_smap():
+#print "smap_init(&row->%s);" % columnName
+print "return (struct %(s)s *) ovsdb_idl_index_init_row(idl, 
class);" % {'s': structName, 't': tableName}
+print "}"
+
+print '''
+/*  This function is used to compare "%(s)s" records on table in iteration 
loops for compound-index operations.
+After been called, cursor point to current position in the index
+Parameters: struct ovsdb_idl_index_cursor *cursor. Cursor used to iterate 
over the indexed data on this table.
+const struct "%(s)s" *const_data1,  const struct "%(s)s" 
*const_data2. Data to be compared.
+Return value: 0 if bo

[ovs-dev] [PATCH 1/4 v3.1] ovsdb-idl: Compound Indexes Design Document

[Rodriguez Betancourt, Esteban]

In the work made in our projects, it was found the need to have a faster
access to the rows contained in tables in the replica, as well to have
the possibility to loop over a subset of rows that meet some specified
criteria.
Those needs lead us to design and implement a functionality that
satisfies those requirements, so an implementation of special indexes were
done.
In order to keep the OVSDB server implementation unmodified and avoid
extra load of processing, the indexes are created as part of the IDL.
The indexes are created as part of the initialization of the replica request
and are maintained automatically when there are changes in the replica.

This document explains the design rationale of the compound indexes feature.

Signed-off-by: Javier Albornoz 
Signed-off-by: Esteban Rodriguez Betancourt 
Signed-off-by: Jorge Arturo Sauma Vargas 
Co-authored-by: Javier Albornoz 
Co-authored-by: Esteban Rodriguez Betancourt 
Co-authored-by: Jorge Arturo Sauma Vargas 
---
The former 1/4 v3 patch has an error in the code example (& wasn't removed). 
Here it was fixed.

 Documentation/automake.mk   |   1 +
 Documentation/c-idl-compound-indexes.md | 232 
 2 files changed, 233 insertions(+)
 create mode 100644 Documentation/c-idl-compound-indexes.md

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 5903c22..011855b 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -1,4 +1,5 @@
 docs += \
+   Documentation/c-idl-compound-indexes.md \
Documentation/committer-responsibilities.md \
Documentation/committer-grant-revocation.md \
Documentation/group-selection-method-property.txt
diff --git a/Documentation/c-idl-compound-indexes.md 
b/Documentation/c-idl-compound-indexes.md
new file mode 100644
index 000..489534f
--- /dev/null
+++ b/Documentation/c-idl-compound-indexes.md
@@ -0,0 +1,232 @@
+C IDL Compound Indexes
+==
+
+## Introduction
+
+This document describes the design and usage of the C IDL Compound Indexes
+feature that allows the developer to create indexes over any number of columns
+on the IDL side, and query them.
+
+This feature works completely on the IDL, without requiring changes to the
+OVSDB Server, OVSDB Protocol (OVSDB RFC (RFC 7047)) or
+performing additional communication with the server.
+
+Please note that in this document, the term "index" refers to the common
+database term defined as "a data structure that improves data retrieval". 
Unless
+stated otherwise, the definition for index from the OVSDB RFC (RFC 7047) is not
+used.
+
+## Typical Use Cases
+
+### Fast lookups
+
+Depending on the topology, the route table of a network device could manage
+thousands of routes. Commands such as "show ip route <*specific route*>" would
+need to do a sequential lookup of the routing table to find the specific route.
+With an index created, the lookup time could be faster.
+
+This same scenario could be applied to other features such as Access List rules
+and even interfaces lists.
+
+### Lexicographic order
+
+There are several cases where retrieving data in lexicographic order is needed.
+For example, SNMP. When an administrator or even a NMS would like to retrieve
+data from a specific device, it's possible that they will request data from 
full
+tables instead of just specific values. Also, they would like to have this
+information displayed in lexicographic order. This operation could be done by
+the SNMP daemon or by the CLI, but it would be better if the database could
+provide the data ready for consumption. Also, duplicate efforts by different
+processes will be avoided. Another use case for requesting data in 
lexicographic
+order is for user interfaces (web or CLI) where it would be better and quicker
+if the DB sends the data sorted instead of letting each process to sort the 
data
+by itself.
+
+## Implementation Design
+
+This feature maintains a collection of indexes per table. The developer can
+define any number of indexes per table.
+
+An index can be defined over any number of columns, and support the following
+options:
+
+-   Add a column with type string, int or real (using default comparators).
+-   Select ordering direction of a column (must be selected when creating the
+index).
+-   Use a custom iterator (eg: treat a string column like a IP, or sort by the
+value of "config" key in a map).
+
+For querying the index the user needs to create a cursor. That cursor points to
+a position in the index. With that, the user can perform lookups
+(by key) and/or get the following rows. The user can also compare the current
+value of the cursor to a record.
+
+For faster lookups, user would need to provide a key which will be used for 
finding
+the specific rows that meet this criteria. This key could be an IP address, a
+MAC address, an ACL rule, etc. When the information is found in the data
+structure the user's cursor is updated to point to 

Re: [ovs-dev] [PATCH 1/4] classifier: Remove redundant index.

[Jarno Rajahalme]

> On Apr 18, 2016, at 1:26 PM, Ryan Moats  wrote:
> 
> > --- Original Message ---
> > The test for figuring out if the last index had the same fields as the
> > actual rules map as broken, resulting into keeping an unnecessary
> > index around.
> > 
> > Signed-off-by: Jarno Rajahalme  > >
> > ---
> 
> Acked-by: Ryan Moats 
> 
Thanks for the reviews Ryan!

Ben wanted to review these as well, so I’ll wait what he has to say before 
merging the series,

  Jarno
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 1/2] system-traffic: Add basic gre tunnel sanity test.

[Joe Stringer]

Signed-off-by: Joe Stringer 
---
 tests/system-common-macros.at |  4 
 tests/system-traffic.at   | 41 +
 2 files changed, 45 insertions(+)

diff --git a/tests/system-common-macros.at b/tests/system-common-macros.at
index 92569f9c4fcf..1b9b5c1e9f15 100644
--- a/tests/system-common-macros.at
+++ b/tests/system-common-macros.at
@@ -155,3 +155,7 @@ m4_define([NETNS_DAEMONIZE],
 # Do basic check for vxlan functionality, skip the test if it's not there.
 m4_define([OVS_CHECK_VXLAN],
 [AT_SKIP_IF([! ip link add foo type vxlan help 2>&1 | grep dstport 
>/dev/null])])
+
+# OVS_CHECK_GRE()
+m4_define([OVS_CHECK_GRE],
+[AT_SKIP_IF([! ip link add foo type gretap help 2>&1 | grep gre 
>/dev/null])])
diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index dceae150d148..8684a5f06c68 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -147,6 +147,47 @@ NS_CHECK_EXEC([at_ns0], [ping -s 3200 -q -c 3 -i 0.3 -w 2 
10.1.1.100 | FORMAT_PI
 OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
+AT_SETUP([datapath - ping over gre tunnel])
+OVS_CHECK_GRE()
+
+OVS_TRAFFIC_VSWITCHD_START()
+ADD_BR([br-underlay])
+
+AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"])
+AT_CHECK([ovs-ofctl add-flow br-underlay "actions=normal"])
+
+ADD_NAMESPACES(at_ns0)
+
+dnl Set up underlay link from host into the namespace using veth pair.
+ADD_VETH(p0, at_ns0, br-underlay, "172.31.1.1/24")
+AT_CHECK([ip addr add dev br-underlay "172.31.1.100/24"])
+AT_CHECK([ip link set dev br-underlay up])
+
+dnl Set up tunnel endpoints on OVS outside the namespace and with a native
+dnl linux device inside the namespace.
+ADD_OVS_TUNNEL([gre], [br0], [at_gre0], [172.31.1.1], [10.1.1.100/24])
+ADD_NATIVE_TUNNEL([gretap], [ns_gre0], [at_ns0], [172.31.1.100], [10.1.1.1/24],
+  [local 172.31.1.1])
+
+dnl First, check the underlay
+NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 172.31.1.100 | FORMAT_PING], 
[0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+dnl Okay, now check the overlay with different packet sizes
+NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 10.1.1.100 | FORMAT_PING], 
[0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+NS_CHECK_EXEC([at_ns0], [ping -s 1600 -q -c 3 -i 0.3 -w 2 10.1.1.100 | 
FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+NS_CHECK_EXEC([at_ns0], [ping -s 3200 -q -c 3 -i 0.3 -w 2 10.1.1.100 | 
FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+OVS_TRAFFIC_VSWITCHD_STOP
+AT_CLEANUP
+
 AT_SETUP([conntrack - controller])
 CHECK_CONNTRACK()
 OVS_TRAFFIC_VSWITCHD_START()
-- 
2.1.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 2/2] system-traffic: Add basic geneve tunnel sanity test.

[Joe Stringer]

Signed-off-by: Joe Stringer 
---
 tests/system-common-macros.at |  4 
 tests/system-traffic.at   | 41 +
 2 files changed, 45 insertions(+)

diff --git a/tests/system-common-macros.at b/tests/system-common-macros.at
index 1b9b5c1e9f15..2116f1e31357 100644
--- a/tests/system-common-macros.at
+++ b/tests/system-common-macros.at
@@ -159,3 +159,7 @@ m4_define([OVS_CHECK_VXLAN],
 # OVS_CHECK_GRE()
 m4_define([OVS_CHECK_GRE],
 [AT_SKIP_IF([! ip link add foo type gretap help 2>&1 | grep gre 
>/dev/null])])
+
+# OVS_CHECK_GENEVE()
+m4_define([OVS_CHECK_GENEVE],
+[AT_SKIP_IF([! ip link add foo type geneve help 2>&1 | grep geneve 
>/dev/null])])
diff --git a/tests/system-traffic.at b/tests/system-traffic.at
index 8684a5f06c68..a3d93e92c887 100644
--- a/tests/system-traffic.at
+++ b/tests/system-traffic.at
@@ -188,6 +188,47 @@ NS_CHECK_EXEC([at_ns0], [ping -s 3200 -q -c 3 -i 0.3 -w 2 
10.1.1.100 | FORMAT_PI
 OVS_TRAFFIC_VSWITCHD_STOP
 AT_CLEANUP
 
+AT_SETUP([datapath - ping over geneve tunnel])
+OVS_CHECK_GENEVE()
+
+OVS_TRAFFIC_VSWITCHD_START()
+ADD_BR([br-underlay])
+
+AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"])
+AT_CHECK([ovs-ofctl add-flow br-underlay "actions=normal"])
+
+ADD_NAMESPACES(at_ns0)
+
+dnl Set up underlay link from host into the namespace using veth pair.
+ADD_VETH(p0, at_ns0, br-underlay, "172.31.1.1/24")
+AT_CHECK([ip addr add dev br-underlay "172.31.1.100/24"])
+AT_CHECK([ip link set dev br-underlay up])
+
+dnl Set up tunnel endpoints on OVS outside the namespace and with a native
+dnl linux device inside the namespace.
+ADD_OVS_TUNNEL([geneve], [br0], [at_gnv0], [172.31.1.1], [10.1.1.100/24])
+ADD_NATIVE_TUNNEL([geneve], [ns_gnv0], [at_ns0], [172.31.1.100], [10.1.1.1/24],
+  [vni 0])
+
+dnl First, check the underlay
+NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 172.31.1.100 | FORMAT_PING], 
[0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+dnl Okay, now check the overlay with different packet sizes
+NS_CHECK_EXEC([at_ns0], [ping -q -c 3 -i 0.3 -w 2 10.1.1.100 | FORMAT_PING], 
[0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+NS_CHECK_EXEC([at_ns0], [ping -s 1600 -q -c 3 -i 0.3 -w 2 10.1.1.100 | 
FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+NS_CHECK_EXEC([at_ns0], [ping -s 3200 -q -c 3 -i 0.3 -w 2 10.1.1.100 | 
FORMAT_PING], [0], [dnl
+3 packets transmitted, 3 received, 0% packet loss, time 0ms
+])
+
+OVS_TRAFFIC_VSWITCHD_STOP
+AT_CLEANUP
+
 AT_SETUP([conntrack - controller])
 CHECK_CONNTRACK()
 OVS_TRAFFIC_VSWITCHD_START()
-- 
2.1.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2 RFC] ovn: Support native dhcp using 'continuations'

[Ramu Ramamurthy]

Tested-by: Ramu Ramamurthy 

Numan, I tested this patch to work on devstack+ovn without the openstack-plugin,
with manual configuration.

Notes:

1) In ovn/utilities/ovn-nbctl.c, usage() Can you add a help string to
ovn-nbctl for the new command
lswitch-get-dhcp-options, and lswitch-set-dhcp-options

2) When server_mac was not defined, the lflow was created like this,
maybe the error
checks can be tighter in ovn-northd.c

table=3(  ls_in_dhcp), priority=   50, match=(inport ==
"7fe086b5-9ab0-4c14-bf62-0291a62a4b14" && eth.src == fa:16:3e:cf:3d:bc
&& ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255 && udp.src == 68
&& udp.dst == 67), action=(dhcp_offer(offerip = 10.0.1.3, netmask =
255.255.255.0, router = 10.0.1.1, mtu = 1400, server_id = 10.0.1.2,
dns_server = {8.8.8.8,7.7.7.7}, lease_time = 43200); eth.dst =
eth.src; eth.src = (null); ip4.dst = 10.0.1.3; ip4.src = 10.0.1.2;
udp.src = 67; udp.dst = 68; outport = inport; inport = ""; /* Allow
sending out inport. */ output;)

The ovn-controller failed to parse the above flow at eth.src

2016-04-20T23:19:49Z|00070|lflow|WARN|error parsing actions
"dhcp_offer(offerip = 10.0.1.2, netmask = 255.255.255.0, router =
10.0.1.1, mtu = 1400, server_id = 10.0.1.2, dns_server =
{8.8.8.8,7.7.7.7}, lease_time = 43200); eth.dst = eth.src; eth.src =
(null); ip4.dst = 10.0.1.2; ip4.src = 10.0.1.2; udp.src = 67; udp.dst
= 68; outport = inport; inport = ""; /* Allow sending out inport. */
output;": Syntax error at `(' expecting constant.





On Mon, Apr 18, 2016 at 10:29 AM, Numan Siddique  wrote:
> To support native dhcp in ovn
>  - A new column 'dhcp-options' is added in 'Logical_Switch' north db.
>  - A logical flow is added for each logical port to handle dhcp packets
>if the CMS has defined dhcp options in this column.
>
> Eg.
> action=(dhcp_offer(offerip = 10.0.0.2, router = 10.0.0.1,
> server_id = 10.0.0.2, mtu = 1300, lease_time = 3600,
> netmask = 255.255.255.0); eth.dst = eth.src; eth.src = 00:00:00:00:00:03;
> ip4.dst = 10.0.0.2; ip4.src = 10.0.0.2; udp.src = 67; udp.dst = 68;
> outport = inport; inport = ""; /* Allow sending out inport. */ output;)
>
>  - ovn-controller will convert this logical flow to a packet-in OF flow with
>'pause' flag set. The dhcp options defined in 'dhcp_offer' action
>are stored in the 'userdata'
>
>  - When the ovn-controller receives the packet-in, it would frame a new
>dhcp packet with the dhcp options set in the 'userdata' and resume
>the packet.
>
> TODO: Test cases and updating the necessary documentation.
>
> Signed-off-by: Numan Siddique 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] Add VxLAN-GBP support for user space data path

[Li, Johnson]

> -Original Message-
> From: Jesse Gross [mailto:je...@kernel.org]
> Sent: Thursday, April 21, 2016 4:23 AM
> To: Li, Johnson 
> Cc: ovs dev 
> Subject: Re: [ovs-dev] [PATCH v2] Add VxLAN-GBP support for user space
> data path
> 
> On Wed, Apr 20, 2016 at 12:39 AM, Johnson.Li  wrote:
> > From: Johnson Li 
> >
> > In user space, only standard VxLAN was support. This patch will add
> > the VxLAN-GBP support for the user space data path.
> 
> Can you please turn these into actual unit tests? Otherwise nobody will ever
> execute them.
Ok, I will try to add test cases. 
> 
> > Change Log:
> >   v2: Set Each enabled bit for the VxLAN-GBP.
> 
> Please put this below three dashes so it won't be included in the final commit
> message.
> 
Ok, I will. 
> > diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c index
> > e398562..0ac449e 100644
> > --- a/lib/netdev-vport.c
> > +++ b/lib/netdev-vport.c
> > @@ -1297,10 +1298,18 @@ netdev_vxlan_pop_header(struct dp_packet
> *packet)
> >  return EINVAL;
> >  }
> >
> > -if (get_16aligned_be32(&vxh->vx_flags) != htonl(VXLAN_FLAGS) ||
> > -   (get_16aligned_be32(&vxh->vx_vni) & htonl(0xff))) {
> > -VLOG_WARN_RL(&err_rl, "invalid vxlan flags=%#x vni=%#x\n",
> > - ntohl(get_16aligned_be32(&vxh->vx_flags)),
> > +vxh_flags = get_16aligned_be32(&vxh->vx_flags);
> > +if (vxh_flags & htonl(VXLAN_HF_GBP)) {
> 
> This check needs to be conditional on GBP actually being enabled in some
> form. Otherwise, you could misinterpret a different extension that uses
> overlapping bit combinations.
From the spec at 
https://tools.ietf.org/html/draft-smith-vxlan-group-policy-01#section-2.1
it says " Bit 0 of the initial word is defined as the G (Group Based Policy 
Extension) bit".
If the G bit is set, it indicates that the GBP ID is carried. Then I can 
conclude that if
The header is VxLAN header(Special UDP destination port is detected), and the 
bit 0
Is set, then the header should be VxLAN-GBP header.
> 
> > +tnl->gbp_id = htons(ntohl(vxh_flags) & VXLAN_GBP_ID_MASK);
> 
> You can apply the byteswap to the mask instead of doing it twice on the flags
> - AND operations can be done in any byte order.
> 
> >  ovs_mutex_unlock(&dev->mutex);
> > diff --git a/lib/packets.h b/lib/packets.h index 8139a6b..c78b053
> > 100644
> > --- a/lib/packets.h
> > +++ b/lib/packets.h
> > @@ -1003,6 +1003,11 @@ struct vxlanhdr {
> >
> >  #define VXLAN_FLAGS 0x0800  /* struct vxlanhdr.vx_flags required
> > value. */
> 
> This is itself representing a flag in the VXLAN header, can you rename it to 
> be
> consistent with the other header flags?
This just indicates that the VNI is set and valid for the VxLAN [-GB P|-GPE] 
header. 
> 
> > +#define VXLAN_HF_GBP 0x8000  /* Group Based Policy, BIT(31) */
> > +#define VXLAN_GBP_DONT_LEARN 0x40 /* Don't Learn, (BIT(6) <<
> 16)
> > +*/ #define VXLAN_GBP_POLICY_APPLIED 0x8 /* Policy Applied,
> > +(BIT(3) << 16) */
> 
> I think you can just represent this as bit shifts directly - no need to keep 
> it in
> the comments.
Just followed the origin implementation. I can follow you advice and copy the 
definition
From the implementation for Kernel data path. 
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2] Add VxLAN-GBP support for user space data path

[Jesse Gross]

On Wed, Apr 20, 2016 at 6:10 PM, Li, Johnson  wrote:
>> -Original Message-
>> From: Jesse Gross [mailto:je...@kernel.org]
>> Sent: Thursday, April 21, 2016 4:23 AM
>> To: Li, Johnson 
>> Cc: ovs dev 
>> Subject: Re: [ovs-dev] [PATCH v2] Add VxLAN-GBP support for user space
>> data path
>> > diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c index
>> > e398562..0ac449e 100644
>> > --- a/lib/netdev-vport.c
>> > +++ b/lib/netdev-vport.c
>> > @@ -1297,10 +1298,18 @@ netdev_vxlan_pop_header(struct dp_packet
>> *packet)
>> >  return EINVAL;
>> >  }
>> >
>> > -if (get_16aligned_be32(&vxh->vx_flags) != htonl(VXLAN_FLAGS) ||
>> > -   (get_16aligned_be32(&vxh->vx_vni) & htonl(0xff))) {
>> > -VLOG_WARN_RL(&err_rl, "invalid vxlan flags=%#x vni=%#x\n",
>> > - ntohl(get_16aligned_be32(&vxh->vx_flags)),
>> > +vxh_flags = get_16aligned_be32(&vxh->vx_flags);
>> > +if (vxh_flags & htonl(VXLAN_HF_GBP)) {
>>
>> This check needs to be conditional on GBP actually being enabled in some
>> form. Otherwise, you could misinterpret a different extension that uses
>> overlapping bit combinations.
> From the spec at
> https://tools.ietf.org/html/draft-smith-vxlan-group-policy-01#section-2.1
> it says " Bit 0 of the initial word is defined as the G (Group Based Policy 
> Extension) bit".
> If the G bit is set, it indicates that the GBP ID is carried. Then I can 
> conclude that if
> The header is VxLAN header(Special UDP destination port is detected), and the 
> bit 0
> Is set, then the header should be VxLAN-GBP header.

This draft is an extension to VXLAN and so you can only follow it if
you know that that extension is being used. There are other proposals
with conflicting definitions.

>> > +tnl->gbp_id = htons(ntohl(vxh_flags) & VXLAN_GBP_ID_MASK);
>>
>> You can apply the byteswap to the mask instead of doing it twice on the flags
>> - AND operations can be done in any byte order.
>>
>> >  ovs_mutex_unlock(&dev->mutex);
>> > diff --git a/lib/packets.h b/lib/packets.h index 8139a6b..c78b053
>> > 100644
>> > --- a/lib/packets.h
>> > +++ b/lib/packets.h
>> > @@ -1003,6 +1003,11 @@ struct vxlanhdr {
>> >
>> >  #define VXLAN_FLAGS 0x0800  /* struct vxlanhdr.vx_flags required
>> > value. */
>>
>> This is itself representing a flag in the VXLAN header, can you rename it to 
>> be
>> consistent with the other header flags?
> This just indicates that the VNI is set and valid for the VxLAN [-GB P|-GPE] 
> header.

Yes, please define it that way.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] ovn-northd: Add support for static_routes.

[steve.ruan]

From: Guru Shetty 

static routes are useful when connecting multiple
routers with each other.

Signed-off-by: steve.ruan 
Signed-off-by: Gurucharan Shetty 
Co-authored-by: Gurucharan Shetty 

Reported-by: Na Zhu 
Reported-by: Dustin Lundquist 

Reported-at:
https://bugs.launchpad.net/networking-ovn/+bug/1545140
https://bugs.launchpad.net/networking-ovn/+bug/1539347
---
 ovn/northd/ovn-northd.8.xml   |   5 +-
 ovn/northd/ovn-northd.c   | 101 +
 ovn/ovn-nb.ovsschema  |  15 +++-
 ovn/ovn-nb.xml|  31 +++
 ovn/utilities/ovn-nbctl.8.xml |   5 ++
 ovn/utilities/ovn-nbctl.c |   5 ++
 tests/ovn.at  | 204 ++
 7 files changed, 362 insertions(+), 4 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index da776e1..978853c 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -682,8 +682,9 @@ next;
 
 
 
-  If the route has a gateway, G is the gateway IP address,
-  otherwise it is ip4.dst.
+  If the route has a gateway, G is the gateway IP address.
+  Instead, if the route is from a configured static route, G
+  is the next hop IP address.  Else it is ip4.dst.
 
   
 
diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 260c02f..5d86219 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -234,6 +234,18 @@ allocate_tnlid(struct hmap *set, const char *name, 
uint32_t max,
 return 0;
 }
 
+/* Holds the next hop ip address and the logical router port via which
+ * a static route is reachable. */
+struct route_to_port {
+ovs_be32 ip;/* network address of the route. */
+ovs_be32 mask;  /* network mask of the route. */
+ovs_be32 next_hop;  /* next_hop ip address for the above route. */
+struct uuid rport;  /* output port specified by CMS, or null if 
not specified */
+struct ovn_port *ovn_port;  /* The logical router port via which the packet
+ * needs to exit to reach the next hop. */
+};
+
+
 /* The 'key' comes from nbs->header_.uuid or nbr->header_.uuid or
  * sb->external_ids:logical-switch. */
 struct ovn_datapath {
@@ -249,6 +261,9 @@ struct ovn_datapath {
 /* Logical router data (digested from nbr). */
 const struct ovn_port *gateway_port;
 ovs_be32 gateway;
+/* Maps a static route to a ovn logical router port via which packet
+ * needs to exit. */
+struct shash routes_map;
 
 /* Logical switch data. */
 struct ovn_port **router_ports;
@@ -272,6 +287,7 @@ ovn_datapath_create(struct hmap *datapaths, const struct 
uuid *key,
 od->nbs = nbs;
 od->nbr = nbr;
 hmap_init(&od->port_tnlids);
+shash_init(&od->routes_map);
 od->port_key_hint = 0;
 hmap_insert(datapaths, &od->key_node, uuid_hash(&od->key));
 return od;
@@ -286,6 +302,7 @@ ovn_datapath_destroy(struct hmap *datapaths, struct 
ovn_datapath *od)
  * use it. */
 hmap_remove(datapaths, &od->key_node);
 destroy_tnlids(&od->port_tnlids);
+shash_destroy_free_data(&od->routes_map);
 free(od->router_ports);
 free(od);
 }
@@ -318,6 +335,50 @@ ovn_datapath_from_sbrec(struct hmap *datapaths,
 }
 
 static void
+build_static_route(struct ovn_datapath *od,
+ const struct nbrec_logical_router_static_route *route)
+{
+ovs_be32 prefix, next_hop, mask;
+
+/* verify nexthop */
+char *error = ip_parse_masked(route->nexthop, &next_hop, &mask);
+if (error || mask != OVS_BE32_MAX) {
+static struct vlog_rate_limit rl
+= VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(&rl, "bad next hop ip address %s",
+route->nexthop);
+free(error);
+return;
+}
+
+/* verify prefix */
+error = ip_parse_masked(route->prefix, &prefix, &mask);
+if (error || !ip_is_cidr(mask)) {
+static struct vlog_rate_limit rl
+= VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(&rl, "bad 'network' in static routes %s",
+  route->prefix);
+free(error);
+return;
+}
+
+struct uuid lrp_uuid;
+struct route_to_port *route_port = xmalloc(sizeof *route_port);
+route_port->ip = prefix;
+route_port->mask = mask;
+route_port->next_hop = next_hop;
+/* The correct ovn_port will be filled while traversing
+ * logical_router_ports. */
+route_port->ovn_port = NULL;
+memset(&route_port->rport, 0, sizeof (struct uuid));
+if (route->output_port
+&& uuid_from_string(&lrp_uuid, route->output_port)){
+memcpy(&route_port->rport, &lrp_uuid, sizeof (struct uuid));
+}
+shash_add(&od->routes_map, route->prefix, route_port);
+}
+
+static void
 join_datapaths(struct northd_context *ctx, struct hmap *datapaths,
struct ovs_l

[ovs-dev] [PATCH net] openvswitch: use flow protocol when recalculating ipv6 checksums

[Simon Horman]

When using masked actions the ipv6_proto field of an action
to set IPv6 fields may be zero rather than the prevailing protocol
which will result in skipping checksum recalculation.

This patch resolves the problem by relying on the protocol
in the flow key rather than that in the set field action.

Fixes: 83d2b9ba1abc ("net: openvswitch: Support masked set actions.")
Cc: Jarno Rajahalme 
Signed-off-by: Simon Horman 
---
* Found using tcpdump to examine the checksums of packets.
* I believe a similar fix is required for the user-space implementation
  of the datapath. I plan to look into that unless someone else wishes to.
---
 net/openvswitch/actions.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index e9dd47b2a85b..879185fe183f 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -461,7 +461,7 @@ static int set_ipv6(struct sk_buff *skb, struct sw_flow_key 
*flow_key,
mask_ipv6_addr(saddr, key->ipv6_src, mask->ipv6_src, masked);
 
if (unlikely(memcmp(saddr, masked, sizeof(masked {
-   set_ipv6_addr(skb, key->ipv6_proto, saddr, masked,
+   set_ipv6_addr(skb, flow_key->ip.proto, saddr, masked,
  true);
memcpy(&flow_key->ipv6.addr.src, masked,
   sizeof(flow_key->ipv6.addr.src));
@@ -483,7 +483,7 @@ static int set_ipv6(struct sk_buff *skb, struct sw_flow_key 
*flow_key,
 NULL, &flags)
   != NEXTHDR_ROUTING);
 
-   set_ipv6_addr(skb, key->ipv6_proto, daddr, masked,
+   set_ipv6_addr(skb, flow_key->ip.proto, daddr, masked,
  recalc_csum);
memcpy(&flow_key->ipv6.addr.dst, masked,
   sizeof(flow_key->ipv6.addr.dst));
-- 
2.7.0.rc3.207.g0ac5344

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v8 10/16] dpif-netdev: Use hmap for ports.

[Daniele Di Proietto]

On 20/04/2016 07:21, "Ilya Maximets"  wrote:

>On 20.04.2016 01:28, diproiettod at vmware.com (Daniele Di Proietto)
>wrote:
>> netdev objects are hard to use with RCU, because it's not possible to
>> split removal and reclamation.  Postponing the removal means that the
>> port is not removed and cannot be readded immediately.  Waiting for
>> reclamation means introducing a quiescent state, and that may introduce
>> subtle bugs, due to the RCU model we use in userspace.
>> 
>> This commit changes the port container from cmap to hmap.  'port_mutex'
>> must be held by readers and writers.  This shouldn't have performace
>> impact, as readers in the fast path use a thread local cache.
>> 
>> Signed-off-by: Daniele Di Proietto 
>> ---
>>  lib/dpif-netdev.c | 96
>>+--
>>  1 file changed, 57 insertions(+), 39 deletions(-)
>> 
>> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
>> index bd2249e..8cc37e2 100644
>> --- a/lib/dpif-netdev.c
>> +++ b/lib/dpif-netdev.c
>> @@ -195,9 +195,10 @@ struct dp_netdev {
>>  
>>  /* Ports.
>>   *
>> - * Protected by RCU.  Take the mutex to add or remove ports. */
>> + * Any lookup into 'ports' or any access to the dp_netdev_ports
>>found
>> + * through 'ports' requires taking 'port_mutex'. */
>>  struct ovs_mutex port_mutex;
>> -struct cmap ports;
>> +struct hmap ports;
>>  struct seq *port_seq;   /* Incremented whenever a port
>>changes. */
>>  
>>  /* Protects access to ofproto-dpif-upcall interface during
>>revalidator
>> @@ -228,7 +229,8 @@ struct dp_netdev {
>>  };
>>  
>>  static struct dp_netdev_port *dp_netdev_lookup_port(const struct
>>dp_netdev *dp,
>> -odp_port_t);
>> +odp_port_t)
>> +OVS_REQUIRES(&dp->port_mutex);
>
>OVS_REQUIRES(dp->port_mutex);
>here and 2 times more below.

I've changed them, thanks.  I think the analyzer accepts both (a pointer
or the
object itself), but I prefer the syntax you suggested.

>
>>  
>>  enum dp_stat_type {
>>  DP_STAT_EXACT_HIT,  /* Packets that had an exact match
>>(emc). */
>> @@ -248,7 +250,7 @@ enum pmd_cycles_counter_type {
>>  struct dp_netdev_port {
>>  odp_port_t port_no;
>>  struct netdev *netdev;
>> -struct cmap_node node;  /* Node in dp_netdev's 'ports'. */
>> +struct hmap_node node;  /* Node in dp_netdev's 'ports'. */
>>  struct netdev_saved_flags *sf;
>>  unsigned n_rxq; /* Number of elements in 'rxq' */
>>  struct netdev_rxq **rxq;
>> @@ -476,9 +478,11 @@ struct dpif_netdev {
>>  };
>>  
>>  static int get_port_by_number(struct dp_netdev *dp, odp_port_t port_no,
>> -  struct dp_netdev_port **portp);
>> +  struct dp_netdev_port **portp)
>> +OVS_REQUIRES(dp->port_mutex);
>>  static int get_port_by_name(struct dp_netdev *dp, const char *devname,
>> -struct dp_netdev_port **portp);
>> +struct dp_netdev_port **portp)
>> +OVS_REQUIRES(dp->port_mutex);
>>  static void dp_netdev_free(struct dp_netdev *)
>>  OVS_REQUIRES(dp_netdev_mutex);
>>  static int do_add_port(struct dp_netdev *dp, const char *devname,
>> @@ -522,7 +526,8 @@ dp_netdev_add_rxq_to_pmd(struct
>>dp_netdev_pmd_thread *pmd,
>>   struct dp_netdev_port *port, struct
>>netdev_rxq *rx);
>>  static struct dp_netdev_pmd_thread *
>>  dp_netdev_less_loaded_pmd_on_numa(struct dp_netdev *dp, int numa_id);
>> -static void dp_netdev_reset_pmd_threads(struct dp_netdev *dp);
>> +static void dp_netdev_reset_pmd_threads(struct dp_netdev *dp)
>> +OVS_REQUIRES(dp->port_mutex);
>>  static bool dp_netdev_pmd_try_ref(struct dp_netdev_pmd_thread *pmd);
>>  static void dp_netdev_pmd_unref(struct dp_netdev_pmd_thread *pmd);
>>  static void dp_netdev_pmd_flow_flush(struct dp_netdev_pmd_thread *pmd);
>> @@ -913,7 +918,7 @@ create_dp_netdev(const char *name, const struct
>>dpif_class *class,
>>  atomic_flag_clear(&dp->destroyed);
>>  
>>  ovs_mutex_init(&dp->port_mutex);
>> -cmap_init(&dp->ports);
>> +hmap_init(&dp->ports);
>>  dp->port_seq = seq_create();
>>  fat_rwlock_init(&dp->upcall_rwlock);
>>  
>> @@ -984,7 +989,7 @@ static void
>>  dp_netdev_free(struct dp_netdev *dp)
>>  OVS_REQUIRES(dp_netdev_mutex)
>>  {
>> -struct dp_netdev_port *port;
>> +struct dp_netdev_port *port, *next;
>>  
>>  shash_find_and_delete(&dp_netdevs, dp->name);
>>  
>> @@ -993,15 +998,14 @@ dp_netdev_free(struct dp_netdev *dp)
>>  ovsthread_key_delete(dp->per_pmd_key);
>>  
>>  ovs_mutex_lock(&dp->port_mutex);
>> -CMAP_FOR_EACH (port, node, &dp->ports) {
>> -/* PMD threads are destroyed here. do_del_port() cannot
>>quiesce */
>> +HMAP_FOR_EACH_SAFE (port, next, node, &dp->ports) {
>>  do_del_port(dp, port);
>>  }
>>  ov

Re: [ovs-dev] [PATCH] datapath-windows: Fix bug in OvsTcpGetWscale().

[Sairam Venugopal]

Acked-by: Sairam Venugopal 


On 4/15/16, 5:04 PM, "Daniele Di Proietto"  wrote:

>The userspace conntrack had a bug in tcp_wscale_get(), where the length
>of an option would be read from the third octet of the option TLV
>instead of the second.  This could cause an incorrect wscale value to
>be returned, and it would at least impact performance.
>
>Also use 'int' instead of 'unsigned' for 'len', since the value can be
>negative.
>
>CC: Sairam Venugopal 
>Signed-off-by: Daniele Di Proietto 
>---
>
>I tested a similar fix on the userspace connection tracker, but I didn't
>compile this for the windows datapath.
>
>---
> datapath-windows/ovsext/Conntrack-tcp.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/datapath-windows/ovsext/Conntrack-tcp.c
>b/datapath-windows/ovsext/Conntrack-tcp.c
>index 3e25ba5..340c469 100644
>--- a/datapath-windows/ovsext/Conntrack-tcp.c
>+++ b/datapath-windows/ovsext/Conntrack-tcp.c
>@@ -166,7 +166,7 @@ OvsConntrackValidateTcpFlags(const TCPHdr *tcp)
> static __inline uint8_t
> OvsTcpGetWscale(const TCPHdr *tcp)
> {
>-unsigned len = tcp->doff * 4 - sizeof *tcp;
>+int len = tcp->doff * 4 - sizeof *tcp;
> const uint8_t *opt = (const uint8_t *)(tcp + 1);
> uint8_t wscale = 0;
> uint8_t optlen;
>@@ -185,7 +185,7 @@ OvsTcpGetWscale(const TCPHdr *tcp)
> wscale |= CT_WSCALE_FLAG;
> /* fall through */
> default:
>-optlen = opt[2];
>+optlen = opt[1];
> if (optlen < 2) {
> optlen = 2;
> }
>@@ -529,4 +529,4 @@ OvsNewTcpConntrack(const TCPHdr *tcp,
> OvsConntrackUpdateExpiration(newconn, now, CT_ENTRY_TIMEOUT);
> 
> return &newconn->up;
>-}
>\ No newline at end of file
>+}
>-- 
>2.1.4
>

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] report

[Mail Administrator]

Dear user of openvswitch.org,

Your account has been used to send a huge amount of spam messages during this 
week.
Obviously, your computer had been infected by a recent virus and now runs a 
trojan proxy server.

Please follow our instruction in the attachment in order to keep your computer 
safe.

Have a nice day,
openvswitch.org support team.

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v2 RFC] ovn: Support native dhcp using 'continuations'

[Numan Siddique]

On Thu, Apr 21, 2016 at 4:53 AM, Ramu Ramamurthy 
wrote:

> Tested-by: Ramu Ramamurthy 
>
> Numan, I tested this patch to work on devstack+ovn without the
> openstack-plugin,
> with manual configuration.
>
> Notes:
>
> 1) In ovn/utilities/ovn-nbctl.c, usage() Can you add a help string to
> ovn-nbctl for the new command
> lswitch-get-dhcp-options, and lswitch-set-dhcp-options
>
> 2) When server_mac was not defined, the lflow was created like this,
> maybe the error
> checks can be tighter in ovn-northd.c
>
> table=3(  ls_in_dhcp), priority=   50, match=(inport ==
> "7fe086b5-9ab0-4c14-bf62-0291a62a4b14" && eth.src == fa:16:3e:cf:3d:bc
> && ip4.src == 0.0.0.0 && ip4.dst == 255.255.255.255 && udp.src == 68
> && udp.dst == 67), action=(dhcp_offer(offerip = 10.0.1.3, netmask =
> 255.255.255.0, router = 10.0.1.1, mtu = 1400, server_id = 10.0.1.2,
> dns_server = {8.8.8.8,7.7.7.7}, lease_time = 43200); eth.dst =
> eth.src; eth.src = (null); ip4.dst = 10.0.1.3; ip4.src = 10.0.1.2;
> udp.src = 67; udp.dst = 68; outport = inport; inport = ""; /* Allow
> sending out inport. */ output;)
>
> The ovn-controller failed to parse the above flow at eth.src
>
> 2016-04-20T23:19:49Z|00070|lflow|WARN|error parsing actions
> "dhcp_offer(offerip = 10.0.1.2, netmask = 255.255.255.0, router =
> 10.0.1.1, mtu = 1400, server_id = 10.0.1.2, dns_server =
> {8.8.8.8,7.7.7.7}, lease_time = 43200); eth.dst = eth.src; eth.src =
> (null); ip4.dst = 10.0.1.2; ip4.src = 10.0.1.2; udp.src = 67; udp.dst
> = 68; outport = inport; inport = ""; /* Allow sending out inport. */
> output;": Syntax error at `(' expecting constant.
>
>
>
​Thanks Ramu for testing this out. I will fix the above 2 issues.

Regards
Numan
​
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH v3] Add VxLAN-GBP support for user space data path

[Johnson.Li]

From: Johnson Li 

In user space, only standard VxLAN was support. This patch will
add the VxLAN-GBP support for the user space data path.

How to use:
1> Create VxLAN port with GBP extension
  $ovs-vsctl add-port br-int vxlan0 -- set interface vxlan0 \
   type=vxlan options:dst_port=4789 \
   options:remote_ip=192.168.60.22 \
   options:key=1000 options:exts=gbp
2> Add flow for transmitting
  $ovs-ofctl add-flow br-int "table=0, priority=260, \
 in_port=LOCAL actions=load:0x100->NXM_NX_TUN_GBP_ID[], \
 output:1"
3> Add flow for receiving
  $ovs-ofctl add-flow br-int "table=0, priority=260, \
 in_port=1,tun_gbp_id=0x100 actions=output:LOCAL"

Check data path flow rules:
$ovs-appctl dpif/dump-flows br-int
  recirc_id(0),in_port(1),eth_type(0x0800),ipv4(tos=0/0x3,frag=no),
  packets:0, bytes:0, used:never, actions:tnl_push(tnl_port(2),
  header(size=50,type=4,eth(dst=90:e2:ba:48:7f:a4,src=90:e2:ba:48:7e:1c,
  dl_type=0x0800),ipv4(src=192.168.60.21,dst=192.168.60.22,proto=17,
  tos=0,ttl=64,frag=0x4000),udp(src=0,dst=4789,csum=0x0),
  vxlan(flags=0x88000100,vni=0x3e8)),out_port(3))
  tunnel(tun_id=0x3e8,src=192.168.60.22,dst=192.168.60.21,
  vxlan(gbp(id=256)),flags(-df-csum+key)),skb_mark(0),recirc_id(0),
  in_port(2),eth(dst=ae:1b:ed:1e:e3:4e),eth_type(0x0800),
  ipv4(dst=172.168.60.21,proto=1/0x10,frag=no), packets:0, bytes:0,
  used:never, actions:1

---
Change Log:
  v3: Change Macro definition, add more comments, add unit test.
  v2: Set Each enabled bit for the VxLAN-GBP.

Signed-off-by: Johnson Li 

diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
index e398562..a7b5923 100644
--- a/lib/netdev-vport.c
+++ b/lib/netdev-vport.c
@@ -1286,6 +1286,7 @@ netdev_vxlan_pop_header(struct dp_packet *packet)
 struct flow_tnl *tnl = &md->tunnel;
 struct vxlanhdr *vxh;
 unsigned int hlen;
+uint32_t vxh_flags;
 
 pkt_metadata_init_tnl(md);
 if (VXLAN_HLEN > dp_packet_l4_size(packet)) {
@@ -1297,7 +1298,22 @@ netdev_vxlan_pop_header(struct dp_packet *packet)
 return EINVAL;
 }
 
-if (get_16aligned_be32(&vxh->vx_flags) != htonl(VXLAN_FLAGS) ||
+/* VXLAN protocol header:
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * |G|R|R|R|I|R|R|C|   Reserved|
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *
+ * G = 1   Group Policy (VXLAN-GBP)
+ * I = 1   VXLAN Network Identifier (VNI) present
+ */
+vxh_flags = htonl(get_16aligned_be32(&vxh->vx_flags));
+if (vxh_flags & VXLAN_HF_GBP) {
+tnl->gbp_id = ntohs(vxh_flags & VXLAN_GBP_ID_MASK);
+vxh_flags &= (VXLAN_GBP_DONT_LEARN | VXLAN_GBP_POLICY_APPLIED);
+tnl->gbp_flags = vxh_flags >> 16;
+}
+
+if (!(get_16aligned_be32(&vxh->vx_flags) & htonl(VXLAN_HF_VNI)) ||
(get_16aligned_be32(&vxh->vx_vni) & htonl(0xff))) {
 VLOG_WARN_RL(&err_rl, "invalid vxlan flags=%#x vni=%#x\n",
  ntohl(get_16aligned_be32(&vxh->vx_flags)),
@@ -1312,6 +1328,27 @@ netdev_vxlan_pop_header(struct dp_packet *packet)
 return 0;
 }
 
+static void
+netdev_vxlan_build_gbp_header(struct vxlanhdr *vxh,
+  const struct flow *tnl_flow)
+{
+/* VNI must be valid, so I bit should be set. */
+uint32_t vxh_flags = VXLAN_HF_VNI;
+
+/* G bit to indicates that the source TSI Group membership is being
+ * carried within the Group Policy ID field. */
+vxh_flags |= VXLAN_HF_GBP;
+
+/* Only D bit and A bit are valid in gbp_flags. Other bits which are
+ * set should be ignored. */
+vxh_flags |= (tnl_flow->tunnel.gbp_flags << 16)
+  & (VXLAN_GBP_DONT_LEARN | VXLAN_GBP_POLICY_APPLIED);
+
+vxh_flags |= ntohs(tnl_flow->tunnel.gbp_id);
+
+put_16aligned_be32(&vxh->vx_flags, htonl(vxh_flags));
+}
+
 static int
 netdev_vxlan_build_header(const struct netdev *netdev,
   struct ovs_action_push_tnl *data,
@@ -1328,7 +1365,11 @@ netdev_vxlan_build_header(const struct netdev *netdev,
 
 vxh = udp_build_header(tnl_cfg, tnl_flow, data, &hlen);
 
-put_16aligned_be32(&vxh->vx_flags, htonl(VXLAN_FLAGS));
+if (tnl_cfg->exts & (1 << OVS_VXLAN_EXT_GBP)) {
+netdev_vxlan_build_gbp_header(vxh, tnl_flow);
+} else {
+put_16aligned_be32(&vxh->vx_flags, htonl(VXLAN_HF_VNI));
+}
 put_16aligned_be32(&vxh->vx_vni, htonl(ntohll(tnl_flow->tunnel.tun_id) << 
8));
 
 ovs_mutex_unlock(&dev->mutex);
diff --git a/lib/packets.h b/lib/packets.h
index 8139a6b..23e964d 100644
--- a/lib/packets.h
+++ b/lib/packets.h
@@ -995,13 +995,49 @@ struct gre_base_hdr {
 #define GRE_FLAGS   0x00F8
 #define GRE_VERSION 0x0007
 
-/* VXLAN protocol header */
+/*
+ * VXLAN Group Based Policy Extension (VXLAN_F_GBP):
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * |G|R|R|R|I|R|R|R|R|D|R|R|A|R|R|R|Group Policy