[ovs-dev] IPFIX crash

2017-04-04 Thread Neelakantam Gaddam
Hi All,

While testing the IPFIX feature with openvswitch-2.6.1, observed the below
crash when traffic is on.

[  347.143417] BUG: unable to handle kernel NULL pointer dereference
at   (null)
[  347.143452] IP: [] dst_cache_get_ip4+0xc/0x50 [openvswitch]
[  347.143484] PGD 0
[  347.143493] Oops:  [#1] SMP
[  347.143506] Modules linked in: vhost_net vhost macvtap macvlan
vport_geneve(OE) vport_gre(OE) vport_vxlan(OE) openvswitch(OE)
nf_conntrack_ipv6 nf_nat_ipv6 nf_defrag_ipv6 geneve gre libcrc32c
xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
xt_conntrack nf_conntrack ipt_REJECT tun bridge stp llc ebtable_filter
ebtables ip6table_filter ip6_tables iptable_filter fuse dm_mirror
dm_region_hash dm_log dm_mod intel_powerclamp coretemp intel_rapl
kvm_intel ixgbe(OE) kvm iTCO_wdt crc32_pclmul ipmi_ssif ipmi_devintf
iTCO_vendor_support ses ghash_clmulni_intel enclosure ipmi_si vxlan
ip6_udp_tunnel udp_tunnel aesni_intel mei_me sg sb_edac dcdbas
edac_core lpc_ich mei shpchp wmi mfd_core acpi_power_meter lrw
gf128mul glue_helper
[  347.143809]  ablk_helper cryptd pcspkr ipmi_msghandler nfsd
auth_rpcgss nfs_acl lockd grace sunrpc ip_tables ext4 mbcache jbd2
sr_mod cdrom sd_mod crc_t10dif crct10dif_generic mgag200 syscopyarea
sysfillrect sysimgblt drm_kms_helper ttm crct10dif_pclmul drm
crct10dif_common ahci crc32c_intel libahci igb dca libata i2c_algo_bit
ptp i2c_core megaraid_sas pps_core [last unloaded: liquidio_ovs]
[  347.143960] CPU: 4 PID: 3818 Comm: vhost-3811 Tainted: G
OE     3.10.0-327.el7.x86_64 #1
[  347.143993] Hardware name: Dell Inc. PowerEdge T630/0W9WXC, BIOS
1.1.4 11/04/2014
[  347.144019] task: 880847ec1700 ti: 8808516f8000 task.ti:
8808516f8000
[  347.144043] RIP: 0010:[]  []
dst_cache_get_ip4+0xc/0x50 [openvswitch]
[  347.144079] RSP: 0018:8808516fb5d8  EFLAGS: 00010246
[  347.144097] RAX:  RBX: 880849023210 RCX: 880849023208
[  347.144120] RDX:  RSI: 880849023210 RDI: 
[  347.144144] RBP: 8808516fb5e8 R08: 0a04a8c0 R09: 880849023210
[  347.144167] R10: 880849023e00 R11: 8808516fb890 R12: 
[  347.144190] R13: 8800784d8c00 R14:  R15: 8808514568f8
[  347.144214] FS:  () GS:88085e48()
knlGS:
[  347.144240] CS:  0010 DS:  ES:  CR0: 80050033
[  347.144259] CR2:  CR3: 00081c865000 CR4: 001427e0
[  347.144283] DR0:  DR1:  DR2: 
[  347.144306] DR3:  DR6: 0ff0 DR7: 0400
[  347.144329] Stack:
[  347.144337]  880849023210  8808516fb658
a04f6b0a
[  347.144365]  0a04a8c04d5e1de0 8800 8808516fb658
81524289
[  347.144393]  020e0e0e6400 030e0e0e 80da67a9
880849023208
[  347.144421] Call Trace:
[  347.144436]  []
vxlan_get_route.isra.41+0xea/0x130 [openvswitch]
[  347.144464]  [] ? __skb_get_hash+0x39/0x160
[  347.144487]  []
ovs_vxlan_fill_metadata_dst+0x170/0x1e0 [openvswitch]
[  347.144517]  []
ovs_dev_fill_metadata_dst+0x9e/0xd0 [openvswitch]
[  347.144544]  [] output_userspace+0xfe/0x180 [openvswitch]
[  347.144569]  [] do_execute_actions+0x63d/0x8f0
[openvswitch]
[  347.144594]  [] ovs_execute_actions+0x41/0x130
[openvswitch]
[  347.145578]  [] ovs_dp_process_packet+0x94/0x140
[openvswitch]
[  347.146549]  [] ovs_vport_receive+0x73/0xd0 [openvswitch]
[  347.147510]  [] ? enqueue_task_fair+0x402/0x6c0
[  347.148470]  [] ? sched_clock_cpu+0x85/0xc0
[  347.149432]  [] ? check_preempt_curr+0x75/0xa0
[  347.150378]  [] ? ttwu_do_wakeup+0x19/0xd0
[  347.151316]  [] ? ttwu_do_activate.constprop.84+0x5d/0x70
[  347.152249]  [] ? try_to_wake_up+0x1b6/0x300
[  347.153168]  [] ? __wake_up+0x44/0x50
[  347.154090]  [] internal_dev_xmit+0x24/0x60 [openvswitch]
[  347.155012]  [] dev_hard_start_xmit+0x171/0x3b0
[  347.155919]  [] sch_direct_xmit+0x104/0x200
[  347.156800]  [] dev_queue_xmit+0x236/0x570
[  347.157662]  [] macvlan_start_xmit+0x3c/0xc0 [macvlan]
[  347.158503]  [] dev_hard_start_xmit+0x171/0x3b0
[  347.159327]  [] sch_direct_xmit+0x104/0x200
[  347.160127]  [] dev_queue_xmit+0x236/0x570
[  347.160901]  [] macvtap_get_user+0x414/0x720 [macvtap]
[  347.161658]  [] macvtap_sendmsg+0x2b/0x30 [macvtap]
[  347.162391]  [] handle_tx+0x2fc/0x550 [vhost_net]
[  347.163111]  [] handle_tx_kick+0x15/0x20 [vhost_net]
[  347.163807]  [] vhost_worker+0xfb/0x1e0 [vhost]
[  347.164489]  [] ? vhost_dev_reset_owner+0x50/0x50 [vhost]
[  347.165165]  [] kthread+0xcf/0xe0
[  347.165826]  [] ? kthread_create_on_node+0x140/0x140
[  347.166482]  [] ret_from_fork+0x58/0x90
[  347.167131]  [] ? kthread_create_on_node+0x140/0x140
[  347.167784] Code: 65 48 03 34 25 e8 ce 00 00 48 83 c7 08 e8 4d ff
ff ff 5d c3 0f 1f 00 31 c0 c3 0f 1f 44 

Re: [ovs-dev] [PATCH ovs V6 00/24] Introducing HW offload support for openvswitch

2017-04-04 Thread Roi Dayan



On 04/04/2017 21:40, Joe Stringer wrote:

On 4 April 2017 at 06:21, Paul Blakey  wrote:



On 03/04/2017 21:00, Joe Stringer wrote:


On 1 April 2017 at 20:50, Roi Dayan  wrote:




On 31/03/2017 01:11, Marcelo Ricardo Leitner wrote:



On Thu, Mar 30, 2017 at 03:43:36PM -0300, Marcelo Ricardo Leitner wrote:



On Wed, Mar 29, 2017 at 03:43:10PM +0300, Roi Dayan wrote:



This patch series introduces rule offload functionality to
dpif-netlink
via netdev ports new flow offloading API. The user can specify whether
to
enable rule offloading or not via OVS configuration. Netdev providers
are able to implement netdev flow offload API in order to offload
rules.

This patch series also implements one offload scheme for netdev-linux,
using TC flower classifier, which was chosen because its sort of
natural
to state OVS DP rules for this classifier. However, the code can be
extended to support other classifiers such as U32, eBPF, etc which
support
offload as well.

The use-case we are currently addressing is the newly sriov switchdev
mode
in the Linux kernel which was introduced in version 4.8 [1][2].
This series was tested against sriov vfs vports representors of the
Mellanox 100G ConnectX-4 series exposed by the mlx5 kernel driver.


V5->V6:
- Rebase over master branch, fix compilation issue
- Add Nicira copyright to tc interface




Hi,

I built rpm packages based on OVS upstream commit 36664f336664. Then I




Please s/36664f336664/36664f377d048/g in this email.
This was the commit used as base for the test:
commit 36664f377d04857256c1d8582057e1cf3e0e3923
Author: Ben Pfaff 
Date:   Mon Mar 20 10:56:22 2017 -0700

ovsdb-server: Drop unnecessary find_db() function.

Thanks


built a new set of packages with this patchset, v6, applied.

When offloading is enabled, the rules are merged in an unexpected way.
See the results below from the two scenarios.

openvswitch-2.7.90-1.fc24.36664f336664.x86_64.rpm
   upstream ovs commit

[root@wsfd-netdev36 ~]# ovs-ofctl dump-flows ovs_pvp_br0
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=12.501s, table=0, n_packets=1022759,
n_bytes=61365540, idle_age=0,
ip,in_port=1,nw_src=16.0.0.1,nw_dst=1.0.0.1
actions=output:2
 cookie=0x0, duration=12.501s, table=0, n_packets=1020990,
n_bytes=61259400, idle_age=0,
ip,in_port=1,nw_src=16.0.0.2,nw_dst=1.0.0.2
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1023860,
n_bytes=61431600, idle_age=0,
ip,in_port=1,nw_src=16.0.0.3,nw_dst=1.0.0.3
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1022554,
n_bytes=61353240, idle_age=0,
ip,in_port=1,nw_src=16.0.0.4,nw_dst=1.0.0.4
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1021516,
n_bytes=61290960, idle_age=0,
ip,in_port=1,nw_src=16.0.0.5,nw_dst=1.0.0.5
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1020599,
n_bytes=61235940, idle_age=0,
ip,in_port=1,nw_src=16.0.0.6,nw_dst=1.0.0.6
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1022285,
n_bytes=61337100, idle_age=0,
ip,in_port=1,nw_src=16.0.0.7,nw_dst=1.0.0.7
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1021725,
n_bytes=61303500, idle_age=0,
ip,in_port=1,nw_src=16.0.0.8,nw_dst=1.0.0.8
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1022281,
n_bytes=61336860, idle_age=0,
ip,in_port=1,nw_src=16.0.0.9,nw_dst=1.0.0.9
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1022449,
n_bytes=61346940, idle_age=0,
ip,in_port=1,nw_src=16.0.0.10,nw_dst=1.0.0.10
actions=output:2
 cookie=0x0, duration=12.208s, table=0, n_packets=2580, n_bytes=154800,
idle_age=0, ip,in_port=2,nw_src=16.0.0.1,nw_dst=1.0.0.1
actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2675, n_bytes=160500,
idle_age=0, ip,in_port=2,nw_src=16.0.0.2,nw_dst=1.0.0.2
actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2520, n_bytes=151200,
idle_age=0, ip,in_port=2,nw_src=16.0.0.3,nw_dst=1.0.0.3
actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2587, n_bytes=155220,
idle_age=0, ip,in_port=2,nw_src=16.0.0.4,nw_dst=1.0.0.4
actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2640, n_bytes=158400,
idle_age=0, ip,in_port=2,nw_src=16.0.0.5,nw_dst=1.0.0.5
actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2593, n_bytes=155580,
idle_age=0, ip,in_port=2,nw_src=16.0.0.6,nw_dst=1.0.0.6
actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2634, n_bytes=158040,
idle_age=0, ip,in_port=2,nw_src=16.0.0.7,nw_dst=1.0.0.7
actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2549, n_bytes=152940,
idle_age=0, ip,in_port=2,nw_src=16.0.0.8,nw_dst=1.0.0.8
actions=output:1
 cookie=0x0, duration=12.207s, table=0, n_packets=2627, n_bytes=157620,
idle_age=0, ip,in_port=2,nw_src=16.0.0.9,nw_dst=1.0.0.9
actions=output:1
 cookie=0x0, duration=12.207s, table=0, 

Re: [ovs-dev] [PATCH ovs V6 22/24] tests: Add system-offloads-testsuite

2017-04-04 Thread Roi Dayan



On 04/04/2017 23:47, Joe Stringer wrote:

On 29 March 2017 at 05:43, Roi Dayan  wrote:

From: Paul Blakey 

The new system-offloads-testsuite, which can be launched via
`make check-offloads`, tests offloading capabilities
to makes sure that certian flows are actually offloaded.

The tests run on virtual netdevices (VETH).

Signed-off-by: Paul Blakey 
Reviewed-by: Roi Dayan 
Reviewed-by: Simon Horman 
---
 tests/.gitignore   |  1 +
 tests/automake.mk  | 16 +
 tests/ofproto-macros.at|  6 ++--
 tests/system-offloaded-traffic.at  | 67 ++
 tests/system-offloads-testsuite.at | 25 ++
 5 files changed, 113 insertions(+), 2 deletions(-)
 create mode 100644 tests/system-offloaded-traffic.at
 create mode 100644 tests/system-offloads-testsuite.at


Is there a reason that some tests/ files are system-offloads-* and
some are system-offloaded-*? Can we make them use the same prefix?



typo. will fix. thanks.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH ovs V5 00/24] Introducing HW offload support for openvswitch

2017-04-04 Thread Roi Dayan



On 04/04/2017 23:53, Joe Stringer wrote:

On 3 April 2017 at 10:53, Joe Stringer  wrote:

On 3 April 2017 at 03:27, Roi Dayan  wrote:



On 29/03/2017 20:13, Joe Stringer wrote:


On 29 March 2017 at 04:50, Roi Dayan  wrote:




On 23/03/2017 09:01, Joe Stringer wrote:



I ran the make check-offloads tests on a recent net-next kernel and it
failed, output was not as expected:

../../tests/system-offloaded-traffic.at:54
: ovs-appctl dpctl/dump-flows |
grep "eth_type(0x0800)" | sed -e


's/used:[0-9].[0-9]*s/used:0.001s/;s/eth(src=[a-z0-9:]*,dst=[a-z0-9:]*)/eth(mac
s)/;s/actions:[0-9,]*/actions:output/;s/recirc_id(0),//' | sort
--- - 2017-03-22 16:43:37.598689692 -0700
+++


/home/vagrant/ovs/_build-clang/tests/system-offloads-testsuite.dir/at-groups/2/stdout
2017-03-22 16:43:37.595628000 -0700
@@ -1,3 +1,3 @@
-in_port(2),eth(macs),eth_type(0x0800), packets:9, bytes:756,
used:0.001s, actions:output
-in_port(3),eth(macs),eth_type(0x0800), packets:9, bytes:756,
used:0.001s, actions:output
+in_port(2),eth(macs),eth_type(0x0800),ipv4(frag=no), packets:9,
bytes:882, used:0.001s, actions:output
+in_port(3),eth(macs),eth_type(0x0800),ipv4(frag=no), packets:9,
bytes:882, used:0.001s, actions:output



Hi Joe,

can you tell me what kernel you used here?
maybe tc offloads were not supported and there was a fallback to OVS dp.



I believe that it was a snapshot of net-next relatively recently,
01461abe62df ("Merge branch 'fib-notifications-cleanup'"). I could try
again with latest net-next? Or do you think there may be some
userspace dependency the test relies on?



I installed net-next kernel and make check-offloads pass for me.
The last commit I'm on is
397df70 Merge branch '40GbE' of
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
last tag is 4.11-rc3+
I'm thinking maybe the test fails for you from something else like a second
openvswitch process running already?


I don't think that was the case, but let me try again with your latest
series and the above commit.


I saw the same behaviour with upstream net-next 397df7092a15. My host
is Ubuntu 14.04 with this kernel.

I thought it might be because I'm not running any of your hardware and
I assumed that the testsuite doesn't require hardware to run. Looking
at the test it seems that assumption was wrong, but when I tried to
configure the tc-policy to skip_hw with the following modification,
the OVSDB change didn't seem to propagate into OVS (there were no log
messages about changing the tc-policy):

diff --git a/tests/system-offloaded-traffic.at
b/tests/system-offloaded-traffic.at
index 7aec8a3f430e..3ddf23a939a8 100644
--- a/tests/system-offloaded-traffic.at
+++ b/tests/system-offloaded-traffic.at
@@ -40,6 +40,7 @@ AT_SETUP([offloads - ping between two ports -
offloads enabled])
OVS_TRAFFIC_VSWITCHD_START()

AT_CHECK([ovs-vsctl set Open_vSwitch . other_config:hw-offload=true])
+AT_CHECK([ovs-vsctl set Open_vSwitch . other_config:tc-policy="skip_hw"])
AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"])

ADD_NAMESPACES(at_ns0, at_ns1)

---

Looking again, my kernel config had CLS_FLOWER disabled so that's
probably what caused the issue. My ovs-vswitchd log from the test is
below.

2017-04-04T20:41:50.737Z|1|vlog|INFO|opened log file
/home/joe/git/openvswitch/_build-gcc/tests/system-offloads-testsuite.dir/2/ovs-vswitchd.log
2017-04-04T20:41:50.737Z|2|ovs_numa|INFO|Discovered 2 CPU cores on
NUMA node 0
2017-04-04T20:41:50.737Z|3|ovs_numa|INFO|Discovered 1 NUMA nodes
and 2 CPU cores
2017-04-04T20:41:50.738Z|4|reconnect|INFO|unix:/home/joe/git/openvswitch/_build-gcc/tests/system-offloads-testsuite.dir/2/db.sock:
connecting...
2017-04-04T20:41:50.738Z|5|reconnect|INFO|unix:/home/joe/git/openvswitch/_build-gcc/tests/system-offloads-testsuite.dir/2/db.sock:
connected
2017-04-04T20:41:50.743Z|6|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.7.90
2017-04-04T20:41:50.757Z|7|ofproto_dpif|INFO|system@ovs-system:
Datapath supports recirculation
2017-04-04T20:41:50.757Z|8|ofproto_dpif|INFO|system@ovs-system:
MPLS label stack length probed as 1
2017-04-04T20:41:50.757Z|9|ofproto_dpif|INFO|system@ovs-system:
Datapath supports truncate action
2017-04-04T20:41:50.757Z|00010|ofproto_dpif|INFO|system@ovs-system:
Datapath supports unique flow ids
2017-04-04T20:41:50.757Z|00011|ofproto_dpif|INFO|system@ovs-system:
Datapath does not support clone action
2017-04-04T20:41:50.757Z|00012|ofproto_dpif|INFO|system@ovs-system:
Max sample nesting level probed as 10
2017-04-04T20:41:50.757Z|00013|ofproto_dpif|INFO|system@ovs-system:
Datapath supports ct_state
2017-04-04T20:41:50.757Z|00014|ofproto_dpif|INFO|system@ovs-system:
Datapath supports ct_zone
2017-04-04T20:41:50.757Z|00015|ofproto_dpif|INFO|system@ovs-system:
Datapath supports ct_mark
2017-04-04T20:41:50.757Z|00016|ofproto_dpif|INFO|system@ovs-system:
Datapath supports ct_label

Re: [ovs-dev] [PATCH v5] netdev-dpdk: fix ifindex assignment for DPDK ports

2017-04-04 Thread Darrell Ball


On 4/4/17, 3:09 AM, "Lal, PrzemyslawX"  wrote:

On 04/04/2017 06:14, Darrell Ball wrote:

>
> On 4/3/17, 5:27 AM, "ovs-dev-boun...@openvswitch.org on behalf of 
Przemyslaw Lal"  wrote:
>
>  In current implementation port_id is used as an ifindex for all 
netdev-dpdk
>  interfaces.
>  
>  For physical DPDK interfaces using port_id as ifindex causes that 
'0' is set as
>  ifindex for 'dpdk0' interface, '1' for 'dpdk1' and so on. For the 
DPDK vHost
>  interfaces ifindexes are not even assigned (0 is used by default) 
due to the
>  fact that vHost ports don't use port_id field from the DPDK library.
>  
>  This causes multiple negative side-effects. First of all 0 is an 
invalid
>  ifindex value. The other issue is possible overlapping of 'dpdkX' 
interfaces
>  ifindex values with the ifindexes of kernel space interfaces which 
may cause
>  problems in any external tools that use those values. Neither 
'dpdk0', nor any
>  DPDK vHost interfaces are visible in sFlow collector tools, as all 
interfaces
>  with ifindexes smaller than 1 are ignored.
>  
>  Proposed solution to these issues is to calculate a hash of 
interface's name
>  and use calculated value as an ifindex. This way interfaces keep 
their
>  ifindexes during OVS-DPDK restarts, ports re-initialization events, 
etc., show
>  up in sFlow collectors and meet RFC 2863 specification regarding 
re-using
>  ifindex values by the same virtual interfaces and maximum ifindex 
value.
>  
>  Signed-off-by: Przemyslaw Lal 
>  ---
>   lib/netdev-dpdk.c | 6 +-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>  
>  diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>  index ddc651b..687b0a5 100644
>  --- a/lib/netdev-dpdk.c
>  +++ b/lib/netdev-dpdk.c
>  @@ -2215,7 +2215,11 @@ netdev_dpdk_get_ifindex(const struct netdev 
*netdev)
>   int ifindex;
>   
>   ovs_mutex_lock(>mutex);
>  -ifindex = dev->port_id;
>  +/* Calculate hash from the netdev name. Ensure that ifindex is 
a 24-bit
>  + * postive integer to meet RFC 2863 recommendations.
>  + */
>  +uint32_t h = hash_string(netdev->name, 0);
>  +ifindex = (int)(h % 0xfe + 1);
>
>
> If user configuration was supported, enforcing uniqueness would be the
> responsibility of the user.

This was already discussed on this mailing list and outcome was that while 
hash is not perfect, it is the best solution for now.
Also, please keep in mind that names of the physical DPDK devices and 
dpdkvhostuser interfaces are configurable, so user can still enforce
uniqueness.

I know uniqueness could be enforced by trial and error of name selection.
I saw the comment
 “At some point, with vhost-pmd we will have port_ids also for vhost interfaces.
   Maybe we can revisit this approach when that becomes available.”

If others are fine, then so am I.


>
> One minor question:
> I know other ifindex implementations do not limit to 24 bits, so I 
checked RFC 2863.
> What section is the 24 bit limit recommendation mentioned in RFC 2863; I 
missed it.

Recommendation of RFC 2863 is to use "small integers". Main purpose of this 
patch is to enable dpdkvhostuser interfaces in sFlow metrics collecting tools.
After posting previous version I've received feedback from the community 
that not all interfaces are visible in sFlow collectors and maximum supported 
ifindex is 2^24.
Here's the sFlow v5 specification: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__sflow.org_sflow-5Fversion-5F5.txt=DwICaQ=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=BU2KdxyVIZVbS8qF48IH8n4FNs8DBkSQf7Bp0zdQvXE=ZgBDm95VkGw_R6_ULUFT5mh0OtbGPzcnjpWXze9DIGw=
 

2^24 is an sflow recommendation (rather than Interfaces MIB recommendation)
 – that’s fine; I was just curious where it came from.


>
>
>
>   ovs_mutex_unlock(>mutex);
>   
>   return ifindex;
>  --
>  1.9.1
>  
>  ___
>  dev mailing list
>  d...@openvswitch.org
>  
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=Rcpenle5jqQ1mu3STwFMODvsTFjKL9iMBrwMfu9J8FM=FJtoKpLo8NxpzHwFKSz6xsT3aGqZCiR507-MDVxjFeE=
>  
>
>
>



___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] dpif-netlink: fix memory leak in dpif_netlink_port_del__() on WIN32

2017-04-04 Thread Joe Stringer
On 4 April 2017 at 13:31, Eric Garver  wrote:
> Furthermore, the return code of dpif_netlink_port_query__() was not
> being checked.
>
> Signed-off-by: Eric Garver 
> ---

For context, yes this adds the call to the Linux path as well but this
is already in the proposed rtnetlink patch series so I'm not concerned
about this.

Here's my Ack. I'd like some windows folk to be aware and take a look
too though:
Acked-by: Joe Stringer 

>  lib/dpif-netlink.c | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
> index bad575c9cf65..860df6013827 100644
> --- a/lib/dpif-netlink.c
> +++ b/lib/dpif-netlink.c
> @@ -60,9 +60,6 @@ VLOG_DEFINE_THIS_MODULE(dpif_netlink);
>  #ifdef _WIN32
>  #include "wmi.h"
>  enum { WINDOWS = 1 };
> -static int dpif_netlink_port_query__(const struct dpif_netlink *dpif,
> - odp_port_t port_no, const char 
> *port_name,
> - struct dpif_port *dpif_port);
>  #else
>  enum { WINDOWS = 0 };
>  #endif
> @@ -224,6 +221,9 @@ static void dpif_netlink_vport_to_ofpbuf(const struct 
> dpif_netlink_vport *,
>   struct ofpbuf *);
>  static int dpif_netlink_vport_from_ofpbuf(struct dpif_netlink_vport *,
>const struct ofpbuf *);
> +static int dpif_netlink_port_query__(const struct dpif_netlink *dpif,
> + odp_port_t port_no, const char 
> *port_name,
> + struct dpif_port *dpif_port);
>
>  static struct dpif_netlink *
>  dpif_netlink_cast(const struct dpif *dpif)
> @@ -948,19 +948,23 @@ dpif_netlink_port_del__(struct dpif_netlink *dpif, 
> odp_port_t port_no)
>  OVS_REQ_WRLOCK(dpif->upcall_lock)
>  {
>  struct dpif_netlink_vport vport;
> +struct dpif_port dpif_port;
>  int error;
>
> +error = dpif_netlink_port_query__(dpif, port_no, NULL, _port);
> +if (error) {
> +return error;
> +}
> +
>  dpif_netlink_vport_init();
>  vport.cmd = OVS_VPORT_CMD_DEL;
>  vport.dp_ifindex = dpif->dp_ifindex;
>  vport.port_no = port_no;
>  #ifdef _WIN32
> -struct dpif_port temp_dpif_port;
> -dpif_netlink_port_query__(dpif, port_no, NULL, _dpif_port);
> -if (!strcmp(temp_dpif_port.type, "internal")) {
> -if (!delete_wmi_port(temp_dpif_port.name)){
> +if (!strcmp(dpif_port.type, "internal")) {
> +if (!delete_wmi_port(dpif_port.name)){
>  VLOG_ERR("Could not delete wmi port with name: %s",
> - temp_dpif_port.name);
> + dpif_port.name);
>  };
>  }
>  #endif
> @@ -968,6 +972,8 @@ dpif_netlink_port_del__(struct dpif_netlink *dpif, 
> odp_port_t port_no)
>
>  vport_del_channels(dpif, port_no);
>
> +dpif_port_destroy(_port);
> +
>  return error;
>  }
>
> --
> 2.9.3
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH ovs V5 00/24] Introducing HW offload support for openvswitch

2017-04-04 Thread Joe Stringer
On 3 April 2017 at 10:53, Joe Stringer  wrote:
> On 3 April 2017 at 03:27, Roi Dayan  wrote:
>>
>>
>> On 29/03/2017 20:13, Joe Stringer wrote:
>>>
>>> On 29 March 2017 at 04:50, Roi Dayan  wrote:



 On 23/03/2017 09:01, Joe Stringer wrote:
>
>
> I ran the make check-offloads tests on a recent net-next kernel and it
> failed, output was not as expected:
>
> ../../tests/system-offloaded-traffic.at:54
> : ovs-appctl dpctl/dump-flows |
> grep "eth_type(0x0800)" | sed -e
>
>
> 's/used:[0-9].[0-9]*s/used:0.001s/;s/eth(src=[a-z0-9:]*,dst=[a-z0-9:]*)/eth(mac
> s)/;s/actions:[0-9,]*/actions:output/;s/recirc_id(0),//' | sort
> --- - 2017-03-22 16:43:37.598689692 -0700
> +++
>
>
> /home/vagrant/ovs/_build-clang/tests/system-offloads-testsuite.dir/at-groups/2/stdout
> 2017-03-22 16:43:37.595628000 -0700
> @@ -1,3 +1,3 @@
> -in_port(2),eth(macs),eth_type(0x0800), packets:9, bytes:756,
> used:0.001s, actions:output
> -in_port(3),eth(macs),eth_type(0x0800), packets:9, bytes:756,
> used:0.001s, actions:output
> +in_port(2),eth(macs),eth_type(0x0800),ipv4(frag=no), packets:9,
> bytes:882, used:0.001s, actions:output
> +in_port(3),eth(macs),eth_type(0x0800),ipv4(frag=no), packets:9,
> bytes:882, used:0.001s, actions:output
>

 Hi Joe,

 can you tell me what kernel you used here?
 maybe tc offloads were not supported and there was a fallback to OVS dp.
>>>
>>>
>>> I believe that it was a snapshot of net-next relatively recently,
>>> 01461abe62df ("Merge branch 'fib-notifications-cleanup'"). I could try
>>> again with latest net-next? Or do you think there may be some
>>> userspace dependency the test relies on?
>>>
>>
>> I installed net-next kernel and make check-offloads pass for me.
>> The last commit I'm on is
>> 397df70 Merge branch '40GbE' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
>> last tag is 4.11-rc3+
>> I'm thinking maybe the test fails for you from something else like a second
>> openvswitch process running already?
>
> I don't think that was the case, but let me try again with your latest
> series and the above commit.

I saw the same behaviour with upstream net-next 397df7092a15. My host
is Ubuntu 14.04 with this kernel.

I thought it might be because I'm not running any of your hardware and
I assumed that the testsuite doesn't require hardware to run. Looking
at the test it seems that assumption was wrong, but when I tried to
configure the tc-policy to skip_hw with the following modification,
the OVSDB change didn't seem to propagate into OVS (there were no log
messages about changing the tc-policy):

diff --git a/tests/system-offloaded-traffic.at
b/tests/system-offloaded-traffic.at
index 7aec8a3f430e..3ddf23a939a8 100644
--- a/tests/system-offloaded-traffic.at
+++ b/tests/system-offloaded-traffic.at
@@ -40,6 +40,7 @@ AT_SETUP([offloads - ping between two ports -
offloads enabled])
OVS_TRAFFIC_VSWITCHD_START()

AT_CHECK([ovs-vsctl set Open_vSwitch . other_config:hw-offload=true])
+AT_CHECK([ovs-vsctl set Open_vSwitch . other_config:tc-policy="skip_hw"])
AT_CHECK([ovs-ofctl add-flow br0 "actions=normal"])

ADD_NAMESPACES(at_ns0, at_ns1)

---

Looking again, my kernel config had CLS_FLOWER disabled so that's
probably what caused the issue. My ovs-vswitchd log from the test is
below.

2017-04-04T20:41:50.737Z|1|vlog|INFO|opened log file
/home/joe/git/openvswitch/_build-gcc/tests/system-offloads-testsuite.dir/2/ovs-vswitchd.log
2017-04-04T20:41:50.737Z|2|ovs_numa|INFO|Discovered 2 CPU cores on
NUMA node 0
2017-04-04T20:41:50.737Z|3|ovs_numa|INFO|Discovered 1 NUMA nodes
and 2 CPU cores
2017-04-04T20:41:50.738Z|4|reconnect|INFO|unix:/home/joe/git/openvswitch/_build-gcc/tests/system-offloads-testsuite.dir/2/db.sock:
connecting...
2017-04-04T20:41:50.738Z|5|reconnect|INFO|unix:/home/joe/git/openvswitch/_build-gcc/tests/system-offloads-testsuite.dir/2/db.sock:
connected
2017-04-04T20:41:50.743Z|6|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.7.90
2017-04-04T20:41:50.757Z|7|ofproto_dpif|INFO|system@ovs-system:
Datapath supports recirculation
2017-04-04T20:41:50.757Z|8|ofproto_dpif|INFO|system@ovs-system:
MPLS label stack length probed as 1
2017-04-04T20:41:50.757Z|9|ofproto_dpif|INFO|system@ovs-system:
Datapath supports truncate action
2017-04-04T20:41:50.757Z|00010|ofproto_dpif|INFO|system@ovs-system:
Datapath supports unique flow ids
2017-04-04T20:41:50.757Z|00011|ofproto_dpif|INFO|system@ovs-system:
Datapath does not support clone action
2017-04-04T20:41:50.757Z|00012|ofproto_dpif|INFO|system@ovs-system:
Max sample nesting level probed as 10
2017-04-04T20:41:50.757Z|00013|ofproto_dpif|INFO|system@ovs-system:
Datapath supports ct_state
2017-04-04T20:41:50.757Z|00014|ofproto_dpif|INFO|system@ovs-system:
Datapath supports 

Re: [ovs-dev] [PATCH ovs V6 22/24] tests: Add system-offloads-testsuite

2017-04-04 Thread Joe Stringer
On 29 March 2017 at 05:43, Roi Dayan  wrote:
> From: Paul Blakey 
>
> The new system-offloads-testsuite, which can be launched via
> `make check-offloads`, tests offloading capabilities
> to makes sure that certian flows are actually offloaded.
>
> The tests run on virtual netdevices (VETH).
>
> Signed-off-by: Paul Blakey 
> Reviewed-by: Roi Dayan 
> Reviewed-by: Simon Horman 
> ---
>  tests/.gitignore   |  1 +
>  tests/automake.mk  | 16 +
>  tests/ofproto-macros.at|  6 ++--
>  tests/system-offloaded-traffic.at  | 67 
> ++
>  tests/system-offloads-testsuite.at | 25 ++
>  5 files changed, 113 insertions(+), 2 deletions(-)
>  create mode 100644 tests/system-offloaded-traffic.at
>  create mode 100644 tests/system-offloads-testsuite.at

Is there a reason that some tests/ files are system-offloads-* and
some are system-offloaded-*? Can we make them use the same prefix?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH] dpif-netlink: fix memory leak in dpif_netlink_port_del__() on WIN32

2017-04-04 Thread Eric Garver
Furthermore, the return code of dpif_netlink_port_query__() was not
being checked.

Signed-off-by: Eric Garver 
---
 lib/dpif-netlink.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index bad575c9cf65..860df6013827 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -60,9 +60,6 @@ VLOG_DEFINE_THIS_MODULE(dpif_netlink);
 #ifdef _WIN32
 #include "wmi.h"
 enum { WINDOWS = 1 };
-static int dpif_netlink_port_query__(const struct dpif_netlink *dpif,
- odp_port_t port_no, const char *port_name,
- struct dpif_port *dpif_port);
 #else
 enum { WINDOWS = 0 };
 #endif
@@ -224,6 +221,9 @@ static void dpif_netlink_vport_to_ofpbuf(const struct 
dpif_netlink_vport *,
  struct ofpbuf *);
 static int dpif_netlink_vport_from_ofpbuf(struct dpif_netlink_vport *,
   const struct ofpbuf *);
+static int dpif_netlink_port_query__(const struct dpif_netlink *dpif,
+ odp_port_t port_no, const char *port_name,
+ struct dpif_port *dpif_port);
 
 static struct dpif_netlink *
 dpif_netlink_cast(const struct dpif *dpif)
@@ -948,19 +948,23 @@ dpif_netlink_port_del__(struct dpif_netlink *dpif, 
odp_port_t port_no)
 OVS_REQ_WRLOCK(dpif->upcall_lock)
 {
 struct dpif_netlink_vport vport;
+struct dpif_port dpif_port;
 int error;
 
+error = dpif_netlink_port_query__(dpif, port_no, NULL, _port);
+if (error) {
+return error;
+}
+
 dpif_netlink_vport_init();
 vport.cmd = OVS_VPORT_CMD_DEL;
 vport.dp_ifindex = dpif->dp_ifindex;
 vport.port_no = port_no;
 #ifdef _WIN32
-struct dpif_port temp_dpif_port;
-dpif_netlink_port_query__(dpif, port_no, NULL, _dpif_port);
-if (!strcmp(temp_dpif_port.type, "internal")) {
-if (!delete_wmi_port(temp_dpif_port.name)){
+if (!strcmp(dpif_port.type, "internal")) {
+if (!delete_wmi_port(dpif_port.name)){
 VLOG_ERR("Could not delete wmi port with name: %s",
- temp_dpif_port.name);
+ dpif_port.name);
 };
 }
 #endif
@@ -968,6 +972,8 @@ dpif_netlink_port_del__(struct dpif_netlink *dpif, 
odp_port_t port_no)
 
 vport_del_channels(dpif, port_no);
 
+dpif_port_destroy(_port);
+
 return error;
 }
 
-- 
2.9.3

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] Make your fantasies real! Order here and now.

2017-04-04 Thread Pharmacy Express
Use my good advice and you will manage to cure Erectyle disfunction under your 
steam!-https://goo.gl/hSKqyA
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH ovs V6 00/24] Introducing HW offload support for openvswitch

2017-04-04 Thread Joe Stringer
On 4 April 2017 at 06:21, Paul Blakey  wrote:
>
>
> On 03/04/2017 21:00, Joe Stringer wrote:
>>
>> On 1 April 2017 at 20:50, Roi Dayan  wrote:
>>>
>>>
>>>
>>> On 31/03/2017 01:11, Marcelo Ricardo Leitner wrote:


 On Thu, Mar 30, 2017 at 03:43:36PM -0300, Marcelo Ricardo Leitner wrote:
>
>
> On Wed, Mar 29, 2017 at 03:43:10PM +0300, Roi Dayan wrote:
>>
>>
>> This patch series introduces rule offload functionality to
>> dpif-netlink
>> via netdev ports new flow offloading API. The user can specify whether
>> to
>> enable rule offloading or not via OVS configuration. Netdev providers
>> are able to implement netdev flow offload API in order to offload
>> rules.
>>
>> This patch series also implements one offload scheme for netdev-linux,
>> using TC flower classifier, which was chosen because its sort of
>> natural
>> to state OVS DP rules for this classifier. However, the code can be
>> extended to support other classifiers such as U32, eBPF, etc which
>> support
>> offload as well.
>>
>> The use-case we are currently addressing is the newly sriov switchdev
>> mode
>> in the Linux kernel which was introduced in version 4.8 [1][2].
>> This series was tested against sriov vfs vports representors of the
>> Mellanox 100G ConnectX-4 series exposed by the mlx5 kernel driver.
>>
>>
>> V5->V6:
>> - Rebase over master branch, fix compilation issue
>> - Add Nicira copyright to tc interface
>
>
>
> Hi,
>
> I built rpm packages based on OVS upstream commit 36664f336664. Then I



 Please s/36664f336664/36664f377d048/g in this email.
 This was the commit used as base for the test:
 commit 36664f377d04857256c1d8582057e1cf3e0e3923
 Author: Ben Pfaff 
 Date:   Mon Mar 20 10:56:22 2017 -0700

 ovsdb-server: Drop unnecessary find_db() function.

 Thanks

> built a new set of packages with this patchset, v6, applied.
>
> When offloading is enabled, the rules are merged in an unexpected way.
> See the results below from the two scenarios.
>
> openvswitch-2.7.90-1.fc24.36664f336664.x86_64.rpm
>    upstream ovs commit
>
> [root@wsfd-netdev36 ~]# ovs-ofctl dump-flows ovs_pvp_br0
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=12.501s, table=0, n_packets=1022759,
> n_bytes=61365540, idle_age=0,
> ip,in_port=1,nw_src=16.0.0.1,nw_dst=1.0.0.1
> actions=output:2
>  cookie=0x0, duration=12.501s, table=0, n_packets=1020990,
> n_bytes=61259400, idle_age=0,
> ip,in_port=1,nw_src=16.0.0.2,nw_dst=1.0.0.2
> actions=output:2
>  cookie=0x0, duration=12.500s, table=0, n_packets=1023860,
> n_bytes=61431600, idle_age=0,
> ip,in_port=1,nw_src=16.0.0.3,nw_dst=1.0.0.3
> actions=output:2
>  cookie=0x0, duration=12.500s, table=0, n_packets=1022554,
> n_bytes=61353240, idle_age=0,
> ip,in_port=1,nw_src=16.0.0.4,nw_dst=1.0.0.4
> actions=output:2
>  cookie=0x0, duration=12.500s, table=0, n_packets=1021516,
> n_bytes=61290960, idle_age=0,
> ip,in_port=1,nw_src=16.0.0.5,nw_dst=1.0.0.5
> actions=output:2
>  cookie=0x0, duration=12.500s, table=0, n_packets=1020599,
> n_bytes=61235940, idle_age=0,
> ip,in_port=1,nw_src=16.0.0.6,nw_dst=1.0.0.6
> actions=output:2
>  cookie=0x0, duration=12.500s, table=0, n_packets=1022285,
> n_bytes=61337100, idle_age=0,
> ip,in_port=1,nw_src=16.0.0.7,nw_dst=1.0.0.7
> actions=output:2
>  cookie=0x0, duration=12.500s, table=0, n_packets=1021725,
> n_bytes=61303500, idle_age=0,
> ip,in_port=1,nw_src=16.0.0.8,nw_dst=1.0.0.8
> actions=output:2
>  cookie=0x0, duration=12.500s, table=0, n_packets=1022281,
> n_bytes=61336860, idle_age=0,
> ip,in_port=1,nw_src=16.0.0.9,nw_dst=1.0.0.9
> actions=output:2
>  cookie=0x0, duration=12.500s, table=0, n_packets=1022449,
> n_bytes=61346940, idle_age=0,
> ip,in_port=1,nw_src=16.0.0.10,nw_dst=1.0.0.10
> actions=output:2
>  cookie=0x0, duration=12.208s, table=0, n_packets=2580, n_bytes=154800,
> idle_age=0, ip,in_port=2,nw_src=16.0.0.1,nw_dst=1.0.0.1
> actions=output:1
>  cookie=0x0, duration=12.208s, table=0, n_packets=2675, n_bytes=160500,
> idle_age=0, ip,in_port=2,nw_src=16.0.0.2,nw_dst=1.0.0.2
> actions=output:1
>  cookie=0x0, duration=12.208s, table=0, n_packets=2520, n_bytes=151200,
> idle_age=0, ip,in_port=2,nw_src=16.0.0.3,nw_dst=1.0.0.3
> actions=output:1
>  cookie=0x0, duration=12.208s, table=0, n_packets=2587, n_bytes=155220,
> idle_age=0, ip,in_port=2,nw_src=16.0.0.4,nw_dst=1.0.0.4
> actions=output:1
>  cookie=0x0, duration=12.208s, table=0, n_packets=2640, n_bytes=158400,
> idle_age=0, 

Re: [ovs-dev] Traffic fails in vhost user port

2017-04-04 Thread Nadathur, Sundar
You are perfectly right, Ilya! That fixed it. 

Thank you very much.

Regards,
Sundar

> -Original Message-
> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
> Sent: Tuesday, April 4, 2017 2:45 AM
> To: Nadathur, Sundar ; ovs-
> d...@openvswitch.org
> Subject: Re: [ovs-dev] Traffic fails in vhost user port
> 
> On 04.04.2017 12:26, Nadathur, Sundar wrote:
> > Thanks, Ilya.
> >
> > # ovs-vsctl list Interface vi1
> > _uuid   : 30d1600a-ff7d-4bf5-9fdb-b0767af3611c
> > admin_state : up
> > bfd : {}
> > bfd_status  : {}
> > cfm_fault   : []
> > cfm_fault_status: []
> > cfm_flap_count  : []
> > cfm_health  : []
> > cfm_mpid: []
> > cfm_remote_mpids: []
> > cfm_remote_opstate  : []
> > duplex  : []
> > error   : []
> > external_ids: {}
> > ifindex : 0
> > ingress_policing_burst: 0
> > ingress_policing_rate: 0
> > lacp_current: []
> > link_resets : 0
> > link_speed  : []
> > link_state  : up
> > lldp: {}
> > mac : []
> > mac_in_use  : "00:00:00:00:00:00"
> > mtu : 1500
> > mtu_request : []
> > name: "vi1"
> > ofport  : 5
> > ofport_request  : []
> > options : {}
> > other_config: {}
> > statistics  : {"rx_1024_to_1518_packets"=0,
> "rx_128_to_255_packets"=0, "rx_1523_to_max_packets"=0,
> "rx_1_to_64_packets"=0, "rx_256_to_511_packets"=0,
> "rx_512_to_1023_packets"=0, "rx_65_to_127_packets"=0, rx_bytes=0,
> rx_dropped=0, rx_errors=0, tx_bytes=0, tx_dropped=11}
> > status  : {}
> > type: dpdkvhostuser
> >
> > Here is the qemu command line split for readability:
> > /usr/libexec/qemu-kvm -name guest=vhu-vm1,debug-threads=on -S
> >-object
> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-vhu-
> vm1/master-key.aes -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off
> >-m 2048 -mem-prealloc -mem-path /dev/hugepages/libvirt/qemu -
> realtime mlock=off -smp 2,sockets=2,cores=1,threads=1
> >-uuid f5b8c05b-9c7a-3211-49b9-2bd635f7e2aa -no-user-config -
> nodefaults
> >-chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-
> vhu-vm1/monitor.sock,server,nowait
> >-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-
> shutdown -boot strict=on -device piix3-usb-
> uhci,id=usb,bus=pci.0,addr=0x1.0x2
> >-drive
> file=/home/nfv/Images/vm1.qcow2,format=qcow2,if=none,id=drive-virtio-
> disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-
> disk0,id=virtio-disk0,bootindex=1
> > -chardev socket,id=charnet0,path=/usr/local/var/run/openvswitch/vi1 -
> netdev vhost-user,chardev=charnet0,id=hostnet0
> >-device virtio-net-
> pci,netdev=hostnet0,id=net0,mac=3a:19:09:52:14:50,bus=pci.0,addr=0x3 -
> vnc 0.0.0.0:1
> >-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device
> > virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
> >
> 
> OK. I got it. Memory is not shared between OVS and VM.
> To make vhostuser work you must use 'share' option for qemu memory
> backing.
> 
> Please, refer the Documentation/topics/dpdk/vhost-user.rst for libvirt xml
> example.  "memAccess='shared'" - is what you need.
> 
> QEMU cmdline should contain something like this:
> -object memory-backend-file,id=ram-node0,prealloc=yes,mem-
> path=/dev/hugepages/libvirt/qemu,share=yes,size=10737418240,host-
> nodes=0,policy=bind
> Maybe you can avoid using hugepages, but 'share=yes' is required for vhost-
> user to work.
> 
> Best regards, Ilya Maximets.
> 
> 
> 
> > Re. ifconfig from VM, I have difficulty getting it right now over VPN, but I
> will get it by tomorrow morning. The 'ifconfig ' state is UP in the VM, IP
> address is configured as 200.1.1.2/24 in the virtio-net interface in the VM.
> Within the VM, the local address 200.1.1.2 can be pinged.
> >
> > Is there any good way to monitor packets flowing over vhost-user interface,
> such as wireshark for eth interfaces?
> >
> >
> > Regards,
> > Sundar
> >
> >> -Original Message-
> >> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
> >> Sent: Tuesday, April 4, 2017 2:13 AM
> >> To: Nadathur, Sundar ; ovs-
> >> d...@openvswitch.org
> >> Subject: Re: [ovs-dev] Traffic fails in vhost user port
> >>
> >> On 04.04.2017 11:29, Nadathur, Sundar wrote:
>  -Original Message-
>  From: Ilya Maximets [mailto:i.maxim...@samsung.com]
>  Sent: Tuesday, April 4, 2017 12:07 AM
>  To: ovs-dev@openvswitch.org; Nadathur, Sundar
>  
>  Subject: [ovs-dev] Traffic fails in vhost user port
> 
>  Hi Sundar.
> >>>
> > The flows are configured as below:
> > # ovs-ofctl dump-flows br0
> > NXST_FLOW reply (xid=0x4):
> > cookie=0x0, duration=2833.612s, table=0, 

[ovs-dev] [PATCH v3 8/8] userspace: add vxlan gpe support to vport

2017-04-04 Thread Zoltán Balogh
From: Georg Schmuecking 

This patch is based on the "datapath: enable vxlangpe creation in compat mode"
from Yi Yang. It introduces an extension option "gpe" to the vxlan port in the
netdev-dpdk datapath. Furthermore it introduces a new protocol header file
vxlangpe.h in which the vxlan gpe protocoll is described. In the vxlan specific
methods the different packet are introduced and handled.

Signed-off-by: Yi Yang 
Signed-off-by: Georg Schmuecking 
---
 datapath/linux/compat/include/linux/openvswitch.h |  1 +
 include/openvswitch/automake.mk   |  4 +-
 include/openvswitch/vxlangpe.h| 76 +++
 lib/netdev-native-tnl.c   | 61 --
 lib/netdev-vport.c| 18 +-
 5 files changed, 150 insertions(+), 10 deletions(-)
 create mode 100755 include/openvswitch/vxlangpe.h

diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index 61f9e22..0146d23 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -291,6 +291,7 @@ enum ovs_vport_attr {
 enum {
OVS_VXLAN_EXT_UNSPEC,
OVS_VXLAN_EXT_GBP,  /* Flag or __u32 */
+   OVS_VXLAN_EXT_GPE = 8,  /* Flag or __u32 */
__OVS_VXLAN_EXT_MAX,
 };
 
diff --git a/include/openvswitch/automake.mk b/include/openvswitch/automake.mk
index c0e276f..c125f1e 100644
--- a/include/openvswitch/automake.mk
+++ b/include/openvswitch/automake.mk
@@ -29,5 +29,5 @@ openvswitchinclude_HEADERS = \
include/openvswitch/uuid.h \
include/openvswitch/version.h \
include/openvswitch/vconn.h \
-   include/openvswitch/vlog.h
-
+   include/openvswitch/vlog.h \
+   include/openvswitch/vxlangpe.h
diff --git a/include/openvswitch/vxlangpe.h b/include/openvswitch/vxlangpe.h
new file mode 100755
index 000..4c18d90
--- /dev/null
+++ b/include/openvswitch/vxlangpe.h
@@ -0,0 +1,76 @@
+#ifndef __OPENVSWITCH_VXLANGPE_H
+#define __OPENVSWITCH_VXLANGPE_H 1
+
+#include "openvswitch/types.h"
+
+#define u8 uint8_t
+#define u32 uint8_t
+#define __be32 ovs_be32
+
+/*
+ * VXLAN Generic Protocol Extension (VXLAN_F_GPE):
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * |R|R|Ver|I|P|R|O|   Reserved|Next Protocol  |
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ * |VXLAN Network Identifier (VNI) |   Reserved|
+ * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ *
+ * Ver = Version. Indicates VXLAN GPE protocol version.
+ *
+ * P = Next Protocol Bit. The P bit is set to indicate that the
+ * Next Protocol field is present.
+ *
+ * O = OAM Flag Bit. The O bit is set to indicate that the packet
+ * is an OAM packet.
+ *
+ * Next Protocol = This 8 bit field indicates the protocol header
+ * immediately following the VXLAN GPE header.
+ *
+ * https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-01
+ */
+
+struct vxlanhdr_gpe {
+#ifdef WORDS_BIGENDIAN
+   u8  reserved_flags2:2,
+   version:2,
+   instance_applied:1,
+   np_applied:1,
+   reserved_flags1:1,
+   oam_flag:1;
+#else
+   u8  oam_flag:1,
+   reserved_flags1:1,
+   np_applied:1,
+   instance_applied:1,
+   version:2,
+   reserved_flags2:2;
+#endif
+   u8  reserved_flags3;
+   u8  reserved_flags4;
+   u8  next_protocol;
+   __be32  vx_vni;
+};
+
+/* VXLAN-GPE header flags. */
+#define VXLAN_HF_VER   ((1U <<29) | (1U <<28))
+#define VXLAN_HF_NP(1U <<26)
+#define VXLAN_HF_OAM   (1U <<24)
+
+#define VXLAN_GPE_USED_BITS (VXLAN_HF_VER | VXLAN_HF_NP | VXLAN_HF_OAM | \
+0xff)
+
+/* VXLAN-GPE header Next Protocol. */
+#define VXLAN_GPE_NP_IPV4  0x01
+#define VXLAN_GPE_NP_IPV6  0x02
+#define VXLAN_GPE_NP_ETHERNET  0x03
+#define VXLAN_GPE_NP_NSH   0x04
+
+struct vxlan_metadata {
+   u32 gbp;
+   u32 gpe;
+};
+
+#define VXLAN_F_GPE0x4000
+#define VXLAN_HF_GPE 0x0400
+
+#endif /* __OPENVSWITCH_VXLANGPE_H */
diff --git a/lib/netdev-native-tnl.c b/lib/netdev-native-tnl.c
index 4590e25..2d947c2 100644
--- a/lib/netdev-native-tnl.c
+++ b/lib/netdev-native-tnl.c
@@ -44,6 +44,7 @@
 #include "unaligned.h"
 #include "unixctl.h"
 #include "openvswitch/vlog.h"
+#include "openvswitch/vxlangpe.h"
 
 VLOG_DEFINE_THIS_MODULE(native_tnl);
 static struct vlog_rate_limit err_rl = VLOG_RATE_LIMIT_INIT(60, 5);
@@ -497,6 +498,8 @@ netdev_vxlan_pop_header(struct dp_packet *packet)
 struct flow_tnl *tnl = >tunnel;
 struct vxlanhdr *vxh;
 unsigned int hlen;
+ovs_be32 vx_flags;
+enum packet_type next_pt = PT_ETH;
 
 

[ovs-dev] [PATCH v3 7/8] ofproto-dpif-xlate: refactor compose_output_action__

2017-04-04 Thread Zoltán Balogh
From: Jan Scheurich 

The very long function compose_output_action__() has been re-factored to make
the different cases for output to patch-port, native tunnel port, kernel tunnel
port, recirculation, or termination of a native tunnel at output to LOCAL port
clearer. Larger, self-contained blocks have been split out into separate
functions.

Signed-off-by; Jan Scheurich 
Co-authored-by: Zoltan Balogh 
---
 ofproto/ofproto-dpif-xlate.c | 435 +++
 1 file changed, 235 insertions(+), 200 deletions(-)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index cc775ad..86695de 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -3258,39 +3258,28 @@ xlate_flow_is_protected(const struct xlate_ctx *ctx, 
const struct flow *flow, co
 xport_in->xbundle->protected && xport_out->xbundle->protected);
 }
 
-static void
-compose_output_action__(struct xlate_ctx *ctx, ofp_port_t ofp_port,
-const struct xlate_bond_recirc *xr, bool check_stp)
+static bool
+check_output_prerequisites(struct xlate_ctx *ctx,
+   const struct xport *xport,
+   struct flow *flow,
+   bool check_stp)
 {
-const struct xport *xport = get_ofp_port(ctx->xbridge, ofp_port);
 struct flow_wildcards *wc = ctx->wc;
-struct flow *flow = >xin->flow;
-struct flow_tnl flow_tnl;
-union flow_vlan_hdr flow_vlans[FLOW_MAX_VLAN_HEADERS];
-uint8_t flow_nw_tos;
-odp_port_t out_port, odp_port;
-bool tnl_push_pop_send = false;
-uint8_t dscp;
-
-/* If 'struct flow' gets additional metadata, we'll need to zero it out
- * before traversing a patch port. */
-BUILD_ASSERT_DECL(FLOW_WC_SEQ == 39);
-memset(_tnl, 0, sizeof flow_tnl);
 
 if (!xport) {
 xlate_report(ctx, OFT_WARN, "Nonexistent output port");
-return;
+return false;
 } else if (xport->config & OFPUTIL_PC_NO_FWD) {
 xlate_report(ctx, OFT_DETAIL, "OFPPC_NO_FWD set, skipping output");
-return;
+return false;
 } else if (ctx->mirror_snaplen != 0 && xport->odp_port == ODPP_NONE) {
 xlate_report(ctx, OFT_WARN,
  "Mirror truncate to ODPP_NONE, skipping output");
-return;
+return false;
 } else if (xlate_flow_is_protected(ctx, flow, xport)) {
 xlate_report(ctx, OFT_WARN,
  "Flow is between protected ports, skipping output.");
-return;
+return false;
 } else if (check_stp) {
 if (is_stp(>base_flow)) {
 if (!xport_stp_should_forward_bpdu(xport) &&
@@ -3304,7 +3293,7 @@ compose_output_action__(struct xlate_ctx *ctx, ofp_port_t 
ofp_port,
  "RSTP not managing BPDU in this state, "
  "skipping bpdu output");
 }
-return;
+return false;
 }
 } else if ((xport->cfm && cfm_should_process_flow(xport->cfm, flow, 
wc))
|| (xport->bfd && bfd_should_process_flow(xport->bfd, flow,
@@ -3319,162 +3308,214 @@ compose_output_action__(struct xlate_ctx *ctx, 
ofp_port_t ofp_port,
 xlate_report(ctx, OFT_WARN,
  "RSTP not in forwarding state, skipping output");
 }
-return;
+return false;
 }
 }
+return true;
+}
 
-if (flow->packet_type == htonl(PT_ETH) && xport->is_layer3 ) {
-/* Ethernet packet to L3 outport -> pop ethernet header. */
-flow->packet_type = PACKET_TYPE_BE(OFPHTN_ETHERTYPE,
-   ntohs(flow->dl_type));
+static void
+xlate_output_patch_port(struct xlate_ctx *ctx,
+const struct xport *xport)
+{
+const struct xport *peer = xport->peer;
+struct flow *flow = >xin->flow;
+struct flow old_flow = ctx->xin->flow;
+struct flow_tnl old_flow_tnl_wc = ctx->wc->masks.tunnel;
+bool old_conntrack = ctx->conntracked;
+bool old_was_mpls = ctx->was_mpls;
+ovs_version_t old_version = ctx->xin->tables_version;
+struct ofpbuf old_stack = ctx->stack;
+uint8_t new_stack[1024];
+struct ofpbuf old_action_set = ctx->action_set;
+struct ovs_list *old_trace = ctx->xin->trace;
+uint64_t actset_stub[1024 / 8];
+
+ofpbuf_use_stub(>stack, new_stack, sizeof new_stack);
+ofpbuf_use_stub(>action_set, actset_stub, sizeof actset_stub);
+flow->in_port.ofp_port = peer->ofp_port;
+flow->metadata = htonll(0);
+memset(>tunnel, 0, sizeof flow->tunnel);
+flow->tunnel.metadata.tab = ofproto_get_tun_tab(
+>xbridge->ofproto->up);
+ctx->wc->masks.tunnel.metadata.tab = flow->tunnel.metadata.tab;
+memset(flow->regs, 0, sizeof flow->regs);
+flow->actset_output = 

[ovs-dev] [PATCH v3 3/8] userspace: Switching of L3 packets in L2 pipeline

2017-04-04 Thread Zoltán Balogh
From: Jan Scheurich 

Ports have a new layer3 attribute if they send/receive L3 packets.

The packet_type included in structs dp_packet and flow is considered in
ofproto-dpif. The classical L2 match fields (dl_src, dl_dst, dl_type, and
vlan_tci, vlan_vid, vlan_pcp) now have Ethernet as pre-requisite.

A dummy ethernet header is pushed to L3 packets received from L3 ports
before the the pipeline processing starts. The ethernet header is popped
before sending a packet to a L3 port.

For datapath ports that can receive L2 or L3 packets, the packet_type
becomes part of the flow key for datapath flows and is handled
appropriately in dpif-netdev.

In the 'else' branch in flow_put_on_pmd() function, the additional check
flow_equal(, _flow->flow) was removed, as a) the dpcls
lookup is sufficient to uniquely identify a flow and b) it caused false
negatives because the flow in netdev->flow may not properly masked.

In dpif_netdev_flow_put() we now use the same method for constructing the
netdev_flow_key as the one used when adding the flow to the dplcs to make sure
these always match. The function netdev_flow_key_from_flow() used so far was
not only inefficient but sometimes caused mismatches and subsequent flow
update failures.

Signed-off-by: Lorand Jakab 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Benc 
Signed-off-by: Yi Yang 
Signed-off-by: Jan Scheurich 
Co-authored-by: Zoltan Balogh 
---
 build-aux/extract-ofp-fields  |   1 +
 datapath/linux/compat/include/linux/openvswitch.h |   2 +
 include/openvswitch/match.h   |   1 +
 include/openvswitch/meta-flow.h   |  15 +-
 lib/dpif-netdev.c |  46 +++---
 lib/dpif-netlink.c|   2 +-
 lib/match.c   |  25 +++
 lib/meta-flow.c   |   2 +
 lib/netdev-vport.c|   8 +-
 lib/netdev.h  |   1 +
 lib/odp-execute.c |   2 +
 lib/odp-util.c| 185 ++
 lib/odp-util.h|   6 +-
 lib/packets.h |   1 -
 ofproto/ofproto-dpif-sflow.c  |   1 +
 ofproto/ofproto-dpif-upcall.c |   4 +-
 ofproto/ofproto-dpif-xlate.c  |  49 +-
 ofproto/ofproto-dpif.c|   6 +-
 ofproto/tunnel.c  |   3 +
 tests/tunnel-push-pop-ipv6.at |  10 +-
 tests/tunnel-push-pop.at  |  12 +-
 tests/tunnel.at   |  28 ++--
 22 files changed, 298 insertions(+), 112 deletions(-)

diff --git a/build-aux/extract-ofp-fields b/build-aux/extract-ofp-fields
index af7c69b..d5b8a82 100755
--- a/build-aux/extract-ofp-fields
+++ b/build-aux/extract-ofp-fields
@@ -39,6 +39,7 @@ FORMATTING = {"decimal":("MFS_DECIMAL",  1,   
8),
   "TCP flags":  ("MFS_TCP_FLAGS",2,   2)}
 
 PREREQS = {"none": "MFP_NONE",
+   "Ethernet": "MFP_ETHERNET",
"ARP": "MFP_ARP",
"VLAN VID": "MFP_VLAN_VID",
"IPv4": "MFP_IPV4",
diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index ad979eb..61f9e22 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -363,6 +363,8 @@ enum ovs_key_attr {
/* Only used within kernel data path. */
OVS_KEY_ATTR_TUNNEL_INFO,  /* struct ovs_tunnel_info */
 #endif
+
+   OVS_KEY_ATTR_PACKET_TYPE,  /* be32 packet type */
__OVS_KEY_ATTR_MAX
 };
 
diff --git a/include/openvswitch/match.h b/include/openvswitch/match.h
index 06fa04c..ce06919 100644
--- a/include/openvswitch/match.h
+++ b/include/openvswitch/match.h
@@ -115,6 +115,7 @@ void match_set_ct_ipv6_dst(struct match *, const struct 
in6_addr *);
 void match_set_ct_ipv6_dst_masked(struct match *, const struct in6_addr *,
   const struct in6_addr *);
 
+void match_set_packet_type(struct match *, ovs_be32 packet_type);
 void match_set_skb_priority(struct match *, uint32_t skb_priority);
 void match_set_dl_type(struct match *, ovs_be16);
 void match_set_dl_src(struct match *, const struct eth_addr );
diff --git a/include/openvswitch/meta-flow.h b/include/openvswitch/meta-flow.h
index 11852d2..c284ec6 100644
--- a/include/openvswitch/meta-flow.h
+++ b/include/openvswitch/meta-flow.h
@@ -985,7 +985,7 @@ enum OVS_PACKED_ENUM mf_field_id {
  * Type: MAC.
  * Maskable: bitwise.
  * Formatting: Ethernet.
- * Prerequisites: none.
+ * 

[ovs-dev] [PATCH v3 2/8] userspace: Support for push_eth and pop_eth actions

2017-04-04 Thread Zoltán Balogh
From: Jan Scheurich 

Add support for actions push_eth and pop_eth to the netdev datapath and
the supporting libraries. This patch relies on the support for these actions
in the kernel datapath to be present.

Signed-off-by: Lorand Jakab 
Signed-off-by: Simon Horman 
Signed-off-by: Jiri Benc 
Signed-off-by: Yi Yang 
Signed-off-by: Jean Tourrilhes 
Signed-off-by: Jan Scheurich 
Co-authored-by: Zoltan Balogh 
---
 datapath/linux/compat/include/linux/openvswitch.h |  6 ++-
 lib/odp-execute.c | 17 +-
 lib/odp-util.c| 64 +--
 lib/odp-util.h|  7 +++
 lib/packets.c | 41 +++
 lib/packets.h |  4 ++
 ofproto/ofproto-dpif-sflow.c  | 14 ++---
 7 files changed, 138 insertions(+), 15 deletions(-)

diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index f2ef0c1..ad979eb 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -747,6 +747,9 @@ enum ovs_ct_attr {
  */
 struct ovs_action_push_eth {
struct ovs_key_ethernet addresses;
+#ifndef __KERNEL__
+__be16  eth_type;
+#endif
 };
 
 /**
@@ -823,8 +826,7 @@ enum ovs_nat_attr {
  * entries in the flow key.
  * @OVS_ACTION_ATTR_PUSH_ETH: Push a new outermost Ethernet header onto the
  * packet.
- * @OVS_ACTION_ATTR_POP_ETH: Pop the outermost Ethernet header off the
- * packet.
+ * @OVS_ACTION_ATTR_POP_ETH: Pop the outermost Ethernet header off the packet.
  *
  * Only a single header can be set with a single %OVS_ACTION_ATTR_SET.  Not all
  * fields within a header are modifiable, e.g. the IPv4 protocol and fragment
diff --git a/lib/odp-execute.c b/lib/odp-execute.c
index c4563b1..8e090c8 100644
--- a/lib/odp-execute.c
+++ b/lib/odp-execute.c
@@ -732,6 +732,21 @@ odp_execute_actions(void *dp, struct dp_packet_batch 
*batch, bool steal,
 case OVS_ACTION_ATTR_METER:
 /* Not implemented yet. */
 break;
+case OVS_ACTION_ATTR_PUSH_ETH: {
+const struct ovs_action_push_eth *eth = nl_attr_get(a);
+
+DP_PACKET_BATCH_FOR_EACH (packet, batch) {
+push_eth(packet, >addresses.eth_dst,
+ >addresses.eth_src, eth->eth_type);
+}
+break;
+}
+
+case OVS_ACTION_ATTR_POP_ETH:
+DP_PACKET_BATCH_FOR_EACH (packet, batch) {
+pop_eth(packet);
+}
+break;
 
 case OVS_ACTION_ATTR_OUTPUT:
 case OVS_ACTION_ATTR_TUNNEL_PUSH:
@@ -739,8 +754,6 @@ odp_execute_actions(void *dp, struct dp_packet_batch 
*batch, bool steal,
 case OVS_ACTION_ATTR_USERSPACE:
 case OVS_ACTION_ATTR_RECIRC:
 case OVS_ACTION_ATTR_CT:
-case OVS_ACTION_ATTR_PUSH_ETH:
-case OVS_ACTION_ATTR_POP_ETH:
 case OVS_ACTION_ATTR_UNSPEC:
 case __OVS_ACTION_ATTR_MAX:
 OVS_NOT_REACHED();
diff --git a/lib/odp-util.c b/lib/odp-util.c
index 8747778..f137044 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -865,9 +865,11 @@ format_odp_action(struct ds *ds, const struct nlattr *a)
 break;
 case OVS_ACTION_ATTR_PUSH_ETH: {
 const struct ovs_action_push_eth *eth = nl_attr_get(a);
-ds_put_format(ds, "push_eth(src="ETH_ADDR_FMT",dst="ETH_ADDR_FMT")",
+ds_put_format(ds, "push_eth(src="ETH_ADDR_FMT",dst="ETH_ADDR_FMT
+  ",type=0x%04"PRIx16")",
   ETH_ADDR_ARGS(eth->addresses.eth_src),
-  ETH_ADDR_ARGS(eth->addresses.eth_dst));
+  ETH_ADDR_ARGS(eth->addresses.eth_dst),
+  ntohs(eth->eth_type));
 break;
 }
 case OVS_ACTION_ATTR_POP_ETH:
@@ -1078,14 +1080,41 @@ parse_odp_userspace_action(const char *s, struct ofpbuf 
*actions)
 odp_put_userspace_action(pid, user_data, user_data_size,
  tunnel_out_port, include_actions, 
actions);
 res = n + n1;
+goto out;
 } else if (s[n] == ')') {
 odp_put_userspace_action(pid, user_data, user_data_size,
  ODPP_NONE, include_actions, actions);
 res = n + 1;
-} else {
-res = -EINVAL;
+goto out;
+}
+}
+
+{
+struct ovs_action_push_eth push;
+int eth_type = 0;
+int n1 = -1;
+
+if (ovs_scan([n], "push_eth(src="ETH_ADDR_SCAN_FMT","
+ "dst="ETH_ADDR_SCAN_FMT",type=%i)%n",
+ 

[ovs-dev] [PATCH v3 1/8] userspace: Add packet_type in dp_packet and flow

2017-04-04 Thread Zoltán Balogh
From: Jan Scheurich 

This commit adds a packet_type attribute to the structs dp_packet and flow
to explicitly carry the type of the packet as prepration for the
introduction of the so-called packet type-aware pipeline (PTAP) in OVS.

The packet_type is a big-endian 32 bit integer with the encoding as
specified in OpenFlow verion 1.5.

The upper 16 bits contain the packet type name space. Pre-defined values
are defined in openflow-common.h:

enum ofp_header_type_namespaces {
OFPHTN_ONF = 0, /* ONF namespace. */
OFPHTN_ETHERTYPE = 1,   /* ns_type is an Ethertype. */
OFPHTN_IP_PROTO = 2,/* ns_type is a IP protocol number. */
OFPHTN_UDP_TCP_PORT = 3,/* ns_type is a TCP or UDP port. */
OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */
};

The lower 16 bits specify the actual type in the context of the name space.

Only name spaces 0 and 1 will be supported for now.

For name space OFPHTN_ONF the relevant packet type is 0 (Ethernet).
This is the default packet_type in OVS and the only one supported so far.
Packets of type (OFPHTN_ONF, 0) are called Ethernet packets.

In name space OFPHTN_ETHERTYPE the type is the Ethertype of the packet.
A packet of type (OFPHTN_ETHERTYPE, ) is a standard L2 packet
whith the Ethernet header (and any VLAN tags) removed to expose the L3
(or L2.5) payload of the packet. These will simply be called L3 packets.

The Ethernet address fields dl_src and dl_dst in struct flow are not
applicable for an L3 packet and must be zero. However, to maintain
compatibility with the large code base, we have chosen to copy the
Ethertype of an L3 packet into the the dl_type field of struct flow.

This does not mean that it will be possible to match on dl_type for L3
packets with PTAP later on. Matching must be done on packet_type instead.

New dp_packets are initialized with packet_type Ethernet. Ports that
receive L3 packets will have to explicitly adjust the packet_type.

Signed-off-by: Jean Tourrilhes 
Signed-off-by: Jan Scheurich 
Co-authored-by: Zoltan Balogh 
---
 include/openflow/openflow-common.h |   9 +++
 include/openvswitch/flow.h |  16 +++---
 include/openvswitch/ofp-print.h|   9 ++-
 lib/cfm.c  |   2 +-
 lib/conntrack.c|   2 +-
 lib/dp-packet.c|   3 +
 lib/dp-packet.h|  18 --
 lib/dpif-netdev.c  |   3 +-
 lib/dpif-netlink.c |  17 ++
 lib/dpif.c |   6 +-
 lib/flow.c | 112 ++---
 lib/flow.h |  11 +++-
 lib/match.c|   2 +-
 lib/netdev-bsd.c   |   1 +
 lib/netdev-dummy.c |   5 ++
 lib/netdev-linux.c |   4 +-
 lib/netdev-native-tnl.c|   4 +-
 lib/nx-match.c |   2 +-
 lib/odp-execute.c  |   2 +-
 lib/odp-util.h |   2 +-
 lib/ofp-print.c|  29 --
 lib/ofp-util.c |   2 +-
 lib/packets.c  |  10 +++-
 lib/packets.h  |  35 
 lib/pcap-file.c|   4 +-
 ofproto/ofproto-dpif-rid.h |   2 +-
 ofproto/ofproto-dpif-xlate.c   |   2 +-
 ofproto/ofproto-dpif.c |   4 +-
 ovn/controller/pinctrl.c   |   6 +-
 tests/test-flows.c |   2 +-
 30 files changed, 235 insertions(+), 91 deletions(-)

diff --git a/include/openflow/openflow-common.h 
b/include/openflow/openflow-common.h
index 7b619a9..2382682 100644
--- a/include/openflow/openflow-common.h
+++ b/include/openflow/openflow-common.h
@@ -454,4 +454,13 @@ enum ofp_table_config {
 OFPTC14_VACANCY_EVENTS= 1 << 3, /* Enable vacancy events. */
 };
 
+/* Header and packet type name spaces. */
+enum ofp_header_type_namespaces {
+OFPHTN_ONF = 0, /* ONF namespace. */
+OFPHTN_ETHERTYPE = 1,   /* ns_type is an Ethertype. */
+OFPHTN_IP_PROTO = 2,/* ns_type is a IP protocol number. */
+OFPHTN_UDP_TCP_PORT = 3,/* ns_type is a TCP or UDP port. */
+OFPHTN_IPV4_OPTION = 4, /* ns_type is an IPv4 option number. */
+};
+
 #endif /* openflow/openflow-common.h */
diff --git a/include/openvswitch/flow.h b/include/openvswitch/flow.h
index 188467d..36a2a85 100644
--- a/include/openvswitch/flow.h
+++ b/include/openvswitch/flow.h
@@ -23,7 +23,7 @@
 /* This sequence number should be incremented whenever anything involving flows
  * or the wildcarding of flows changes.  This will cause build assertion
  * failures in places which likely need to be updated. */
-#define FLOW_WC_SEQ 38
+#define FLOW_WC_SEQ 39
 
 /* Number of Open vSwitch extension 32-bit registers. */
 #define FLOW_N_REGS 16
@@ -108,7 +108,7 @@ struct flow {
  

[ovs-dev] [PATCH v3 6/8] dpif-netlink: Don't send PACKET_TYPE to kernel

2017-04-04 Thread Zoltán Balogh
The kernel datapath does not support the packet_type match field.
Instead it encodes the packet type implictly by the presence or absence of
the Ethernet attribute in the flow key and mask.

This patch filters the PACKET_TYPE attribute out of netlink flow key and
mask to be sent to the kernel datapath.

Signed-off-by; Zoltan Balogh 
---
 lib/dpif-netlink.c | 37 -
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index c01c89e..7144465 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -2911,6 +2911,34 @@ dpif_netlink_flow_from_ofpbuf(struct dpif_netlink_flow 
*flow,
 return 0;
 }
 
+static inline void
+nl_msg_put_exclude_packet_type(struct ofpbuf* buf, uint16_t type,
+   const struct nlattr *data,
+   uint16_t data_len)
+{
+const struct nlattr *packet_type = nl_attr_find__(data, data_len,
+  
OVS_KEY_ATTR_PACKET_TYPE);
+if (packet_type) {
+/* exclude PACKET_TYPE Netlink attribute. */
+ovs_assert(NLA_ALIGN(packet_type->nla_len) == NLA_HDRLEN + 
sizeof(uint32_t));
+
+size_t packet_type_len = NLA_HDRLEN + sizeof(uint32_t);
+size_t first_chunk_size =
+(size_t)((uint8_t *)packet_type - (uint8_t *)data);
+size_t second_chunk_size = data_len - first_chunk_size
+   - packet_type_len;
+uint8_t *first_attr = NULL;
+struct nlattr *next_attr = nl_attr_next(packet_type);
+
+first_attr = nl_msg_put_unspec_uninit(buf, type,
+  data_len - packet_type_len);
+memcpy(first_attr, data, first_chunk_size);
+memcpy(first_attr + first_chunk_size, next_attr, second_chunk_size);
+} else {
+nl_msg_put_unspec(buf, type, data, data_len);
+}
+}
+
 /* Appends to 'buf' (which must initially be empty) a "struct ovs_header"
  * followed by Netlink attributes corresponding to 'flow'. */
 static void
@@ -2937,13 +2965,12 @@ dpif_netlink_flow_to_ofpbuf(const struct 
dpif_netlink_flow *flow,
 }
 if (!flow->ufid_terse || !flow->ufid_present) {
 if (flow->key_len) {
-nl_msg_put_unspec(buf, OVS_FLOW_ATTR_KEY,
-  flow->key, flow->key_len);
+nl_msg_put_exclude_packet_type(buf, OVS_FLOW_ATTR_KEY, flow->key,
+   flow->key_len);
 }
-
 if (flow->mask_len) {
-nl_msg_put_unspec(buf, OVS_FLOW_ATTR_MASK,
-  flow->mask, flow->mask_len);
+nl_msg_put_exclude_packet_type(buf, OVS_FLOW_ATTR_MASK, flow->mask,
+   flow->mask_len);
 }
 if (flow->actions || flow->actions_len) {
 nl_msg_put_unspec(buf, OVS_FLOW_ATTR_ACTIONS,
-- 
2.7.4
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH v3 5/8] userspace: L3 tunnel support for GRE and LISP

2017-04-04 Thread Zoltán Balogh
From: Jan Scheurich 

Add a boolean "layer3" configuration option for tunnel vports.
The layer3 option defaults to false for all ports except LISP.
GRE ports accept both true and false for "layer3".

A tunnel vport configured with layer3=true receives L3 packets.
which are then converted to Ethernet packets by pushing a dummy
Ethernet heder at the ingress of the OpenFlow pipeline. The
Ethernet header of a packet is stripped before sending to a
layer3 tunnel vport.

Presently a single GRE vport cannot carry both L2 and L3 packets.
But it is possible to create two GRE vports representing the same
GRE tunel, one with layer3=false, the other with layer3=true.
L2 packet from the tunnel are received on the first vport, L3
packets on the second. The controller must send packets to the
layer3 GRE vport to tunnel them without their Ethernet header.

Units tests have been added to check the L3 tunnel handling.

LISP tunnels are not yet supported by the netdev userspace datapath.

Signed-off-by: Simon Horman 
Signed-off-by: Jiri Benc 
Signed-off-by: Yi Yang 
Signed-off-by; Jan Scheurich 
Co-authored-by: Zoltan Balogh 
---
 lib/netdev-native-tnl.c   | 26 +-
 lib/netdev-vport.c| 14 --
 ofproto/tunnel.c  | 14 +++---
 tests/tunnel-push-pop-ipv6.at | 15 ++-
 tests/tunnel-push-pop.at  | 33 +++--
 vswitchd/vswitch.xml  | 13 +
 6 files changed, 94 insertions(+), 21 deletions(-)

diff --git a/lib/netdev-native-tnl.c b/lib/netdev-native-tnl.c
index 2798324..4590e25 100644
--- a/lib/netdev-native-tnl.c
+++ b/lib/netdev-native-tnl.c
@@ -154,6 +154,10 @@ netdev_tnl_push_ip_header(struct dp_packet *packet,
 *ip_tot_size = dp_packet_size(packet) - sizeof (struct eth_header);
 
 memcpy(eth, header, size);
+/* The encapsulated packet has type Ethernet. Adjust dp_packet. */
+packet->packet_type = htonl(PT_ETH);
+dp_packet_reset_offsets(packet);
+packet->l3_ofs = sizeof (struct eth_header);
 
 if (netdev_tnl_is_header_ipv6(header)) {
 ip6 = netdev_tnl_ipv6_hdr(eth);
@@ -345,6 +349,7 @@ parse_gre_header(struct dp_packet *packet,
 ovs_16aligned_be32 *options;
 int hlen;
 unsigned int ulen;
+uint16_t greh_protocol;
 
 greh = netdev_tnl_ip_extract_tnl_md(packet, tnl, );
 if (!greh) {
@@ -355,10 +360,6 @@ parse_gre_header(struct dp_packet *packet,
 return -EINVAL;
 }
 
-if (greh->protocol != htons(ETH_TYPE_TEB)) {
-return -EINVAL;
-}
-
 hlen = ulen + gre_header_len(greh->flags);
 if (hlen > dp_packet_size(packet)) {
 return -EINVAL;
@@ -388,6 +389,15 @@ parse_gre_header(struct dp_packet *packet,
 options++;
 }
 
+/* Set the new packet type depending on the GRE protocol field. */
+greh_protocol = ntohs(greh->protocol);
+if (greh_protocol == ETH_TYPE_TEB) {
+packet->packet_type = htonl(PT_ETH);
+} else {
+/* Allow all GRE protocol values as Ethertypes */
+packet->packet_type = PACKET_TYPE_BE(OFPHTN_ETHERTYPE, greh_protocol);
+}
+
 return hlen;
 }
 
@@ -451,7 +461,11 @@ netdev_gre_build_header(const struct netdev *netdev,
 
 greh = netdev_tnl_ip_build_header(data, params, IPPROTO_GRE);
 
-greh->protocol = htons(ETH_TYPE_TEB);
+if (tnl_cfg->is_layer3) {
+greh->protocol = params->flow->dl_type;
+} else {
+greh->protocol = htons(ETH_TYPE_TEB);
+}
 greh->flags = 0;
 
 options = (ovs_16aligned_be32 *) (greh + 1);
@@ -504,6 +518,7 @@ netdev_vxlan_pop_header(struct dp_packet *packet)
 tnl->tun_id = htonll(ntohl(get_16aligned_be32(>vx_vni)) >> 8);
 tnl->flags |= FLOW_TNL_F_KEY;
 
+packet->packet_type = htonl(PT_ETH);
 dp_packet_reset_packet(packet, hlen + VXLAN_HLEN);
 
 return packet;
@@ -583,6 +598,7 @@ netdev_geneve_pop_header(struct dp_packet *packet)
 tnl->metadata.present.len = opts_len;
 tnl->flags |= FLOW_TNL_F_UDPIF;
 
+packet->packet_type = htonl(PT_ETH);
 dp_packet_reset_packet(packet, hlen);
 
 return packet;
diff --git a/lib/netdev-vport.c b/lib/netdev-vport.c
index a6c1e23..8653e96 100644
--- a/lib/netdev-vport.c
+++ b/lib/netdev-vport.c
@@ -410,7 +410,7 @@ set_tunnel_config(struct netdev *dev_, const struct smap 
*args, char **errp)
 const char *name = netdev_get_name(dev_);
 const char *type = netdev_get_type(dev_);
 struct ds errors = DS_EMPTY_INITIALIZER;
-bool needs_dst_port, has_csum;
+bool needs_dst_port, has_csum, optional_layer3;
 uint16_t dst_proto = 0, src_proto = 0;
 struct netdev_tunnel_config tnl_cfg;
 struct smap_node *node;
@@ -418,6 +418,7 @@ set_tunnel_config(struct netdev *dev_, const struct smap 
*args, char **errp)
 
 has_csum = strstr(type, "gre") || 

[ovs-dev] [PATCH v3 4/8] ofproto-dpif-upcall: Initialize dump-seq of new flow to zero

2017-04-04 Thread Zoltán Balogh
From: Jan Scheurich 

This forces updating of flow stat at the next re-validation, even for
flows that are being created when the revalidation has already commenced.

It enables reliable testing of fast path flow stats using ovs-appctl
time/warp after flow creation.

The change has no other negative side-effects, in particular with respect to
performance.

Signed-off-by: Jan Scheurich 
---
 ofproto/ofproto-dpif-upcall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c
index 5d9f7ed..241cce1 100644
--- a/ofproto/ofproto-dpif-upcall.c
+++ b/ofproto/ofproto-dpif-upcall.c
@@ -1118,7 +1118,7 @@ upcall_xlate(struct udpif *udpif, struct upcall *upcall,
  * with pushing its stats eventually. */
 }
 
-upcall->dump_seq = seq_read(udpif->dump_seq);
+upcall->dump_seq = 0;
 upcall->reval_seq = seq_read(udpif->reval_seq);
 
 xlate_actions(, >xout);
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH] netdev-dpdk: add dpdk interface strip_vlan option

2017-04-04 Thread Kevin Traynor
On 03/15/2017 08:46 AM, Zang MingJie wrote:
> dpdk-strip-vlan option specifies whether strip vlan for the dpdk interface.
> 
> Signed-off-by: Zang MingJie 
> ---
>  lib/netdev-dpdk.c| 23 ++-
>  vswitchd/vswitch.xml |  7 +++
>  2 files changed, 29 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index ddc651bf9..ea49adf3e 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -373,6 +373,7 @@ struct netdev_dpdk {
>  int requested_n_rxq;
>  int requested_rxq_size;
>  int requested_txq_size;
> +bool requested_strip_vlan;
>  
>  /* Number of rx/tx descriptors for physical devices */
>  int rxq_size;
> @@ -395,6 +396,8 @@ struct netdev_dpdk {
>  /* DPDK-ETH hardware offload features,
>   * from the enum set 'dpdk_hw_ol_features' */
>  uint32_t hw_ol_features;
> +
> +bool strip_vlan;

I don't think this should have it's own fields in the data struct as
there is a hw_ol_feature bitmask intended for that. At the moment it is
only used for rx checksum offload and could easily be extended for strip
vlan if people think it's a good feature to expose. Maybe the reason you
didn't use it in this patch is because it's currently broken and does
nothing on reconfiguration :|

I've sent a patch to fix that here
https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330481.html

>  };
>  
>  struct netdev_rxq_dpdk {
> @@ -646,6 +649,7 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, int 
> n_rxq, int n_txq)
>  conf.rxmode.jumbo_frame = 0;
>  conf.rxmode.max_rx_pkt_len = 0;
>  }
> +conf.rxmode.hw_vlan_strip = dev->strip_vlan;
>  conf.rxmode.hw_ip_checksum = (dev->hw_ol_features &
>NETDEV_RX_CHECKSUM_OFFLOAD) != 0;
>  /* A device may report more queues than it makes available (this has
> @@ -1133,6 +1137,19 @@ netdev_dpdk_process_devargs(const char *devargs, char 
> **errp)
>  }
>  
>  static void
> +dpdk_set_strip_vlan_config(struct netdev_dpdk *dev, const struct smap *args)
> +OVS_REQUIRES(dev->mutex)
> +{
> +bool strip_vlan;
> +
> +strip_vlan = smap_get_bool(args, "dpdk-strip-vlan", false);
> +if (strip_vlan != dev->requested_strip_vlan) {
> +dev->requested_strip_vlan = strip_vlan;
> +netdev_request_reconfigure(>up);
> +}
> +}
> +
> +static void
>  dpdk_set_rxq_config(struct netdev_dpdk *dev, const struct smap *args)
>  OVS_REQUIRES(dev->mutex)
>  {
> @@ -1182,6 +1199,7 @@ netdev_dpdk_set_config(struct netdev *netdev, const 
> struct smap *args,
>  ovs_mutex_lock(>mutex);
>  
>  dpdk_set_rxq_config(dev, args);
> +dpdk_set_strip_vlan_config(dev, args);
>  
>  dpdk_process_queue_size(netdev, args, "n_rxq_desc",
>  NIC_PORT_DEFAULT_RXQ_SIZE,
> @@ -3123,7 +3141,8 @@ netdev_dpdk_reconfigure(struct netdev *netdev)
>  && dev->mtu == dev->requested_mtu
>  && dev->rxq_size == dev->requested_rxq_size
>  && dev->txq_size == dev->requested_txq_size
> -&& dev->socket_id == dev->requested_socket_id) {
> +&& dev->socket_id == dev->requested_socket_id
> +&& dev->strip_vlan == dev->requested_strip_vlan) {
>  /* Reconfiguration is unnecessary */
>  
>  goto out;
> @@ -3145,6 +3164,8 @@ netdev_dpdk_reconfigure(struct netdev *netdev)
>  dev->rxq_size = dev->requested_rxq_size;
>  dev->txq_size = dev->requested_txq_size;
>  
> +dev->strip_vlan = dev->requested_strip_vlan;
> +
>  rte_free(dev->tx_q);
>  err = dpdk_eth_dev_init(dev);
>  dev->tx_q = netdev_dpdk_alloc_txq(netdev->n_txq);
> diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
> index a91be59b0..5c0083188 100644
> --- a/vswitchd/vswitch.xml
> +++ b/vswitchd/vswitch.xml
> @@ -2360,6 +2360,13 @@
>  
>
>  
> +  
> +
> +  Specifies whether strip vlan for the dpdk interface. It is useful
> +  when using ixgbevf interface with a vlan filter.
> +
> +  
> +
>type='{"type": "string"}'>
>  
> 

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH v2 3/3] ovn-nbctl: include table formatting options in man page

2017-04-04 Thread Lance Richardson
Include descriptions of table formatting optiosn in ovn-nbctl
man page.

Signed-off-by: Lance Richardson 
---
 v2: no changes

 ovn/utilities/ovn-nbctl.8.xml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ovn/utilities/ovn-nbctl.8.xml b/ovn/utilities/ovn-nbctl.8.xml
index 10793ce..70afc10 100644
--- a/ovn/utilities/ovn-nbctl.8.xml
+++ b/ovn/utilities/ovn-nbctl.8.xml
@@ -847,6 +847,12 @@
 
 Logging options
 http://www.w3.org/2003/XInclude"/>
+
+Table Formatting Options
+These options control the format of output from the list and
+find commands.
+http://www.w3.org/2003/XInclude"/>
+
 PKI Options
 
   PKI configuration is required to use SSL for the connection to the
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH v2 2/3] table: add xml version of lib/table.man

2017-04-04 Thread Lance Richardson
Add lib/table.xml, translated from lib/table.man for inclusion
in XML man pages (such as ovn-nbctl.8.xml).

Signed-off-by: Lance Richardson 
---
v2: incorporated v2 table.man changes, fixed whitespace
issue, removed extraneous text from description of
"--pretty" option.

 lib/automake.mk |   1 +
 lib/table.xml   | 114 
 2 files changed, 115 insertions(+)
 create mode 100644 lib/table.xml

diff --git a/lib/automake.mk b/lib/automake.mk
index b266af1..62b2f38 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -443,6 +443,7 @@ EXTRA_DIST += \
lib/db-ctl-base.xml \
lib/ssl.xml \
lib/ssl-bootstrap.xml \
+   lib/table.xml \
lib/vlog.xml
 
 MAN_FRAGMENTS += \
diff --git a/lib/table.xml b/lib/table.xml
new file mode 100644
index 000..8076bc9
--- /dev/null
+++ b/lib/table.xml
@@ -0,0 +1,114 @@
+
+
+  -f format
+  --format=format
+  
+
+  Sets the type of table formatting.  The following types of
+  format are available:
+  
+table
+
+  2-D text tables with aligned columns.
+
+
+list (default)
+
+  A list with one column per line and rows separated by a blank line.
+
+
+html
+
+  HTML tables.
+
+csv
+
+  Comma-separated values as defined in RFC 4180.
+
+
+json
+
+  JSON format as defined in RFC 4627.  The output
+  is a sequence of JSON objects, each of which corresponds to one
+  table.  Each JSON object has the following members with the noted
+  values:
+  
+caption
+
+  The table's caption.  This member is omitted if the table has
+  no caption.
+
+headings
+
+  An array with one element per table column.  Each array element
+  is a string giving the corresponding column's heading.
+
+data
+
+  An array with one element per table row.  Each element is also
+  an array with one element per table column.  The elements of
+  this second-level array are the cells that constitute the table.
+  Cells that represent OVSDB data or data types are expressed in
+  the format described in the OVSDB specification; other cells are
+  simply expressed as text strings.
+
+  
+
+  
+
+  
+  -d format
+  --data=format
+  
+
+  Sets the formatting for cells within output tables unless the table
+  format is set to json, in which case json
+  formatting is always used when formatting cells.  The following types
+  of format are available:
+
+  
+string (default)
+
+  The simple format described in the Database Values
+  section of ovs-vsctl(8).
+
+
+bare
+
+  The simple format with punctuation stripped off:
+  [] and {} are omitted around sets, maps,
+  and empty columns, items within sets and maps are space-separated,
+  and strings are never quoted.  This format may be easier for scripts
+  to parse.
+
+
+json
+
+  The RFC 4627 JSON format as described above.
+
+  
+
+  
+  --no-headings
+  
+This option suppresses the heading row that otherwise appears in the
+first row of table output.
+  
+  --pretty
+  
+
+  By default, JSON in output is printed as compactly as possible.  This
+  option causes JSON in output to be printed in a more readable
+  fashion.  Members of objects and elements of arrays are printed one
+  per line, with indentation.
+
+
+  This option does not affect JSON in tables, which is always printed
+  compactly.
+
+  
+  --bare
+  
+Equivalent to --format=list --data=bare --no-headings.
+  
+
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH v2 1/3] ovsdb-client: improve formatting option description in man page

2017-04-04 Thread Lance Richardson
Use correct option name for "--no-headings", remove duplicate
"--no-heading" option in synopsis.

Clarify description of "--data=json" option.

Signed-off-by: Lance Richardson 
---
v2: all new

 lib/table.man   | 12 ++--
 ovsdb/ovsdb-client.1.in |  3 +--
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/lib/table.man b/lib/table.man
index 62efa9a..2b38741 100644
--- a/lib/table.man
+++ b/lib/table.man
@@ -36,8 +36,10 @@ as text strings.
 .
 .IP "\fB\-d \fIformat\fR"
 .IQ "\fB\-\-data=\fIformat\fR"
-Sets the formatting for cells within output tables.  The following
-types of \fIformat\fR are available:
+Sets the formatting for cells within output tables unless the table
+format is set to \fBjson\fR, in which case \fBjson\fR formatting is
+always used when formatting cells.  The following types of \fIformat\fR
+are available:
 .RS
 .IP "\fBstring\fR (default)"
 The simple format described in the \fBDatabase Values\fR
@@ -49,13 +51,11 @@ are omitted around sets, maps, and empty columns, items 
within sets
 and maps are space-separated, and strings are never quoted.  This
 format may be easier for scripts to parse.
 .IP "\fBjson\fR"
-JSON.
+The RFC 4627 JSON format as described above.
 .RE
 .IP
-The \fBjson\fR output format always outputs cells in JSON format,
-ignoring this option.
 .
-.IP "\fB\-\-no\-heading\fR"
+.IP "\fB\-\-no\-headings\fR"
 This option suppresses the heading row that otherwise appears in the
 first row of table output.
 .
diff --git a/ovsdb/ovsdb-client.1.in b/ovsdb/ovsdb-client.1.in
index 9658291..d3dd84c 100644
--- a/ovsdb/ovsdb-client.1.in
+++ b/ovsdb/ovsdb-client.1.in
@@ -46,10 +46,9 @@ ovsdb\-client \- command-line interface to 
\fBovsdb-server\fR(1)
 .IP "Output formatting options:"
 [\fB\-\-format=\fIformat\fR]
 [\fB\-\-data=\fIformat\fR]
-[\fB\-\-no-heading\fR]
+[\fB\-\-no-headings\fR]
 [\fB\-\-pretty\fR]
 [\fB\-\-bare\fR]
-[\fB\-\-no\-heading\fR]
 [\fB\-\-timestamp\fR]
 .so lib/daemon-syn.man
 .so lib/vlog-syn.man
-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] [PATCH v2 0/3] fix table formatting option descriptions in man pages

2017-04-04 Thread Lance Richardson
Correct some typos in man pages related to table formatting
options.  Clarify description of "--data=json" option. Add
XML version of lib/table.man to include in ovn-nbctl man page.


v2: Corrections to table.man and ovsdb-client.1.in, whitespace
issue and extraneous text in table.xml.

Lance Richardson (3):
  ovsdb-client: improve formatting option description in man page
  table: add xml version of lib/table.man
  ovn-nbctl: include table formatting options in man page

 lib/automake.mk   |   1 +
 lib/table.man |  12 ++---
 lib/table.xml | 114 ++
 ovn/utilities/ovn-nbctl.8.xml |   6 +++
 ovsdb/ovsdb-client.1.in   |   3 +-
 5 files changed, 128 insertions(+), 8 deletions(-)
 create mode 100644 lib/table.xml

-- 
2.7.4

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH ovs V6 00/24] Introducing HW offload support for openvswitch

2017-04-04 Thread Paul Blakey



On 03/04/2017 21:00, Joe Stringer wrote:

On 1 April 2017 at 20:50, Roi Dayan  wrote:



On 31/03/2017 01:11, Marcelo Ricardo Leitner wrote:


On Thu, Mar 30, 2017 at 03:43:36PM -0300, Marcelo Ricardo Leitner wrote:


On Wed, Mar 29, 2017 at 03:43:10PM +0300, Roi Dayan wrote:


This patch series introduces rule offload functionality to dpif-netlink
via netdev ports new flow offloading API. The user can specify whether
to
enable rule offloading or not via OVS configuration. Netdev providers
are able to implement netdev flow offload API in order to offload rules.

This patch series also implements one offload scheme for netdev-linux,
using TC flower classifier, which was chosen because its sort of natural
to state OVS DP rules for this classifier. However, the code can be
extended to support other classifiers such as U32, eBPF, etc which
support
offload as well.

The use-case we are currently addressing is the newly sriov switchdev
mode
in the Linux kernel which was introduced in version 4.8 [1][2].
This series was tested against sriov vfs vports representors of the
Mellanox 100G ConnectX-4 series exposed by the mlx5 kernel driver.


V5->V6:
- Rebase over master branch, fix compilation issue
- Add Nicira copyright to tc interface



Hi,

I built rpm packages based on OVS upstream commit 36664f336664. Then I



Please s/36664f336664/36664f377d048/g in this email.
This was the commit used as base for the test:
commit 36664f377d04857256c1d8582057e1cf3e0e3923
Author: Ben Pfaff 
Date:   Mon Mar 20 10:56:22 2017 -0700

ovsdb-server: Drop unnecessary find_db() function.

Thanks


built a new set of packages with this patchset, v6, applied.

When offloading is enabled, the rules are merged in an unexpected way.
See the results below from the two scenarios.

openvswitch-2.7.90-1.fc24.36664f336664.x86_64.rpm
   upstream ovs commit

[root@wsfd-netdev36 ~]# ovs-ofctl dump-flows ovs_pvp_br0
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=12.501s, table=0, n_packets=1022759,
n_bytes=61365540, idle_age=0, ip,in_port=1,nw_src=16.0.0.1,nw_dst=1.0.0.1
actions=output:2
 cookie=0x0, duration=12.501s, table=0, n_packets=1020990,
n_bytes=61259400, idle_age=0, ip,in_port=1,nw_src=16.0.0.2,nw_dst=1.0.0.2
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1023860,
n_bytes=61431600, idle_age=0, ip,in_port=1,nw_src=16.0.0.3,nw_dst=1.0.0.3
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1022554,
n_bytes=61353240, idle_age=0, ip,in_port=1,nw_src=16.0.0.4,nw_dst=1.0.0.4
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1021516,
n_bytes=61290960, idle_age=0, ip,in_port=1,nw_src=16.0.0.5,nw_dst=1.0.0.5
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1020599,
n_bytes=61235940, idle_age=0, ip,in_port=1,nw_src=16.0.0.6,nw_dst=1.0.0.6
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1022285,
n_bytes=61337100, idle_age=0, ip,in_port=1,nw_src=16.0.0.7,nw_dst=1.0.0.7
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1021725,
n_bytes=61303500, idle_age=0, ip,in_port=1,nw_src=16.0.0.8,nw_dst=1.0.0.8
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1022281,
n_bytes=61336860, idle_age=0, ip,in_port=1,nw_src=16.0.0.9,nw_dst=1.0.0.9
actions=output:2
 cookie=0x0, duration=12.500s, table=0, n_packets=1022449,
n_bytes=61346940, idle_age=0, ip,in_port=1,nw_src=16.0.0.10,nw_dst=1.0.0.10
actions=output:2
 cookie=0x0, duration=12.208s, table=0, n_packets=2580, n_bytes=154800,
idle_age=0, ip,in_port=2,nw_src=16.0.0.1,nw_dst=1.0.0.1 actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2675, n_bytes=160500,
idle_age=0, ip,in_port=2,nw_src=16.0.0.2,nw_dst=1.0.0.2 actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2520, n_bytes=151200,
idle_age=0, ip,in_port=2,nw_src=16.0.0.3,nw_dst=1.0.0.3 actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2587, n_bytes=155220,
idle_age=0, ip,in_port=2,nw_src=16.0.0.4,nw_dst=1.0.0.4 actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2640, n_bytes=158400,
idle_age=0, ip,in_port=2,nw_src=16.0.0.5,nw_dst=1.0.0.5 actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2593, n_bytes=155580,
idle_age=0, ip,in_port=2,nw_src=16.0.0.6,nw_dst=1.0.0.6 actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2634, n_bytes=158040,
idle_age=0, ip,in_port=2,nw_src=16.0.0.7,nw_dst=1.0.0.7 actions=output:1
 cookie=0x0, duration=12.208s, table=0, n_packets=2549, n_bytes=152940,
idle_age=0, ip,in_port=2,nw_src=16.0.0.8,nw_dst=1.0.0.8 actions=output:1
 cookie=0x0, duration=12.207s, table=0, n_packets=2627, n_bytes=157620,
idle_age=0, ip,in_port=2,nw_src=16.0.0.9,nw_dst=1.0.0.9 actions=output:1
 cookie=0x0, duration=12.207s, table=0, n_packets=2530, n_bytes=151800,
idle_age=0, ip,in_port=2,nw_src=16.0.0.10,nw_dst=1.0.0.10 actions=output:1

[root@wsfd-netdev36 ~]# 

Re: [ovs-dev] OVN meeting report

2017-04-04 Thread Valentine Sinitsyn

On 03.04.2017 20:29, Valentine Sinitsyn wrote:

Hi Ben,

On 23.03.2017 08:11, Ben Pfaff wrote:

Hello everyone.  I am not sure whether I am going to be able to attend
the OVN meeting tomorrow, because I will be in another possibly
distracting meeting, so I'm going to give my report here.

Toward the end of last week I did a full pass of reviews through
patchwork.  The most notable result, I think, is that I applied patches
that add 802.1ad support.  For OVN, this makes it more reasonable to
consider adding support for tagged logical ports--currently, OVN drops
all tagged logical packets--which I've heard requested once or twice,
because it means that they can now be gatewayed to physical ports within
an outer VLAN.  I don't have any plans to work on that, but I think that
it is worth pointing out.

The OVS "Open Source Day" talks have been scheduled at OpenStack
Boston.  They are all on Wednesday:
https://www.openstack.org/summit/boston-2017/summit-schedule/#track=135

I've been spending what dev time I have on database clustering.  Today,
I managed to get it working, with many caveats.  It will take weeks or
months longer to get it finished, tested, and ready for posting.  (If
you want what I have, check out the raft3 branch in my ovs-reviews repo
at github.)

I've checked out your raft3 branch, and even learned how to create an
OVSDB cluster. Thanks for the docs!

What I don't get though is how do I instruct IDL to connect to the
cluster now? Do I just connect to a random server, or there should be
some dispatcher, or whatever?

OK I see this is an ongoing work in your branch.

Best,
Valentine



Thanks,
Valentine


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v5] netdev-dpdk: fix ifindex assignment for DPDK ports

2017-04-04 Thread Lal, PrzemyslawX

On 04/04/2017 06:14, Darrell Ball wrote:



On 4/3/17, 5:27 AM, "ovs-dev-boun...@openvswitch.org on behalf of Przemyslaw Lal" 
 wrote:

 In current implementation port_id is used as an ifindex for all netdev-dpdk
 interfaces.
 
 For physical DPDK interfaces using port_id as ifindex causes that '0' is set as

 ifindex for 'dpdk0' interface, '1' for 'dpdk1' and so on. For the DPDK 
vHost
 interfaces ifindexes are not even assigned (0 is used by default) due to 
the
 fact that vHost ports don't use port_id field from the DPDK library.
 
 This causes multiple negative side-effects. First of all 0 is an invalid

 ifindex value. The other issue is possible overlapping of 'dpdkX' 
interfaces
 ifindex values with the ifindexes of kernel space interfaces which may 
cause
 problems in any external tools that use those values. Neither 'dpdk0', nor 
any
 DPDK vHost interfaces are visible in sFlow collector tools, as all 
interfaces
 with ifindexes smaller than 1 are ignored.
 
 Proposed solution to these issues is to calculate a hash of interface's name

 and use calculated value as an ifindex. This way interfaces keep their
 ifindexes during OVS-DPDK restarts, ports re-initialization events, etc., 
show
 up in sFlow collectors and meet RFC 2863 specification regarding re-using
 ifindex values by the same virtual interfaces and maximum ifindex value.
 
 Signed-off-by: Przemyslaw Lal 

 ---
  lib/netdev-dpdk.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)
 
 diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c

 index ddc651b..687b0a5 100644
 --- a/lib/netdev-dpdk.c
 +++ b/lib/netdev-dpdk.c
 @@ -2215,7 +2215,11 @@ netdev_dpdk_get_ifindex(const struct netdev *netdev)
  int ifindex;
  
  ovs_mutex_lock(>mutex);

 -ifindex = dev->port_id;
 +/* Calculate hash from the netdev name. Ensure that ifindex is a 
24-bit
 + * postive integer to meet RFC 2863 recommendations.
 + */
 +uint32_t h = hash_string(netdev->name, 0);
 +ifindex = (int)(h % 0xfe + 1);


If user configuration was supported, enforcing uniqueness would be the
responsibility of the user.


This was already discussed on this mailing list and outcome was that while hash 
is not perfect, it is the best solution for now.
Also please keep in mind that names of the physical DPDK devices and 
dpdkvhostuser interfaces are configurable, so user can still enforce uniqueness.



One minor question:
I know other ifindex implementations do not limit to 24 bits, so I checked RFC 
2863.
What section is the 24 bit limit recommendation mentioned in RFC 2863; I missed 
it.


Recommendation of RFC 2863 is to use "small integers". Main purpose of this 
patch is to enable dpdkvhostuser interfaces in sFlow metrics collecting tools.
After posting previous version I've received feedback from the community that 
not all interfaces are visible in sFlow collectors and maximum supported 
ifindex is 2^24.
Here's the sFlow v5 specification: http://sflow.org/sflow_version_5.txt





  ovs_mutex_unlock(>mutex);
  
  return ifindex;

 --
 1.9.1
 
 ___

 dev mailing list
 d...@openvswitch.org
 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev=DwICAg=uilaK90D4TOVoH58JNXRgQ=BVhFA09CGX7JQ5Ih-uZnsw=Rcpenle5jqQ1mu3STwFMODvsTFjKL9iMBrwMfu9J8FM=FJtoKpLo8NxpzHwFKSz6xsT3aGqZCiR507-MDVxjFeE=
 






___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] Traffic fails in vhost user port

2017-04-04 Thread Ilya Maximets
On 04.04.2017 12:26, Nadathur, Sundar wrote:
> Thanks, Ilya. 
> 
> # ovs-vsctl list Interface vi1
> _uuid   : 30d1600a-ff7d-4bf5-9fdb-b0767af3611c
> admin_state : up
> bfd : {}
> bfd_status  : {}
> cfm_fault   : []
> cfm_fault_status: []
> cfm_flap_count  : []
> cfm_health  : []
> cfm_mpid: []
> cfm_remote_mpids: []
> cfm_remote_opstate  : []
> duplex  : []
> error   : []
> external_ids: {}
> ifindex : 0
> ingress_policing_burst: 0
> ingress_policing_rate: 0
> lacp_current: []
> link_resets : 0
> link_speed  : []
> link_state  : up
> lldp: {}
> mac : []
> mac_in_use  : "00:00:00:00:00:00"
> mtu : 1500
> mtu_request : []
> name: "vi1"
> ofport  : 5
> ofport_request  : []
> options : {}
> other_config: {}
> statistics  : {"rx_1024_to_1518_packets"=0, 
> "rx_128_to_255_packets"=0, "rx_1523_to_max_packets"=0, 
> "rx_1_to_64_packets"=0, "rx_256_to_511_packets"=0, 
> "rx_512_to_1023_packets"=0, "rx_65_to_127_packets"=0, rx_bytes=0, 
> rx_dropped=0, rx_errors=0, tx_bytes=0, tx_dropped=11}
> status  : {}
> type: dpdkvhostuser
> 
> Here is the qemu command line split for readability:
> /usr/libexec/qemu-kvm -name guest=vhu-vm1,debug-threads=on -S 
>-object 
> secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-vhu-vm1/master-key.aes
>  -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off 
>-m 2048 -mem-prealloc -mem-path /dev/hugepages/libvirt/qemu -realtime 
> mlock=off -smp 2,sockets=2,cores=1,threads=1 
>-uuid f5b8c05b-9c7a-3211-49b9-2bd635f7e2aa -no-user-config -nodefaults 
>-chardev 
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-vhu-vm1/monitor.sock,server,nowait
>-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc 
> -no-shutdown -boot strict=on -device 
> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2
>-drive 
> file=/home/nfv/Images/vm1.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 
> -device 
> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
>  
> -chardev socket,id=charnet0,path=/usr/local/var/run/openvswitch/vi1 
> -netdev vhost-user,chardev=charnet0,id=hostnet0 
>-device 
> virtio-net-pci,netdev=hostnet0,id=net0,mac=3a:19:09:52:14:50,bus=pci.0,addr=0x3
>  -vnc 0.0.0.0:1 
>-device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device 
> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
> 

OK. I got it. Memory is not shared between OVS and VM.
To make vhostuser work you must use 'share' option for qemu memory backing.

Please, refer the Documentation/topics/dpdk/vhost-user.rst for libvirt xml
example.  "memAccess='shared'" - is what you need.

QEMU cmdline should contain something like this:
-object 
memory-backend-file,id=ram-node0,prealloc=yes,mem-path=/dev/hugepages/libvirt/qemu,share=yes,size=10737418240,host-nodes=0,policy=bind
Maybe you can avoid using hugepages, but 'share=yes' is required for vhost-user 
to work.

Best regards, Ilya Maximets.



> Re. ifconfig from VM, I have difficulty getting it right now over VPN, but I 
> will get it by tomorrow morning. The 'ifconfig ' state is UP in the VM, IP 
> address is configured as 200.1.1.2/24 in the virtio-net interface in the VM. 
> Within the VM, the local address 200.1.1.2 can be pinged. 
> 
> Is there any good way to monitor packets flowing over vhost-user interface, 
> such as wireshark for eth interfaces? 
> 
> 
> Regards,
> Sundar
> 
>> -Original Message-
>> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
>> Sent: Tuesday, April 4, 2017 2:13 AM
>> To: Nadathur, Sundar ; ovs-
>> d...@openvswitch.org
>> Subject: Re: [ovs-dev] Traffic fails in vhost user port
>>
>> On 04.04.2017 11:29, Nadathur, Sundar wrote:
 -Original Message-
 From: Ilya Maximets [mailto:i.maxim...@samsung.com]
 Sent: Tuesday, April 4, 2017 12:07 AM
 To: ovs-dev@openvswitch.org; Nadathur, Sundar
 
 Subject: [ovs-dev] Traffic fails in vhost user port

 Hi Sundar.
>>>
> The flows are configured as below:
> # ovs-ofctl dump-flows br0
> NXST_FLOW reply (xid=0x4):
> cookie=0x0, duration=2833.612s, table=0, n_packets=0, n_bytes=0,
> idle_age=2833, in_port=1 actions=output:5 cookie=0x2,
> duration=2819.820s, table=0, n_packets=0, n_bytes=0, idle_age=2819,
> in_port=5 actions=output:1

 I guess, your flow table configured in a wrong way.
 OpenFlow port of br0 is LOCAL, not 1.
 Try this:

 # ovs-ofctl del-flows br0

 # ovs-ofctl add-flow br0 in_port=5,actions=output:LOCAL # ovs-ofctl
 add-flow
 br0 in_port=LOCAL,actions=output:5
>>>
>>> Thank you, Ilya. I did as you suggested, 

Re: [ovs-dev] Traffic fails in vhost user port

2017-04-04 Thread Nadathur, Sundar
Thanks, Ilya. 

# ovs-vsctl list Interface vi1
_uuid   : 30d1600a-ff7d-4bf5-9fdb-b0767af3611c
admin_state : up
bfd : {}
bfd_status  : {}
cfm_fault   : []
cfm_fault_status: []
cfm_flap_count  : []
cfm_health  : []
cfm_mpid: []
cfm_remote_mpids: []
cfm_remote_opstate  : []
duplex  : []
error   : []
external_ids: {}
ifindex : 0
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current: []
link_resets : 0
link_speed  : []
link_state  : up
lldp: {}
mac : []
mac_in_use  : "00:00:00:00:00:00"
mtu : 1500
mtu_request : []
name: "vi1"
ofport  : 5
ofport_request  : []
options : {}
other_config: {}
statistics  : {"rx_1024_to_1518_packets"=0, "rx_128_to_255_packets"=0, 
"rx_1523_to_max_packets"=0, "rx_1_to_64_packets"=0, "rx_256_to_511_packets"=0, 
"rx_512_to_1023_packets"=0, "rx_65_to_127_packets"=0, rx_bytes=0, rx_dropped=0, 
rx_errors=0, tx_bytes=0, tx_dropped=11}
status  : {}
type: dpdkvhostuser

Here is the qemu command line split for readability:
/usr/libexec/qemu-kvm -name guest=vhu-vm1,debug-threads=on -S 
   -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-3-vhu-vm1/master-key.aes
 -machine pc-i440fx-rhel7.3.0,accel=kvm,usb=off 
   -m 2048 -mem-prealloc -mem-path /dev/hugepages/libvirt/qemu -realtime 
mlock=off -smp 2,sockets=2,cores=1,threads=1 
   -uuid f5b8c05b-9c7a-3211-49b9-2bd635f7e2aa -no-user-config -nodefaults 
   -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-3-vhu-vm1/monitor.sock,server,nowait
   -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown 
-boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2
   -drive 
file=/home/nfv/Images/vm1.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 
-device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 
-chardev socket,id=charnet0,path=/usr/local/var/run/openvswitch/vi1 -netdev 
vhost-user,chardev=charnet0,id=hostnet0 
   -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=3a:19:09:52:14:50,bus=pci.0,addr=0x3 
-vnc 0.0.0.0:1 
   -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on

Re. ifconfig from VM, I have difficulty getting it right now over VPN, but I 
will get it by tomorrow morning. The 'ifconfig ' state is UP in the VM, IP 
address is configured as 200.1.1.2/24 in the virtio-net interface in the VM. 
Within the VM, the local address 200.1.1.2 can be pinged. 

Is there any good way to monitor packets flowing over vhost-user interface, 
such as wireshark for eth interfaces? 


Regards,
Sundar

> -Original Message-
> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
> Sent: Tuesday, April 4, 2017 2:13 AM
> To: Nadathur, Sundar ; ovs-
> d...@openvswitch.org
> Subject: Re: [ovs-dev] Traffic fails in vhost user port
> 
> On 04.04.2017 11:29, Nadathur, Sundar wrote:
> >> -Original Message-
> >> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
> >> Sent: Tuesday, April 4, 2017 12:07 AM
> >> To: ovs-dev@openvswitch.org; Nadathur, Sundar
> >> 
> >> Subject: [ovs-dev] Traffic fails in vhost user port
> >>
> >> Hi Sundar.
> >
> >>> The flows are configured as below:
> >>> # ovs-ofctl dump-flows br0
> >>> NXST_FLOW reply (xid=0x4):
> >>> cookie=0x0, duration=2833.612s, table=0, n_packets=0, n_bytes=0,
> >>> idle_age=2833, in_port=1 actions=output:5 cookie=0x2,
> >>> duration=2819.820s, table=0, n_packets=0, n_bytes=0, idle_age=2819,
> >>> in_port=5 actions=output:1
> >>
> >> I guess, your flow table configured in a wrong way.
> >> OpenFlow port of br0 is LOCAL, not 1.
> >> Try this:
> >>
> >> # ovs-ofctl del-flows br0
> >>
> >> # ovs-ofctl add-flow br0 in_port=5,actions=output:LOCAL # ovs-ofctl
> >> add-flow
> >> br0 in_port=LOCAL,actions=output:5
> >
> > Thank you, Ilya. I did as you suggested, but the ping traffic from br0
> (LOCAL) is dropped by the output port 5:
> > # ovs-ofctl dump-flows br0
> > NXST_FLOW reply (xid=0x4):
> >  cookie=0x0, duration=1922.876s, table=0, n_packets=0, n_bytes=0,
> > idle_age=1922, in_port=5 actions=LOCAL  cookie=0x0,
> > duration=1915.458s, table=0, n_packets=6, n_bytes=252, idle_age=116,
> > in_port=LOCAL actions=output:5
> >
> > # ovs-ofctl dump-ports br0 # <-- Drops in port 5 OFPST_PORT reply
> > (xid=0x2): 2 ports
> >   port  5: rx pkts=?, bytes=0, drop=0, errs=0, frame=?, over=?, crc=?
> >tx pkts=?, bytes=0, drop=5, errs=?, coll=?
> >   port LOCAL: rx pkts=43, bytes=2118, drop=0, errs=0, frame=0, over=0,
> crc=0
> >tx pkts=0, bytes=0, drop=0, errs=0, coll=0
> >
> > Wireshark shows that br0 sends out 3 ARP 

Re: [ovs-dev] Traffic fails in vhost user port

2017-04-04 Thread Ilya Maximets
On 04.04.2017 11:29, Nadathur, Sundar wrote:
>> -Original Message-
>> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
>> Sent: Tuesday, April 4, 2017 12:07 AM
>> To: ovs-dev@openvswitch.org; Nadathur, Sundar
>> 
>> Subject: [ovs-dev] Traffic fails in vhost user port
>>
>> Hi Sundar.
> 
>>> The flows are configured as below:
>>> # ovs-ofctl dump-flows br0
>>> NXST_FLOW reply (xid=0x4):
>>> cookie=0x0, duration=2833.612s, table=0, n_packets=0, n_bytes=0,
>>> idle_age=2833, in_port=1 actions=output:5 cookie=0x2,
>>> duration=2819.820s, table=0, n_packets=0, n_bytes=0, idle_age=2819,
>>> in_port=5 actions=output:1
>>
>> I guess, your flow table configured in a wrong way.
>> OpenFlow port of br0 is LOCAL, not 1.
>> Try this:
>>
>> # ovs-ofctl del-flows br0
>>
>> # ovs-ofctl add-flow br0 in_port=5,actions=output:LOCAL # ovs-ofctl add-flow
>> br0 in_port=LOCAL,actions=output:5
> 
> Thank you, Ilya. I did as you suggested, but the ping traffic from br0 
> (LOCAL) is dropped by the output port 5:
> # ovs-ofctl dump-flows br0
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=1922.876s, table=0, n_packets=0, n_bytes=0, 
> idle_age=1922, in_port=5 actions=LOCAL
>  cookie=0x0, duration=1915.458s, table=0, n_packets=6, n_bytes=252, 
> idle_age=116, in_port=LOCAL actions=output:5
> 
> # ovs-ofctl dump-ports br0 # <-- Drops in port 5
> OFPST_PORT reply (xid=0x2): 2 ports
>   port  5: rx pkts=?, bytes=0, drop=0, errs=0, frame=?, over=?, crc=?
>tx pkts=?, bytes=0, drop=5, errs=?, coll=?
>   port LOCAL: rx pkts=43, bytes=2118, drop=0, errs=0, frame=0, over=0, crc=0
>tx pkts=0, bytes=0, drop=0, errs=0, coll=0
> 
> Wireshark shows that br0 sends out 3 ARP requests but there is no response. 
> 
>> or
>>
>> # ovs-ofctl add-flow br0 actions=NORMAL
> I tried this too after doing del-flows. The LOCAL port's MAC is learnt, 
> wireshark still shows br0 sending out ARP requests with no response. 
> 
> BTW, 'ovs-vsctl list Interface' shows the vi1 (VM port, #5) is up (most 
> fields are blank):
> _uuid   : 30d1600a-ff7d-4bf5-9fdb-b0767af3611c
> admin_state : up
> . . .
> link_speed  : []
> link_state  : up
> . . .
> mac_in_use  : "00:00:00:00:00:00"
> mtu : 1500
> mtu_request : []
> name: "vi1"
> . . .
> statistics  : {"rx_1024_to_1518_packets"=0, 
> "rx_128_to_255_packets"=0, "rx_1523_to_max_packets"=0, 
> "rx_1_to_64_packets"=0, "rx_256_to_511_packets"=0, 
> "rx_512_to_1023_packets"=0, "rx_65_to_127_packets"=0, rx_bytes=0, 
> rx_dropped=0, rx_errors=0, tx_bytes=0, tx_dropped=8}
> status  : {}
> type: dpdkvhostuser
> 
> Is there any way to do the equivalent of a tcpdump or wireshark on a vhost 
> user port?
> 
> Thanks,
> Sundar
> 
Blanc fields in 'list interface' is normal for vhostuser.

Looks like something wrong with VM.
Please, provide the output of 'ip a' or 'ifconfig -a' from VM and full output
of 'ovs-vsctl list Interface vi1'. Also, qemu cmdline or libvirt xml can be 
helpful.


Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] Traffic fails in vhost user port

2017-04-04 Thread Nadathur, Sundar
Since, the port 5 is dropping it on the tx side, are there logs or more 
granular error counters?

FWIW, here are snippets from the qemu process's command line:
   ...  -m 2048 -mem-prealloc -mem-path /dev/hugepages/libvirt/qemu ... 
   ... -chardev socket,id=charnet0,path=/usr/local/var/run/openvswitch/vi1 
-netdev vhost-user,chardev=charnet0,id=hostnet0 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=3a:19:09:52:14:50,bus=pci.0,addr=0x3 
...

srwxr-xr-x 1 root root 0 Apr  3 14:51 /usr/local/var/run/openvswitch/vi1 
This is root-owned, following instructions from the libvirt part of:
 http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/ 
libvirtd and qemu-kvm are running as root. 

Regards,
Sundar

> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Nadathur, Sundar
> Sent: Tuesday, April 4, 2017 1:30 AM
> To: Ilya Maximets ; ovs-dev@openvswitch.org
> Subject: Re: [ovs-dev] Traffic fails in vhost user port
> 
> > -Original Message-
> > From: Ilya Maximets [mailto:i.maxim...@samsung.com]
> > Sent: Tuesday, April 4, 2017 12:07 AM
> > To: ovs-dev@openvswitch.org; Nadathur, Sundar
> > 
> > Subject: [ovs-dev] Traffic fails in vhost user port
> >
> > Hi Sundar.
> 
> > > The flows are configured as below:
> > > # ovs-ofctl dump-flows br0
> > > NXST_FLOW reply (xid=0x4):
> > > cookie=0x0, duration=2833.612s, table=0, n_packets=0, n_bytes=0,
> > > idle_age=2833, in_port=1 actions=output:5 cookie=0x2,
> > > duration=2819.820s, table=0, n_packets=0, n_bytes=0, idle_age=2819,
> > > in_port=5 actions=output:1
> >
> > I guess, your flow table configured in a wrong way.
> > OpenFlow port of br0 is LOCAL, not 1.
> > Try this:
> >
> > # ovs-ofctl del-flows br0
> >
> > # ovs-ofctl add-flow br0 in_port=5,actions=output:LOCAL # ovs-ofctl
> > add-flow
> > br0 in_port=LOCAL,actions=output:5
> 
> Thank you, Ilya. I did as you suggested, but the ping traffic from br0 (LOCAL)
> is dropped by the output port 5:
> # ovs-ofctl dump-flows br0
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=1922.876s, table=0, n_packets=0, n_bytes=0,
> idle_age=1922, in_port=5 actions=LOCAL  cookie=0x0, duration=1915.458s,
> table=0, n_packets=6, n_bytes=252, idle_age=116, in_port=LOCAL
> actions=output:5
> 
> # ovs-ofctl dump-ports br0 # <-- Drops in port 5 OFPST_PORT reply (xid=0x2):
> 2 ports
>   port  5: rx pkts=?, bytes=0, drop=0, errs=0, frame=?, over=?, crc=?
>tx pkts=?, bytes=0, drop=5, errs=?, coll=?
>   port LOCAL: rx pkts=43, bytes=2118, drop=0, errs=0, frame=0, over=0, crc=0
>tx pkts=0, bytes=0, drop=0, errs=0, coll=0
> 
> Wireshark shows that br0 sends out 3 ARP requests but there is no response.
> 
> > or
> >
> > # ovs-ofctl add-flow br0 actions=NORMAL
> I tried this too after doing del-flows. The LOCAL port's MAC is learnt,
> wireshark still shows br0 sending out ARP requests with no response.
> 
> BTW, 'ovs-vsctl list Interface' shows the vi1 (VM port, #5) is up (most fields
> are blank):
> _uuid   : 30d1600a-ff7d-4bf5-9fdb-b0767af3611c
> admin_state : up
> . . .
> link_speed  : []
> link_state  : up
> . . .
> mac_in_use  : "00:00:00:00:00:00"
> mtu : 1500
> mtu_request : []
> name: "vi1"
> . . .
> statistics  : {"rx_1024_to_1518_packets"=0, "rx_128_to_255_packets"=0,
> "rx_1523_to_max_packets"=0, "rx_1_to_64_packets"=0,
> "rx_256_to_511_packets"=0, "rx_512_to_1023_packets"=0,
> "rx_65_to_127_packets"=0, rx_bytes=0, rx_dropped=0, rx_errors=0,
> tx_bytes=0, tx_dropped=8}
> status  : {}
> type: dpdkvhostuser
> 
> Is there any way to do the equivalent of a tcpdump or wireshark on a vhost
> user port?
> 
> Thanks,
> Sundar
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] Traffic fails in vhost user port

2017-04-04 Thread Nadathur, Sundar
> -Original Message-
> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
> Sent: Tuesday, April 4, 2017 12:07 AM
> To: ovs-dev@openvswitch.org; Nadathur, Sundar
> 
> Subject: [ovs-dev] Traffic fails in vhost user port
> 
> Hi Sundar.

> > The flows are configured as below:
> > # ovs-ofctl dump-flows br0
> > NXST_FLOW reply (xid=0x4):
> > cookie=0x0, duration=2833.612s, table=0, n_packets=0, n_bytes=0,
> > idle_age=2833, in_port=1 actions=output:5 cookie=0x2,
> > duration=2819.820s, table=0, n_packets=0, n_bytes=0, idle_age=2819,
> > in_port=5 actions=output:1
> 
> I guess, your flow table configured in a wrong way.
> OpenFlow port of br0 is LOCAL, not 1.
> Try this:
> 
> # ovs-ofctl del-flows br0
> 
> # ovs-ofctl add-flow br0 in_port=5,actions=output:LOCAL # ovs-ofctl add-flow
> br0 in_port=LOCAL,actions=output:5

Thank you, Ilya. I did as you suggested, but the ping traffic from br0 (LOCAL) 
is dropped by the output port 5:
# ovs-ofctl dump-flows br0
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=1922.876s, table=0, n_packets=0, n_bytes=0, 
idle_age=1922, in_port=5 actions=LOCAL
 cookie=0x0, duration=1915.458s, table=0, n_packets=6, n_bytes=252, 
idle_age=116, in_port=LOCAL actions=output:5

# ovs-ofctl dump-ports br0 # <-- Drops in port 5
OFPST_PORT reply (xid=0x2): 2 ports
  port  5: rx pkts=?, bytes=0, drop=0, errs=0, frame=?, over=?, crc=?
   tx pkts=?, bytes=0, drop=5, errs=?, coll=?
  port LOCAL: rx pkts=43, bytes=2118, drop=0, errs=0, frame=0, over=0, crc=0
   tx pkts=0, bytes=0, drop=0, errs=0, coll=0

Wireshark shows that br0 sends out 3 ARP requests but there is no response. 

> or
> 
> # ovs-ofctl add-flow br0 actions=NORMAL
I tried this too after doing del-flows. The LOCAL port's MAC is learnt, 
wireshark still shows br0 sending out ARP requests with no response. 

BTW, 'ovs-vsctl list Interface' shows the vi1 (VM port, #5) is up (most fields 
are blank):
_uuid   : 30d1600a-ff7d-4bf5-9fdb-b0767af3611c
admin_state : up
. . .
link_speed  : []
link_state  : up
. . .
mac_in_use  : "00:00:00:00:00:00"
mtu : 1500
mtu_request : []
name: "vi1"
. . .
statistics  : {"rx_1024_to_1518_packets"=0, "rx_128_to_255_packets"=0, 
"rx_1523_to_max_packets"=0, "rx_1_to_64_packets"=0, "rx_256_to_511_packets"=0, 
"rx_512_to_1023_packets"=0, "rx_65_to_127_packets"=0, rx_bytes=0, rx_dropped=0, 
rx_errors=0, tx_bytes=0, tx_dropped=8}
status  : {}
type: dpdkvhostuser

Is there any way to do the equivalent of a tcpdump or wireshark on a vhost user 
port?

Thanks,
Sundar
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


Re: [ovs-dev] [PATCH v2] netdev-dpdk: Create separate memory pool for each port

2017-04-04 Thread Robert Wojciechowicz
On Fri, Feb 24, 2017 at 11:27:12AM +, Robert Wojciechowicz wrote:
> Since it's possible to delete memory pool in DPDK
> we can try to estimate better required memory size
> when port is reconfigured, e.g. with different number
> of rx queues.
> 
> Signed-off-by: Robert Wojciechowicz 
> Acked-by: Ian Stokes 
> ---
> v2:
> - removing mempool reference counter
> - making sure mempool name isn't longer than RTE_MEMPOOL_NAMESIZE

Did anyone have time to look into this patch?
Does it make sense or static allocation is better for some reason?

Br,
Robert

___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] Traffic fails in vhost user port

2017-04-04 Thread Ilya Maximets
Hi Sundar.

> Hi,
> I have an OVS bridge br0 with no NICs and  1 vhost user port which is 
> connected to a VM. But ping fails between the VM and the br0 port, either 
> way. The stats show zero all the time. Inside the VM, tcpdump shows nothing.
> 
> This is with OVS 2.7.0 and DPDK 17.02. Please indicate what could be going 
> wrong.
> 
> In the host, the bridge's internal port is up.
> # ip addr show br0
> 24: br0:  mtu 1500 qdisc noqueue state UNKNOWN 
> qlen 500
> link/ether 52:2f:57:13:d8:40 brd ff:ff:ff:ff:ff:ff
> inet 200.1.1.1/24 scope global br0
>valid_lft forever preferred_lft forever
> 
> In the VM, the eth interface is up with address 200.1.1.2/24.
> 
> The ports are in the following state, even after "ovs-ofctl mod-port br0 vi1 
> up":
> # ovs-ofctl dump-ports-desc br0
> OFPST_PORT_DESC reply (xid=0x2):
> 5(vi1): addr:00:00:00:00:00:00
>  config: 0
>  state:  0
>  speed: 0 Mbps now, 0 Mbps max
> LOCAL(br0): addr:52:2f:57:13:d8:40
>  config: 0
>  state:  0
>  current:10MB-FD COPPER
>  speed: 10 Mbps now, 0 Mbps max
> 
> The flows are configured as below:
> # ovs-ofctl dump-flows br0
> NXST_FLOW reply (xid=0x4):
> cookie=0x0, duration=2833.612s, table=0, n_packets=0, n_bytes=0, 
> idle_age=2833, in_port=1 actions=output:5
> cookie=0x2, duration=2819.820s, table=0, n_packets=0, n_bytes=0, 
> idle_age=2819, in_port=5 actions=output:1

I guess, your flow table configured in a wrong way.
OpenFlow port of br0 is LOCAL, not 1.
Try this:

# ovs-ofctl del-flows br0

# ovs-ofctl add-flow br0 in_port=5,actions=output:LOCAL
# ovs-ofctl add-flow br0 in_port=LOCAL,actions=output:5

or

# ovs-ofctl add-flow br0 actions=NORMAL

> 
> The table info is as below:
> # ovs-ofctl dump-tables br0 | more
> OFPST_TABLE reply (xid=0x2):
>   table 0 ("classifier"):
> active=2, lookup=37, matched=28
> max_entries=100
> matching:
>   in_port: exact match or wildcard
>   eth_src: exact match or wildcard
>   eth_dst: exact match or wildcard
>   eth_type: exact match or wildcard
>   vlan_vid: exact match or wildcard
>   vlan_pcp: exact match or wildcard
>   ip_src: exact match or wildcard
>   ip_dst: exact match or wildcard
>   nw_proto: exact match or wildcard
>   nw_tos: exact match or wildcard
>   tcp_src: exact match or wildcard
>   tcp_dst: exact match or wildcard
> 
>   table 1 ("table1"):
>active=0, lookup=0, matched=0
> (same features)
> 
> Thanks,
> Sundar
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev


[ovs-dev] Offer!!!!

2017-04-04 Thread Alex Marcus


Guten Tag, Wir sind eine eingetragene Private Geldverleiher . Wir geben, 
Kredite Menschen zu helfen, Unternehmen müssen aktualisieren, die ihre 
finanzielle Situation in der ganzen Welt, mit Minimal jährlichen Zinsen von 2%.
Good Day, We are a registered private money lender. We give out loans to assist 
people, firms who need to update their financial status all over the world, 
with Minimal annual Interest Rates of 2%.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev