Re: [ovs-discuss] Using OVSDB to configure flow rules

2016-09-15 Thread Ben Pfaff 
On Fri, Sep 16, 2016 at 04:31:24AM +, Purnendu Ghosh wrote:
> Is it possible to use the OVSDB interface to configure flow rules?

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

[ovs-discuss] Using OVSDB to configure flow rules

2016-09-15 Thread Purnendu Ghosh 
Hi ,

I am new to OVS. I am just curious about the following thought.
Is it possible to use the OVSDB interface to configure flow rules?


Best Regards,
Purnendu Ghosh

Happiest Minds Technologies Pvt Ltd,
m: +91 9445393861 a: Survey No.47/8, 3rd Floor, 1st phase, Velankani Drive,
Electronics City Phase 1,Bengaluru, Karnataka 560100
s: www.happiestminds.com e: 
purnendu.gh...@happiestminds.com
https://in.linkedin.com/in/purnendu15



Happiest Minds Disclaimer

This message is for the sole use of the intended recipient(s) and may contain 
confidential, proprietary or legally privileged information. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
original intended recipient of the message, please contact the sender by reply 
email and destroy all copies of the original message.

Happiest Minds Technologies 


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

Re: [ovs-discuss] vswitchd restart and bond interfaces

2016-09-15 Thread my_ovs_discuss 
Hi Ben,  Thanks for the response. 

I am able to reproduce this problem almost every time, but I had noticed that 
one or two times it worked fine.I am not that worried about the MAC address 
stuff right now. 

port2 has valid mac address:
port2    Link encap:Ethernet  HWaddr 00:00:46:FD:5E:59
    UP BROADCAST RUNNING PROMISC  MTU:1500  Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000 
    RX bytes:0 (0  Bytes)  TX bytes:0 (0  Bytes)


-Thanks 

Sent from Yahoo Mail. Get the app

  From: Ben Pfaff 
 To: my_ovs_disc...@yahoo.com 
Cc: "discuss@openvswitch.org" 
 Sent: Thursday, September 15, 2016 5:47 PM
 Subject: Re: [ovs-discuss] vswitchd restart and bond interfaces
   
On Fri, Sep 16, 2016 at 12:02:57AM +, my_ovs_disc...@yahoo.com wrote:
> Hi,
> I am seeing this strange behavior of slaves getting disabled on bond 
> interfaces upon restart of vswitchd.This bond is static LAG, no LACP. 
> 
> openvswitch-2.5.0 on Centos-6.2 based Linux
> 
> This is the sequence I tried:
>    
>    - kill (vswitchd's pid)
>    - kill (ovsdb-server's pid)  
> 
>    - rm -f /usr/local/etc/openvswitch/conf.db
>    - rm -f /usr/local/var/run/openvswitch/db.sock
>    - ovsdb-tool create /usr/local/etc/openvswitch/conf.db 
>/etc/vswitch.ovsschema
>    - ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock 
>--remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile
>    - ovs-vsctl --no-wait emer-reset
>    - ovs-vsctl --no-wait init
>    - ovs-vswitchd --pidfile
>    - ovs-vsctl add-br br0
>    - ovs-vsctl set bridge br0 datapath_type=netdev
>    - ovs-vsctl set Bridge br0 mcast_snooping_enable=true
>    - ovs-vsctl set Bridge br0 other_config:mcast-snooping-table-size=8192
>    - ovs-vsctl --may-exist add-bond br0 bond0 port1 port2 
>bond_mode=balance-slb -- set port bond0 vlan_mode=trunk
> 
> In case of regular bootup, only steps 1 and 2 won't be there.
> For regular fresh bootup case, I see
> ovs-appctl bond/show
>  bond0 
> bond_mode: balance-slb
> bond may use recirculation: no, Recirc-ID : -1
> bond-hash-basis: 0
> updelay: 0 ms
> downdelay: 0 ms
> next rebalance: 8524 ms
> lacp_status: off
> active slave mac: 00:00:00:00:00:00(port1)
> 
> slave port1: enabled
>     active slave
>     may_enable: true
> 
> slave port2: enabled
>     may_enable: true
> 
> But, if I follow steps 1-14, then I see that bond members are in disabled 
> state:
> ovs-appctl bond/show
>  bond0 
> bond_mode: balance-slb
> bond may use recirculation: no, Recirc-ID : -1
> bond-hash-basis: 0
> updelay: 0 ms
> downdelay: 0 ms
> next rebalance: 6582 ms
> lacp_status: off
> active slave mac: 00:00:00:00:00:00(port2)
> 
> slave port1: disabled
>     may_enable: false
> 
> slave port2: disabled
>     may_enable: false
> 
> Is there something that I am missing during restart?

I can't reproduce this problem in my own testing, from a VM, just now.

It's really weird that, in the case where there is an active slave, it
shows its MAC as all-zeros.  Do port2 actually have an all-zeros MAC?  I
assume not.  There might be something weird even in the "working" case.


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

Re: [ovs-discuss] vswitchd restart and bond interfaces

2016-09-15 Thread Ben Pfaff 
On Fri, Sep 16, 2016 at 12:02:57AM +, my_ovs_disc...@yahoo.com wrote:
> Hi,
> I am seeing this strange behavior of slaves getting disabled on bond 
> interfaces upon restart of vswitchd.This bond is static LAG, no LACP. 
> 
> openvswitch-2.5.0 on Centos-6.2 based Linux
> 
> This is the sequence I tried:
>
>- kill (vswitchd's pid)
>- kill (ovsdb-server's pid)   
> 
>- rm -f /usr/local/etc/openvswitch/conf.db
>- rm -f /usr/local/var/run/openvswitch/db.sock
>- ovsdb-tool create /usr/local/etc/openvswitch/conf.db 
> /etc/vswitch.ovsschema
>- ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock 
> --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile
>- ovs-vsctl --no-wait emer-reset
>- ovs-vsctl --no-wait init
>- ovs-vswitchd --pidfile
>- ovs-vsctl add-br br0
>- ovs-vsctl set bridge br0 datapath_type=netdev
>- ovs-vsctl set Bridge br0 mcast_snooping_enable=true
>- ovs-vsctl set Bridge br0 other_config:mcast-snooping-table-size=8192
>- ovs-vsctl --may-exist add-bond br0 bond0 port1 port2 
> bond_mode=balance-slb -- set port bond0 vlan_mode=trunk
> 
> In case of regular bootup, only steps 1 and 2 won't be there.
> For regular fresh bootup case, I see
> ovs-appctl bond/show
>  bond0 
> bond_mode: balance-slb
> bond may use recirculation: no, Recirc-ID : -1
> bond-hash-basis: 0
> updelay: 0 ms
> downdelay: 0 ms
> next rebalance: 8524 ms
> lacp_status: off
> active slave mac: 00:00:00:00:00:00(port1)
> 
> slave port1: enabled
>     active slave
>     may_enable: true
> 
> slave port2: enabled
>     may_enable: true
> 
> But, if I follow steps 1-14, then I see that bond members are in disabled 
> state:
> ovs-appctl bond/show
>  bond0 
> bond_mode: balance-slb
> bond may use recirculation: no, Recirc-ID : -1
> bond-hash-basis: 0
> updelay: 0 ms
> downdelay: 0 ms
> next rebalance: 6582 ms
> lacp_status: off
> active slave mac: 00:00:00:00:00:00(port2)
> 
> slave port1: disabled
>     may_enable: false
> 
> slave port2: disabled
>     may_enable: false
> 
> Is there something that I am missing during restart?

I can't reproduce this problem in my own testing, from a VM, just now.

It's really weird that, in the case where there is an active slave, it
shows its MAC as all-zeros.  Do port2 actually have an all-zeros MAC?  I
assume not.  There might be something weird even in the "working" case.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] vswitchd restart and bond interfaces

2016-09-15 Thread my_ovs_discuss 
Hi,
I am seeing this strange behavior of slaves getting disabled on bond interfaces 
upon restart of vswitchd.This bond is static LAG, no LACP. 

openvswitch-2.5.0 on Centos-6.2 based Linux

This is the sequence I tried:
   
   - kill (vswitchd's pid)
   - kill (ovsdb-server's pid)   

   - rm -f /usr/local/etc/openvswitch/conf.db
   - rm -f /usr/local/var/run/openvswitch/db.sock
   - ovsdb-tool create /usr/local/etc/openvswitch/conf.db /etc/vswitch.ovsschema
   - ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock 
--remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile
   - ovs-vsctl --no-wait emer-reset
   - ovs-vsctl --no-wait init
   - ovs-vswitchd --pidfile
   - ovs-vsctl add-br br0
   - ovs-vsctl set bridge br0 datapath_type=netdev
   - ovs-vsctl set Bridge br0 mcast_snooping_enable=true
   - ovs-vsctl set Bridge br0 other_config:mcast-snooping-table-size=8192
   - ovs-vsctl --may-exist add-bond br0 bond0 port1 port2 bond_mode=balance-slb 
-- set port bond0 vlan_mode=trunk

In case of regular bootup, only steps 1 and 2 won't be there.
For regular fresh bootup case, I see
ovs-appctl bond/show
 bond0 
bond_mode: balance-slb
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
next rebalance: 8524 ms
lacp_status: off
active slave mac: 00:00:00:00:00:00(port1)

slave port1: enabled
    active slave
    may_enable: true

slave port2: enabled
    may_enable: true

But, if I follow steps 1-14, then I see that bond members are in disabled state:
ovs-appctl bond/show
 bond0 
bond_mode: balance-slb
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
next rebalance: 6582 ms
lacp_status: off
active slave mac: 00:00:00:00:00:00(port2)

slave port1: disabled
    may_enable: false

slave port2: disabled
    may_enable: false

Is there something that I am missing during restart?
-Thanks




 

Sent from Yahoo Mail. Get the app___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] ovs-vswitchd is sucking every cycle (100% CPU usage).

2016-09-15 Thread John Chludzinski 
BTW, when I pulled the plug (literally) on the router, ovs-vswitchd CPU 
usage dropped to <1%.



On 2016-09-16 00:06, John Chludzinski wrote:

I created a bond-port (and enabled LACP):

~# ovs-vsctl add-br b1
~# ovs-vsctl add-bond b1 bd1 enp8s0 enp0s26u1u3u1
~# ovs-vsctl set port bd1 lacp=active

On a CISCO router I connected interfaces: enp8s0 & enp0s26u1u3u1
to ports 2 & 3.

On the CISCO routes I enabled LACP on ports 2 & 3.

Then I ran 'top' and ovs-vswitchd was sucking every cycle (100% CPU 
usage).


I ran:

~# tail -f /var/log/openvswitch/ovs-vswitchd.log

...

2016-09-16T01:54:10.812Z|00408|poll_loop(revalidator12)|INFO|Dropped
24296 log messages in last 6 seconds (most recently, 0 seconds ago)
due to excessive rate
2016-09-16T01:54:10.812Z|00409|poll_loop(revalidator12)|INFO|wakeup
due to [POLLIN] on fd 43 (FIFO pipe:[18987]) at
ofproto/ofproto-dpif-upcall.c:899 (66% CPU usage)
2016-09-16T01:54:16.890Z|00410|poll_loop(revalidator12)|INFO|Dropped
20991 log messages in last 6 seconds (most recently, 1 seconds ago)
due to excessive rate
2016-09-16T01:54:16.890Z|00411|poll_loop(revalidator12)|INFO|wakeup
due to 500-ms timeout at ofproto/ofproto-dpif-upcall.c:898 (55% CPU
usage)
2016-09-16T01:54:22.812Z|00412|poll_loop(revalidator12)|INFO|Dropped
24745 log messages in last 6 seconds (most recently, 0 seconds ago)
due to excessive rate
2016-09-16T01:54:22.812Z|00413|poll_loop(revalidator12)|INFO|wakeup
due to [POLLIN] on fd 43 (FIFO pipe:[18987]) at lib/ovs-thread.c:304
(79% CPU usage)
2016-09-16T01:54:28.812Z|00414|poll_loop(revalidator12)|INFO|Dropped
24821 log messages in last 6 seconds (most recently, 0 seconds ago)
due to excessive rate
2016-09-16T01:54:28.812Z|00415|poll_loop(revalidator12)|INFO|wakeup
due to [POLLIN] on fd 43 (FIFO pipe:[18987]) at lib/ovs-thread.c:304
(66% CPU usage)
2016-09-16T01:54:34.812Z|00043|poll_loop(revalidator13)|INFO|Dropped
26469 log messages in last 6 seconds (most recently, 0 seconds ago)
due to excessive rate

...

Repeated again, and again, and ...


---John
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

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

[ovs-discuss] ovs-vswitchd is sucking every cycle (100% CPU usage).

2016-09-15 Thread John Chludzinski 

I created a bond-port (and enabled LACP):

~# ovs-vsctl add-br b1
~# ovs-vsctl add-bond b1 bd1 enp8s0 enp0s26u1u3u1
~# ovs-vsctl set port bd1 lacp=active

On a CISCO router I connected interfaces: enp8s0 & enp0s26u1u3u1
to ports 2 & 3.

On the CISCO routes I enabled LACP on ports 2 & 3.

Then I ran 'top' and ovs-vswitchd was sucking every cycle (100% CPU 
usage).


I ran:

~# tail -f /var/log/openvswitch/ovs-vswitchd.log

...

2016-09-16T01:54:10.812Z|00408|poll_loop(revalidator12)|INFO|Dropped 
24296 log messages in last 6 seconds (most recently, 0 seconds ago) due 
to excessive rate
2016-09-16T01:54:10.812Z|00409|poll_loop(revalidator12)|INFO|wakeup due 
to [POLLIN] on fd 43 (FIFO pipe:[18987]) at 
ofproto/ofproto-dpif-upcall.c:899 (66% CPU usage)
2016-09-16T01:54:16.890Z|00410|poll_loop(revalidator12)|INFO|Dropped 
20991 log messages in last 6 seconds (most recently, 1 seconds ago) due 
to excessive rate
2016-09-16T01:54:16.890Z|00411|poll_loop(revalidator12)|INFO|wakeup due 
to 500-ms timeout at ofproto/ofproto-dpif-upcall.c:898 (55% CPU usage)
2016-09-16T01:54:22.812Z|00412|poll_loop(revalidator12)|INFO|Dropped 
24745 log messages in last 6 seconds (most recently, 0 seconds ago) due 
to excessive rate
2016-09-16T01:54:22.812Z|00413|poll_loop(revalidator12)|INFO|wakeup due 
to [POLLIN] on fd 43 (FIFO pipe:[18987]) at lib/ovs-thread.c:304 (79% 
CPU usage)
2016-09-16T01:54:28.812Z|00414|poll_loop(revalidator12)|INFO|Dropped 
24821 log messages in last 6 seconds (most recently, 0 seconds ago) due 
to excessive rate
2016-09-16T01:54:28.812Z|00415|poll_loop(revalidator12)|INFO|wakeup due 
to [POLLIN] on fd 43 (FIFO pipe:[18987]) at lib/ovs-thread.c:304 (66% 
CPU usage)
2016-09-16T01:54:34.812Z|00043|poll_loop(revalidator13)|INFO|Dropped 
26469 log messages in last 6 seconds (most recently, 0 seconds ago) due 
to excessive rate


...

Repeated again, and again, and ...


---John
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] native ovs for windows?

2016-09-15 Thread Itamar Ofek 
Hi Nithin,

The use case is to support overlay networks for Windows server containers.


Regards,

Itamar

On Thu, Sep 15, 2016 at 8:52 PM, Nithin Raju  wrote:

> Hi Itamar,
> What is the usecase?
>
> As you know, OVS typically acts as a s/w switch for VMs. What would be a
> good reason to implement OVS in a scenario where there are no VMs running?
> I am curious.
>
> Thanks,
> -- Nithin
>
>
>
> From: discuss  on behalf of Itamar Ofek <
> itamar.o...@gmail.com>
> Date: Wednesday, September 14, 2016 at 4:27 AM
> To: "discuss@openvswitch.org" 
> Subject: [ovs-discuss] native ovs for windows?
>
> Hi all,
>
> Currently OVS under windows is based on hyper-v,
> Has anybody tried to implement OVS as a native windows driver?
>
> Regards,
>
> Itamar
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] mirror ports on multiple bridges - egress problem

2016-09-15 Thread Ben Pfaff 
On Thu, Sep 15, 2016 at 11:05:58AM -0700, Ben Pfaff wrote:
> On Thu, Sep 15, 2016 at 07:52:03AM +, Zoltán Balogh wrote:
> > It seems that for each datapath flow rule, there can be only one mirror 
> > port. 
> > I presume the chosen port could depend on the processing order of output 
> > ports 
> > when the datapath flow is constructed.
> > Is this a planned limitation or a bug?
> 
> It should be possible for a packet to be mirrored multiple times,
> whether on ingress or egress, so this sounds like a bug.  Let me see if
> I can figure anything out.
> 
> From your output it looks like you're working from recent master.  Is
> that correct?

Would you please test this proposed fix?  I have not tested it myself,
except to see that it compiles.

--8<--cut here-->8--

From: Ben Pfaff 
Date: Thu, 15 Sep 2016 11:43:46 -0700
Subject: [PATCH] ofproto-dpif-xlate: Fix treatment of mirrors across patch
 ports.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When the bridges on both sides of a patch port included mirrors, the
translation code incorrectly conflated them instead of treating them as
independent.

Reported-by: Zoltán Balogh 
Reported-at: http://openvswitch.org/pipermail/discuss/2016-September/022689.html
Signed-off-by: Ben Pfaff 
---
 ofproto/ofproto-dpif-xlate.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 6854da3..358edd6 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -2894,7 +2894,6 @@ compose_output_action__(struct xlate_ctx *ctx, ofp_port_t 
ofp_port,
 
 ofpbuf_use_stub(&ctx->stack, new_stack, sizeof new_stack);
 ofpbuf_use_stub(&ctx->action_set, actset_stub, sizeof actset_stub);
-ctx->xbridge = peer->xbridge;
 flow->in_port.ofp_port = peer->ofp_port;
 flow->metadata = htonll(0);
 memset(&flow->tunnel, 0, sizeof flow->tunnel);
@@ -2903,6 +2902,26 @@ compose_output_action__(struct xlate_ctx *ctx, 
ofp_port_t ofp_port,
 ctx->conntracked = false;
 clear_conntrack(flow);
 
+/* When the patch port points to a different bridge, then the mirrors
+ * for that bridge clearly apply independently to the packet, so we
+ * reset the mirror bitmap to zero and then restore it after the packet
+ * returns.
+ *
+ * When the patch port points to the same bridge, this is more of a
+ * design decision: can mirrors be re-applied to the packet after it
+ * re-enters the bridge, or should we treat that as doubly mirroring a
+ * single packet?  The former may be cleaner, since it respects the
+ * model in which a patch port is like a physical cable plugged from
+ * one switch port to another, but the latter may be less surprising to
+ * users.  We take the latter choice, for now at least.  (To use the
+ * former choice, hard-code 'independent_mirrors' to "true".) */
+mirror_mask_t old_mirrors = ctx->mirrors;
+bool independent_mirrors = peer->xbridge != ctx->xbridge;
+if (independent_mirrors) {
+ctx->mirrors = 0;
+}
+ctx->xbridge = peer->xbridge;
+
 /* The bridge is now known so obtain its table version. */
 ctx->xin->tables_version
 = ofproto_dpif_get_tables_version(ctx->xbridge->ofproto);
@@ -2921,10 +2940,10 @@ compose_output_action__(struct xlate_ctx *ctx, 
ofp_port_t ofp_port,
  * the learning action look at the packet, then drop it. */
 struct flow old_base_flow = ctx->base_flow;
 size_t old_size = ctx->odp_actions->size;
-mirror_mask_t old_mirrors = ctx->mirrors;
+mirror_mask_t old_mirrors2 = ctx->mirrors;
 
 xlate_table_action(ctx, flow->in_port.ofp_port, 0, true, true);
-ctx->mirrors = old_mirrors;
+ctx->mirrors = old_mirrors2;
 ctx->base_flow = old_base_flow;
 ctx->odp_actions->size = old_size;
 
@@ -2933,6 +2952,9 @@ compose_output_action__(struct xlate_ctx *ctx, ofp_port_t 
ofp_port,
 }
 }
 
+if (independent_mirrors) {
+ctx->mirrors = old_mirrors;
+}
 ctx->xin->flow = old_flow;
 ctx->xbridge = xport->xbridge;
 ofpbuf_uninit(&ctx->action_set);
-- 
2.1.3

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

Re: [ovs-discuss] mirror ports on multiple bridges - egress problem

2016-09-15 Thread Ben Pfaff 
On Thu, Sep 15, 2016 at 07:52:03AM +, Zoltán Balogh wrote:
> It seems that for each datapath flow rule, there can be only one mirror port. 
> I presume the chosen port could depend on the processing order of output 
> ports 
> when the datapath flow is constructed.
> Is this a planned limitation or a bug?

It should be possible for a packet to be mirrored multiple times,
whether on ingress or egress, so this sounds like a bug.  Let me see if
I can figure anything out.

From your output it looks like you're working from recent master.  Is
that correct?
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] native ovs for windows?

2016-09-15 Thread Nithin Raju 
Hi Itamar,
What is the usecase?

As you know, OVS typically acts as a s/w switch for VMs. What would be a good 
reason to implement OVS in a scenario where there are no VMs running? I am 
curious.

Thanks,
-- Nithin



From: discuss 
mailto:discuss-boun...@openvswitch.org>> on 
behalf of Itamar Ofek mailto:itamar.o...@gmail.com>>
Date: Wednesday, September 14, 2016 at 4:27 AM
To: "discuss@openvswitch.org" 
mailto:discuss@openvswitch.org>>
Subject: [ovs-discuss] native ovs for windows?

Hi all,

Currently OVS under windows is based on hyper-v,
Has anybody tried to implement OVS as a native windows driver?

Regards,

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

[ovs-discuss] Fw: Errors while installing in dpdk in ubuntu 14.04

2016-09-15 Thread Poonam Ghosh 
***Sending the mail on behalf of Lakshmi*

Topology is 2 Simple ports with a Single Bridge  as shown below (with OVS 
and DPDK installed on Ubuntu 14.04):

ovs-vsctl add-br bridge0 -- set bridge bridge0 datapath_type=netdev
ovs-vsctl add-port bridge0 dpdk0 -- set Interface dpdk0 type=dpdk
ovs-vsctl add-port bridge0 dpdk1 -- set Interface dpdk1 type=dpdk

Error what we see here :
Bridge "bridge0"
Port "dpdk0"
Interface "dpdk0"
type: dpdk
error: "could not open network device dpdk0 (Address 
family not supported by protocol)" 
Port "dpdk1"
Interface "dpdk1"
type: dpdk
error: "could not open network device dpdk1 (Address 
family not supported by protocol)"


Same Topology with OVS-DPDK package installed on Ubuntu 16.04:

 ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev 


ovs-vsctl add-port br0 vhost-user1 -- set Interface vhost-user1 
type=dpdkvhostuser 


ovs-vsctl add-port br0 vhost-user2 -- set Interface vhost-user2 
type=dpdkvhostuser

Error which we see here is : "qemu-system-x86_64: -object
memory-backend-file,id=mem,size=512M,mem-path=/dev/hugepages,share=on:
unable to map backing store for hugepages:  




We need to understand if there is something which is missed as part of the 
Hugepages configuration for both the above installations. Or do you have a 
better Solution to deal with such basic topologies with DPDK.

Thanks




From:   Mauricio Vasquez 
To: Lakshmi Kotla/HYD/TCS , 
b...@openvswitch.org
Cc: poonam.gh...@tcs.com
Date:   09/14/2016 11:12 AM
Subject:Re: [ovs-discuss] Errors while installing in dpdk in 
ubuntu 14.04



Hello, 
What are you exactly trying to do?, I mean, what topology do you want to 
create?

On 09/14/2016 12:02 PM, Lakshmi Kotla/HYD/TCS wrote:
First of all thanks for replying to this
thread, Mauricio.

To give a gist of the activities done
for OVS-DPDK installation , here are the details:

1. As part of the Installation guide
( https://github.com/openvswitch/ovs/blob/master/INSTALL.DPDK.md
) we started with installing / Configuring DPDK Target 
followed with the OVS
installation/configuration and compiling binded with the DPDK Target as
been explained in the above reference File.

.P.S. There were no issues seen while
configuring OVS with DPDK .

2. As we understand from the Configuration
file " $DPDK_DIR/config/common_linuxapp " VHOST_USER is support
for the DPDK 

CONFIG_RTE_LIBRTE_VHOST=y`

CONFIG_RTE_LIBRTE_VHOST_USER=y

ovs-vsctl add-br bridge0 -- set bridge bridge0 datapath_type=netdev

ovs-vsctl add-port bridge0 dpdk0 -- set Interface dpdk0 type=dpdk

ovs-vsctl add-port bridge0 dpdk1 -- set Interface dpdk1 type=dpdk

With those commands you are adding physical ports to the bridge. Is it 
what you want to do?

So in order to test the given topology
with the a 2 port on a single bridge and got the following errors as shown
below :
Bridge "bridge0"

Port "dpdk0"

Interface "dpdk0"

type: dpdk

error: "could
not open network device dpdk0 (Address family not supported by protocol)"


Port "dpdk1"

Interface "dpdk1"

type: dpdk

error: "could
not open network device dpdk1 (Address family not supported by protocol)"

3. Referred webpage(
https://software.intel.com/en-us/blogs/2015/06/09/building-vhost-user-for-ovs-today-using-dpdk-200
)
to overcome this issue on the DPDK dependency with the Kernel modules but
it is still not yet resolved. 

4. Secondly i have upgraded my Linux
Container (Ubuntu 16.04) and installed the default package : 
openvswitch-switch-dpdkto leverage the application
to work with DPDK.
Referred the following
link to create the VM's using the QEMU-KVM applications : 
https://software.intel.com/en-us/articles/using-open-vswitch-with-dpdk-on-ubuntu


With this the VHOST-USER's are getting
created successfully as expected but on creating the VM's currently 
encountered
with the following Error:

 "qemu-system-x86_64: -object
memory-backend-file,id=mem,size=512M,mem-path=/dev/hugepages,share=on:
unable to map backing store for hugepages:  


> Command issued :sudo qemu-system-x86_64 -m 512
-smp 4 -cpu host -hda /home/user/f21vm1c1.qcow2 -boot c -enable-kvm 
-no-reboot
-nographic -net none -chardev 
socket,id=char1,path=/run/openvswitch/vhost-user1
-netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce -device 
virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1
-device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1 -object 
memory-backend-file,id=mem,size=512M,mem-path=/dev/hugepages,share=on
-numa node,memdev=mem -mem-prealloc   


P.S. We have increased the Hugepages accordingly but the issue isn't 
resolved
yet. 


Could you provide more information or some
relevant links so that we can create the required Topology with DPDK 
package
(with manual Installation as done in Step -1 to 3) 
or there is a

[ovs-discuss] Fwd: Re: Errors while installing in dpdk in ubuntu 14.04

2016-09-15 Thread Lakshmi Kotla/HYD/TCS 
Topology is 2 Simple ports with a Single
Bridge  as shown below (with OVS and DPDK installed on Ubuntu 14.04):

ovs-vsctl add-br bridge0
-- set bridge bridge0 datapath_type=netdev

ovs-vsctl add-port bridge0 dpdk0 -- set Interface dpdk0 type=dpdk

ovs-vsctl add-port bridge0 dpdk1 -- set Interface dpdk1 type=dpdk

Error what we see here :
Bridge "bridge0"

Port "dpdk0"

Interface "dpdk0"

type: dpdk

error: "could
not open network device dpdk0 (Address family not supported by protocol)"


Port "dpdk1"

Interface "dpdk1"

type: dpdk

error: "could
not open network device dpdk1 (Address family not supported by protocol)"


Same Topology with OVS-DPDK package
installed on Ubuntu 16.04:
 ovs-vsctl
add-br br0 -- set bridge br0 datapath_type=netdev 
ovs-vsctl
add-port br0 vhost-user1 -- set Interface vhost-user1 type=dpdkvhostuser

ovs-vsctl
add-port br0 vhost-user2 -- set Interface vhost-user2 type=dpdkvhostuser

Error which we see here is : "qemu-system-x86_64:
-object

memory-backend-file,id=mem,size=512M,mem-path=/dev/hugepages,share=on:

unable to map backing store for hugepages:  




We need to understand if there is something
which is missed as part of the Hugepages configuration for both the above
installations. Or do you have a better Solution to deal with such basic
topologies with DPDK.

Thanks




From:  
 Mauricio Vasquez 
To:  
 Lakshmi Kotla/HYD/TCS
, b...@openvswitch.org
Cc:  
 poonam.gh...@tcs.com
Date:  
 09/14/2016 11:12 AM
Subject:
   Re: [ovs-discuss]
Errors while installing in dpdk in ubuntu 14.04



=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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

Re: [ovs-discuss] output port in another openvswitch

2016-09-15 Thread madhu 

Thanks Justin for your reply.

On 15-09-2016 12:47, Justin Pettit wrote:

On Sep 14, 2016, at 11:20 PM, madhu  wrote:

Hi All,

Is it possible to set the output port to port in another openvswitch present in 
another compute node of openstack?

If so how the packet traverses from one openvswitch to another openvswitch in 
another node?

Is it through the overlay/underlay networks?

Can anybody paste me a sample flow rule for this?

There are some examples of people setting up tunnels to do this if you search 
around.  If you're looking for something more robust and complete, you might 
check out OVN, which works with OVS and has OpenStack bindings.  It will be 
part of the OVS 2.6 release.

--Justin





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

[ovs-discuss] mirror ports on multiple bridges - egress problem

2016-09-15 Thread Zoltán Balogh 
Hi,

I'm testing a multiple bridge setup with a mirror port on each bridge. The 
bridges are connected with patch ports. Here is a figure:

+-+
  LOCAL | o--+  patch-in-p3
--->obr-ino+ |  patch-in-p2 
| o--+ | |  patch-in-p1 
+-+  | | +--+
 | ++   |
 |  |   |
 |  |   |
 |  |   |
 |  |   |
 patch-p1-in |  | patch-p2-in   | patch-p3-in
 +---o-+ +--o--+ +--o--+
 | | | | | |
  ---obr-p1|  ---obr-p2|  ---obr-p3|
  m-eth4 | |  m-eth5 | |  m-eth1 | |
 +--o--+ +--o--+ +--o--+
   eth4 |  eth5 |  eth1 |
|   |   | 


The mirror ports are used to mirror traffic flowing through the physical ports. 
It seems that mirroring works for all physical ports in ingress direction, but 
it works only for one port in egress direction.

This is the output of 'ovs-appctl dpctl/show':

system@ovs-system:
lookups: hit:17 missed:34 lost:0
flows: 0
masks: hit:19 total:0 hit/pkt:0.37
port 0: ovs-system (internal)
port 1: br-in (internal)
port 2: br-p1 (internal)
port 3: br-p2 (internal)
port 4: br-p3 (internal)
port 5: eth4
port 6: m-eth4 (internal)
port 7: eth5
port 8: m-eth5 (internal)
port 9: eth1
port 10: m-eth1 (internal)


I injected packets to LOCAL port of br-in, these were routed by OF rules 
towards the physical ports on br-p1, br-p2 and br-p3. Before I configured
any mirror port, the datapath had this flow entry:

recirc_id(0),in_port(1),eth(src=00:00:00:11:22:33),eth_type(0x0800),ipv4(src=1.1.1.1,ttl=255,frag=no),
 packets:63, bytes:4032, used:0.628s, 
actions:set(eth(src=de:ad:de:af:be:ef)),7,set(eth(src=00:00:00:11:22:33)),set(ipv4(src=222.175.190.239)),9,set(ipv4(src=1.1.1.1,ttl=254)),push_vlan(vid=100,pcp=0),5


First, I configured m-eth4 as a mirror port on br-p1. At this point mirroring 
did work fine in egress direction. Port 6 (m-eth4) was added to the datapath 
flow. This was the output of 'ovs-appctl dpctl/dump-flows':

recirc_id(0),in_port(1),eth(src=00:00:00:11:22:33),eth_type(0x0800),ipv4(src=1.1.1.1,ttl=255,frag=no),
 packets:132, bytes:8448, used:0.056s, 
actions:set(eth(src=de:ad:de:af:be:ef)),7,set(eth(src=00:00:00:11:22:33)),set(ipv4(src=222.175.190.239)),9,set(ipv4(src=1.1.1.1,ttl=254)),push_vlan(vid=100,pcp=0),5,6


Then, I configured m-eth5 as a mirror port on br-p1. At this point mirroring 
stopped working on m-eth4 in egress direction but was working on m-eth5.
Port 8 was added to the datapath rule but port 6 (m-eth4) was removed. This 
was the output of 'ovs-appctl dpctl/dump-flows':

recirc_id(0),in_port(1),eth(src=00:00:00:11:22:33),eth_type(0x0800),ipv4(src=1.1.1.1,ttl=255,frag=no),
 packets:187, bytes:11968, used:0.852s, 
actions:set(eth(src=de:ad:de:af:be:ef)),7,8,set(eth(src=00:00:00:11:22:33)),set(ipv4(src=222.175.190.239)),9,set(ipv4(src=1.1.1.1,ttl=254)),push_vlan(vid=100,pcp=0),5


Finally, I configured the 3rd mirror port (m-eth1) on br-p3. At this point 
mirroring worked on m-eth5 in egress direction, but did not work on any of the 
other two mirror ports (m-eth4, m-eth1) in egress direction. The output of 
'ovs-appctl dpclt/dump-flow' was the same as before.

recirc_id(0),in_port(1),eth(src=00:00:00:11:22:33),eth_type(0x0800),ipv4(src=1.1.1.1,ttl=255,frag=no),
 packets:298, bytes:19072, used:0.564s, 
actions:set(eth(src=de:ad:de:af:be:ef)),7,8,set(eth(src=00:00:00:11:22:33)),set(ipv4(src=222.175.190.239)),9,set(ipv4(src=1.1.1.1,ttl=254)),push_vlan(vid=100,pcp=0),5


In ingress direction, mirroring did work for all three physical ports. The 
output of 'ovs-appctl dpctl/dump-flows' was:

recirc_id(0),in_port(9),eth_type(0x0800),ipv4(frag=no), packets:72, bytes:6276, 
used:0.704s, actions:10
recirc_id(0),in_port(5),eth_type(0x0800),ipv4(frag=no), packets:55, bytes:3520, 
used:0.848s, actions:6
recirc_id(0),in_port(7),eth_type(0x0800),ipv4(frag=no), packets:48, bytes:3072, 
used:0.752s, actions:8


It seems that for each datapath flow rule, there can be only one mirror port. 
I presume the chosen port could depend on the processing order of output ports 
when the datapath flow is constructed.
Is this a planned limitation or a bug?

Here are the co

Re: [ovs-discuss] Port number of tap interface changes after reboot.

2016-09-15 Thread madhu 

Thanks Justin will try your suggestion.

On 15-09-2016 12:51, Justin Pettit wrote:

On Sep 14, 2016, at 11:16 PM, madhu  wrote:

Hi All,

I have a situation where the port number associated with the tap interface of a 
VM changes after the VM reboot.

1. My setup is I have a VM deployed in openstack.

2. VM is connected through tap interface to the openvswitch in compute node.

3. openvswitch is controlled by opendaylight controller.

Whenever the VM is rebooted the port number associated with the tap interface 
changes in the openvswitch.

Is the above behavior normal ? or my openstack or opendaylight configuration 
has got something to do with this behavior?

I have also observed the port numbers of all the tap interfaces in the 
openvswitch changes when I restart the compute node.

By default, the port number will depend on the order the interfaces are added.  If you 
have stable tap interface names, you could look at populating "ofport_request" 
column as described in the ovs-vswitchd.conf.db man page.

--Justin





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

Re: [ovs-discuss] Port number of tap interface changes after reboot.

2016-09-15 Thread Justin Pettit 

> On Sep 14, 2016, at 11:16 PM, madhu  wrote:
> 
> Hi All,
> 
> I have a situation where the port number associated with the tap interface of 
> a VM changes after the VM reboot.
> 
> 1. My setup is I have a VM deployed in openstack.
> 
> 2. VM is connected through tap interface to the openvswitch in compute node.
> 
> 3. openvswitch is controlled by opendaylight controller.
> 
> Whenever the VM is rebooted the port number associated with the tap interface 
> changes in the openvswitch.
> 
> Is the above behavior normal ? or my openstack or opendaylight configuration 
> has got something to do with this behavior?
> 
> I have also observed the port numbers of all the tap interfaces in the 
> openvswitch changes when I restart the compute node.

By default, the port number will depend on the order the interfaces are added.  
If you have stable tap interface names, you could look at populating 
"ofport_request" column as described in the ovs-vswitchd.conf.db man page.

--Justin


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

Re: [ovs-discuss] output port in another openvswitch

2016-09-15 Thread Justin Pettit 

> On Sep 14, 2016, at 11:20 PM, madhu  wrote:
> 
> Hi All,
> 
> Is it possible to set the output port to port in another openvswitch present 
> in another compute node of openstack?
> 
> If so how the packet traverses from one openvswitch to another openvswitch in 
> another node?
> 
> Is it through the overlay/underlay networks?
> 
> Can anybody paste me a sample flow rule for this?

There are some examples of people setting up tunnels to do this if you search 
around.  If you're looking for something more robust and complete, you might 
check out OVN, which works with OVS and has OpenStack bindings.  It will be 
part of the OVS 2.6 release.

--Justin


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