Re: [ovs-dev] [PATCH v3] netdev-dpdk: leverage the mempool offload support

[Darrell Ball]

One minor comment

On 3/24/17, 12:27 AM, "Hemant Agrawal"  wrote:

DPDK 16.07 introduced the support for mempool offload support.
rte_pktmbuf_pool_create is the recommended method for creating pktmbuf
pools. Buffer pools created with rte_mempool_create may not get offloaded
to the underlying offloaded mempools.

This patch, changes the rte_mempool_create to use helper wrapper
"rte_pktmbuf_pool_create" provided by dpdk, so that it can leverage
offloaded mempools.

Signed-off-by: Hemant Agrawal 
---
v3:
 * adding OVS_UNUSED for mp parameter

v2:
 * removing rte_pktmbuf_init as per review comment

 lib/netdev-dpdk.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
index ddc651b..39021cf 100644
--- a/lib/netdev-dpdk.c
+++ b/lib/netdev-dpdk.c
@@ -451,22 +451,19 @@ free_dpdk_buf(struct dp_packet *p)
 }
 
 static void
-ovs_rte_pktmbuf_init(struct rte_mempool *mp,
+ovs_rte_pktmbuf_init(struct rte_mempool *mp OVS_UNUSED,
  void *opaque_arg OVS_UNUSED,
  void *_p,
  unsigned i OVS_UNUSED)
 {
 struct rte_mbuf *pkt = _p;
 
-rte_pktmbuf_init(mp, opaque_arg, _p, i);
-
 dp_packet_init_dpdk((struct dp_packet *) pkt, pkt->buf_len);
 }
 
 static struct dpdk_mp *
 dpdk_mp_create(int socket_id, int mtu)
 {
-struct rte_pktmbuf_pool_private mbp_priv;
 struct dpdk_mp *dmp;
 unsigned mp_size;
 char *mp_name;
@@ -478,9 +475,6 @@ dpdk_mp_create(int socket_id, int mtu)
 dmp->socket_id = socket_id;
 dmp->mtu = mtu;
 dmp->refcount = 1;
-mbp_priv.mbuf_data_room_size = MBUF_SIZE(mtu) - sizeof(struct 
dp_packet);
-mbp_priv.mbuf_priv_size = sizeof(struct dp_packet)
-  - sizeof(struct rte_mbuf);
 /* XXX: this is a really rough method of provisioning memory.
  * It's impossible to determine what the exact memory requirements are
  * when the number of ports and rxqs that utilize a particular mempool 
can
@@ -496,18 +490,21 @@ dpdk_mp_create(int socket_id, int mtu)
 mp_name = xasprintf("ovs_mp_%d_%d_%u", dmp->mtu, dmp->socket_id,
 mp_size);
 
-dmp->mp = rte_mempool_create(mp_name, mp_size, MBUF_SIZE(mtu),
- MP_CACHE_SZ,
- sizeof(struct 
rte_pktmbuf_pool_private),
- rte_pktmbuf_pool_init, _priv,
- ovs_rte_pktmbuf_init, NULL,
- socket_id, 0);
+dmp->mp = rte_pktmbuf_pool_create(mp_name, mp_size,
+  MP_CACHE_SZ,
+  sizeof (struct dp_packet)
+ - sizeof (struct 
rte_mbuf),
+  MBUF_SIZE(mtu)
+ - sizeof(struct 
dp_packet),
+  socket_id);
 if (dmp->mp) {
 VLOG_DBG("Allocated \"%s\" mempool with %u mbufs",
  mp_name, mp_size);
 }
 free(mp_name);
 if (dmp->mp) {
+/* pktmbuf only prepare the rte_mbuf, prepare the ovs bufs */


/*  rte_pktmbuf_pool_create has done some initialization of the rte_mbuf
  * part of each dp_packet, while ovs_rte_pktmbuf_init initializes some OVS
  * specific fields of dp_packet. */

I also gave the patch a spin, just to check for any regressions.


+rte_mempool_obj_iter(dmp->mp, ovs_rte_pktmbuf_init, NULL);
 return dmp;
 }
 } while (rte_errno == ENOMEM && (mp_size /= 2) >= MIN_NB_MBUF);
-- 
1.9.1



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

[ovs-dev] ovs-vsctl: Error detected while setting up 'dpdk-p0': Error attaching device '0000:43:00.0' to DPDK.

[Deepti Sabnani]

HI,

 

I have bound a port to dpdk using the dpdk-devbind.sh script 

 

root@compute16:/usr/src/dpdk-stable-16.11.1# $DPDK_DIR/tools/dpdk-devbind.py
--bind=vfio-pci eth4

root@compute16:/usr/src/dpdk-stable-16.11.1# $DPDK_DIR/tools/dpdk-devbind.py
--status

 

Network devices using DPDK-compatible driver



:43:00.0 'Myri-10G Dual-Protocol NIC' drv=vfio-pci
unused=myri10ge,igb_uio

But I am unable to add the port to the bridge.

ds2283@compute16:~/ovs$ sudo ovs-vsctl add-port br0 dpdk-p0 -- set Interface
dpdk-p0 type=dpdk options:dpdk-devargs=:43:00.0

ovs-vsctl: Error detected while setting up 'dpdk-p0': Error attaching device
':43:00.0' to DPDK.  See ovs-vswitchd log for details.

ovs-vsctl: The default log directory is "/usr/local/var/log/openvswitch".

ds2283@compute16:~/ovs$

 

I have followed the steps from this link to install OVS:
https://github.com/openvswitch/ovs/blob/master/Documentation/intro/install/g
eneral.rst

And http://docs.openvswitch.org/en/latest/intro/install/dpdk/ to install and
setup DPDK.

 

Right now this is the status of hugepages:

ds2283@compute16:~/ovs$ grep Huge /proc/meminfo

AnonHugePages:548864 kB

HugePages_Total:2048

HugePages_Free: 1536

HugePages_Rsvd:0

HugePages_Surp:0

Hugepagesize:   2048 kB

ds2283@compute16:~/ovs$

 

I had allocated 1024 hugepages of 2M for Node0 and 1024 hugepages for Node2.

 

Here are some other configurations and logs:

ds2283@compute16:~/ovs$ sudo ovs-vswitchd unix:$DB_SOCK --pidfile --detach

2017-04-11T01:44:10Z|1|ovs_numa|INFO|Discovered 16 CPU cores on NUMA
node 0

2017-04-11T01:44:10Z|2|ovs_numa|INFO|Discovered 16 CPU cores on NUMA
node 1

2017-04-11T01:44:10Z|3|ovs_numa|INFO|Discovered 2 NUMA nodes and 32 CPU
cores

2017-04-11T01:44:10Z|4|reconnect|INFO|unix:/usr/local/var/run/openvswitc
h/db.sock: connecting...

2017-04-11T01:44:10Z|5|reconnect|INFO|unix:/usr/local/var/run/openvswitc
h/db.sock: connected

2017-04-11T01:44:10Z|6|dpdk|INFO|DPDK Enabled - initializing...

2017-04-11T01:44:10Z|7|dpdk|INFO|No vhost-sock-dir provided - defaulting
to /usr/local/var/run/openvswitch

2017-04-11T01:44:10Z|8|dpdk|INFO|EAL ARGS: ovs-vswitchd --socket-mem
1024,0 -c 0x0001

2017-04-11T01:44:10Z|9|dpdk|INFO|EAL: Detected 32 lcore(s)

2017-04-11T01:44:10Z|00010|dpdk|WARN|EAL: No free hugepages reported in
hugepages-1048576kB

2017-04-11T01:44:10Z|00011|dpdk|INFO|EAL: Probing VFIO support...

2017-04-11T01:44:10Z|00012|dpdk|INFO|EAL: VFIO support initialized

2017-04-11T01:44:11Z|00013|dpdk|INFO|DPDK Enabled - initialized

2017-04-11T01:44:11Z|00014|timeval|WARN|Unreasonably long 1115ms poll
interval (20ms user, 996ms system)

2017-04-11T01:44:11Z|00015|timeval|WARN|faults: 2799 minor, 0 major

2017-04-11T01:44:11Z|00016|timeval|WARN|context switches: 3 voluntary, 5
involuntary

2017-04-11T01:44:11Z|00017|coverage|INFO|Event coverage, avg rate over last:
5 seconds, last minute, last hour,  hash=edcf6a06:

2017-04-11T01:44:11Z|00018|coverage|INFO|bridge_reconfigure 0.0/sec
0.000/sec0./sec   total: 1

2017-04-11T01:44:11Z|00019|coverage|INFO|cmap_expand0.0/sec
0.000/sec0./sec   total: 8

2017-04-11T01:44:11Z|00020|coverage|INFO|miniflow_malloc0.0/sec
0.000/sec0./sec   total: 15

2017-04-11T01:44:11Z|00021|coverage|INFO|hmap_pathological  0.0/sec
0.000/sec0./sec   total: 1

2017-04-11T01:44:11Z|00022|coverage|INFO|hmap_expand0.0/sec
0.000/sec0./sec   total: 384

2017-04-11T01:44:11Z|00023|coverage|INFO|txn_unchanged  0.0/sec
0.000/sec0./sec   total: 2

2017-04-11T01:44:11Z|00024|coverage|INFO|txn_incomplete 0.0/sec
0.000/sec0./sec   total: 1

2017-04-11T01:44:11Z|00025|coverage|INFO|poll_create_node   0.0/sec
0.000/sec0./sec   total: 40

2017-04-11T01:44:11Z|00026|coverage|INFO|seq_change 0.0/sec
0.000/sec0./sec   total: 62

2017-04-11T01:44:11Z|00027|coverage|INFO|pstream_open   0.0/sec
0.000/sec0./sec   total: 1

2017-04-11T01:44:11Z|00028|coverage|INFO|stream_open0.0/sec
0.000/sec0./sec   total: 1

2017-04-11T01:44:11Z|00029|coverage|INFO|util_xalloc0.0/sec
0.000/sec0./sec   total: 7335

2017-04-11T01:44:11Z|00030|coverage|INFO|netdev_get_hwaddr  0.0/sec
0.000/sec0./sec   total: 4

2017-04-11T01:44:11Z|00031|coverage|INFO|netlink_received   0.0/sec
0.000/sec0./sec   total: 3

2017-04-11T01:44:11Z|00032|coverage|INFO|netlink_sent   0.0/sec
0.000/sec0./sec   total: 1

2017-04-11T01:44:11Z|00033|coverage|INFO|89 events never hit

ds2283@compute16:~/ovs$

 

ds2283@compute16:~/ovs$ sudo ovs-vsctl add-port br0 vhostuser0 -- set
Interface vhostuser0 type=dpdkvhostuser

Re: [ovs-dev] [ovs-discuss] ovn: unsnat handling error for Distributed Gateway

[Mickey Spiegel]

On Sun, Apr 9, 2017 at 3:23 PM, Mickey Spiegel 
wrote:

>
>
> On Thu, Apr 6, 2017 at 7:34 AM, Guoshuai Li  wrote:
>
>>
>> revese my topology:
>>
>>  +-++
>>  |  VM  172.16.1.7  |
>>  +-++
>>|
>>  +-++
>>  |  Logical Switch  |
>>  +-++
>>|172.16.1.254
>>   10.157.142.3 +---++
>>   ++  Logical Router 1  +
>>   |++
>> +-++
>> |  Logical Switch  |
>> +--+
>>   |++
>>   ++  Logical Router 2  |
>>   10.157.142.1 ++
>>
>>
>> Hi All, I am having a problem for ovn and need help, thanks.
>>>
>>>
>>> I created two logical routes and connected the two LogicalRoutes through
>>> a external LogicalSwitch (connected to the external network) .
>>>
>>> And then LogicalRoute-1 connected to the VM through the internal
>>> LogicalSwitch .
>>>
>>> my topology:
>>>
>>>   10.157.142.3  172.16.1.254
>>>++ +-++
>>>  +-++
>>>   ++  Logical Router 1 +--|
>>> Logical Switch  +---+ VM 172.16.1.7   |
>>>   |++ +--+
>>>  +--+
>>> +-++
>>> |  Logical Switch  |
>>> +--+
>>>   |++
>>>   ++  Logical Router 2  |
>>>++
>>>   10.157.142.1
>>>
>>> I tested the master and Branch2.7, it Can not be transferred from VM
>>> (172.16.1.7) to LogicaRouter-2 's port (10.157.142.
>>>
>> Sorry, The destination address is 10.157.142.1, And The SNAT/unSNAT
>> address is 10.157.142.3.
>>
>>> ) via ping.
>>> My logical router is a distributed gateway, and the two logical router
>>> ports that connect external LogicalSwitch are on the same chassis.
>>> If the two logical router ports are not on the same chassis ping is also
>>> OK, And ping from VM (172.16.1.7) to external network is also OK.
>>>
>>> I looked at the openflow tables on gateway chassis,  I suspected unsnat
>>> handling error in Router1 input for icmp replay.
>>> I think it is necessary to replace the destination address 10.157.142.3
>>> with 172.16.1.7 in Table 19 and route 172.16.1.7 in Table 21, but now the
>>> route match is 10.157.142.0/24.
>>>
>>> cookie=0x92bd0055, duration=68.468s, table=16, n_packets=1, n_bytes=98,
>>> idle_age=36, priority=50,reg14=0x4,metadata=0x7,dl_dst=fa:16:3e:58:1c:8a
>>> actions=resubmit(,17)
>>> cookie=0x45765344, duration=68.467s, table=17, n_packets=1, n_bytes=98,
>>> idle_age=36, priority=0,metadata=0x7 actions=resubmit(,18)
>>> cookie=0xaeaaed29, duration=68.479s, table=18, n_packets=1, n_bytes=98,
>>> idle_age=36, priority=0,metadata=0x7 actions=resubmit(,19)
>>> cookie=0xce785d51, duration=68.479s, table=19, n_packets=1, n_bytes=98,
>>> idle_age=36, priority=100,ip,reg14=0x4,metadata=0x7,nw_dst=10.157.142.3
>>> actions=ct(table=20,zone=NXM_NX_REG12[0..15],nat)
>>> cookie=0xbd994421, duration=68.481s, table=20, n_packets=1, n_bytes=98,
>>> idle_age=36, priority=0,metadata=0x7 actions=resubmit(,21)
>>> cookie=0xaea3a6ae, duration=68.479s, table=21, n_packets=1, n_bytes=98,
>>> idle_age=36, priority=49,ip,metadata=0x7,nw_dst=10.157.142.0/24
>>> actions=dec_ttl(),move:NXM_OF_IP_DST[]->NXM_NX_XXREG0[96..12
>>> 7],load:0xa9d8e03->NXM_NX_XXREG0[64..95],mod_dl_src:fa:16:3e
>>> :58:1c:8a,load:0x4->NXM_NX_REG15[],load:0x1->NXM_NX_REG10[0]
>>> ,resubmit(,22)
>>> cookie=0xce6e8d4e, duration=68.482s, table=22, n_packets=1, n_bytes=98,
>>> idle_age=36, priority=0,ip,metadata=0x7 actions=push:NXM_NX_REG0[],pus
>>> h:NXM_NX_XXREG0[96..127],pop:NXM_NX_REG0[],mod_dl_dst:00:00:
>>> 00:00:00:00,resubmit(,66),pop:NXM_NX_REG0[],resubmit(,23)
>>> cookie=0xce89c4ed, duration=68.481s, table=23, n_packets=1, n_bytes=98,
>>> idle_age=36, priority=150,reg15=0x4,metadata=0x7,dl_dst=00:00:00:00:00:00
>>> actions=load:0x5->NXM_NX_REG15[],resubmit(,24)
>>> cookie=0xb2d84350, duration=68.469s, table=24, n_packets=1, n_bytes=98,
>>> idle_age=36, priority=100,ip,metadata=0x7,dl_dst=00:00:00:00:00:00
>>>
>>> I do not know why and need help, thanks.
>>>
>>
> I was able to reproduce this. I agree with your analysis. Looking at
> ovs-ofctl dump-flows, the packet counts indicate that the packet is subject
> to ct(...,nat), but the routing table match is as if NAT never occurred.
>
> I 

Re: [ovs-dev] [PATCH] datapath: Avoid struct copy on conntrack labels.

[Andy Zhou]

On Sat, Apr 1, 2017 at 8:24 PM, Jarno Rajahalme  wrote:
> Older kernels have variable sized labels, and the struct itself
> contains only the length, so we must memcpy the bits explicitly.
>
> The modified system test fails on older kernels without this change.
>
> VMware-BZ: #1841876
> Fixes: 09aa98ad496d ("datapath: Inherit master's labels.")
> Signed-off-by: Jarno Rajahalme 

I have a comment in line.
Acked-by: Andy Zhou 


> ---
>  datapath/conntrack.c|  2 +-
>  tests/system-traffic.at | 18 +-
>  2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/datapath/conntrack.c b/datapath/conntrack.c
> index 4df7352..cb8b3ff 100644
> --- a/datapath/conntrack.c
> +++ b/datapath/conntrack.c
> @@ -367,7 +367,7 @@ static int ovs_ct_init_labels(struct nf_conn *ct, struct 
> sw_flow_key *key,
>
> /* Inherit the master's labels, if any. */
> if (master_cl)
> -   *cl = *master_cl;
> +   memcpy(cl->bits, master_cl->bits, OVS_CT_LABELS_LEN);

This changes from what up stream code looks like. (So that it can work
with older version). To make future back-port easier, may be we should
add an comment around this line to explain the change?
>
> if (have_mask) {
> u32 *dst = (u32 *)cl->bits;
> diff --git a/tests/system-traffic.at b/tests/system-traffic.at
> index 1816b1a..c042773 100644
> --- a/tests/system-traffic.at
> +++ b/tests/system-traffic.at
> @@ -3044,7 +3044,7 @@ dnl Non-REPLY/RELATED packets get the ACL lookup with 
> the packet headers
>  dnl in the actual packet direction in reg0 (IN=1, OUT=2).  REPLY packets
>  dnl get the ACL lookup using the conntrack tuple and the inverted direction.
>  dnl RELATED packets get ACL lookup using the conntrack tuple in the direction
> -dnl of the master connection, as storted in ct_mark.
> +dnl of the master connection, as stored in ct_label[0].
>  dnl
>  dnl Incoming non-related packet in the original direction (ACL IN)
>  table=1 reg3=1, ip, ct_state=-rel-rpl+trk-inv 
> action=set_field:1->reg0,resubmit(,3),goto_table:5
> @@ -3056,7 +3056,7 @@ dnl Outgoing non-related reply packet (CT ACL IN)
>  table=1 reg3=2, ip, ct_state=-rel+rpl+trk-inv 
> action=set_field:1->reg0,resubmit(,3,ct),goto_table:4
>  dnl
>  dnl Related packet (CT ACL in the direction of the master connection.)
> -table=1 ip, ct_state=+rel+trk-inv, 
> action=move:NXM_NX_CT_MARK[[]]->NXM_NX_REG0[[]],resubmit(,3,ct),goto_table:4
> +table=1 ip, ct_state=+rel+trk-inv, 
> action=move:NXM_NX_CT_LABEL[[0]]->NXM_NX_REG0[[0]],resubmit(,3,ct),goto_table:4
>  dnl Drop everything else.
>  table=1 priority=0, action=drop
>  dnl
> @@ -3088,15 +3088,15 @@ table=5 reg2=0 priority=1000 action=drop
>  dnl
>  dnl Commit new incoming FTP control connections with SNAT range.  Must match 
> on
>  dnl 'tcp' when setting 'alg=ftp'.  Store the directionality of non-related
> -dnl connections to ct_mark.  Store the rule ID to labels.
> -table=5 priority=100 reg2=1 reg3=1 ct_state=+new-rel, tcp, tp_dst=21, 
> action=ct(zone=NXM_NX_REG4[[0..15]],alg=ftp,commit,nat(src=$2),exec(move:NXM_NX_REG3[[0..31]]->NXM_NX_CT_MARK[[0..31]],move:NXM_NX_REG1[[0..31]]->NXM_NX_CT_LABEL[[96..127]])),goto_table:6
> +dnl connections to ct_label[0]  Store the rule ID to ct_label[96..127].
> +table=5 priority=100 reg2=1 reg3=1 ct_state=+new-rel, tcp, tp_dst=21, 
> action=ct(zone=NXM_NX_REG4[[0..15]],alg=ftp,commit,nat(src=$2),exec(move:NXM_NX_REG3[[0]]->NXM_NX_CT_LABEL[[0]],move:NXM_NX_REG1[[0..31]]->NXM_NX_CT_LABEL[[96..127]])),goto_table:6
>  dnl Commit other new incoming non-related IP connections with SNAT range.
> -table=5 priority=10 reg2=1 reg3=1 ct_state=+new-rel, ip, 
> action=ct(zone=NXM_NX_REG4[[0..15]],commit,nat(src=$2),exec(move:NXM_NX_REG3[[0..31]]->NXM_NX_CT_MARK[[0..31]],move:NXM_NX_REG1[[0..31]]->NXM_NX_CT_LABEL[[96..127]])),goto_table:6
> +table=5 priority=10 reg2=1 reg3=1 ct_state=+new-rel, ip, 
> action=ct(zone=NXM_NX_REG4[[0..15]],commit,nat(src=$2),exec(move:NXM_NX_REG3[[0]]->NXM_NX_CT_LABEL[[0]],move:NXM_NX_REG1[[0..31]]->NXM_NX_CT_LABEL[[96..127]])),goto_table:6
>  dnl Commit non-related outgoing new IP connections with DNAT range.
>  dnl (This should not get any packets in this test.)
> -table=5 priority=10 reg2=1 reg3=2 ct_state=+new-rel, ip, 
> action=ct(zone=NXM_NX_REG4[[0..15]],commit,nat(dst=$2),exec(move:NXM_NX_REG3[[0..31]]->NXM_NX_CT_MARK[[0..31]],move:NXM_NX_REG1[[0..31]]->NXM_NX_CT_LABEL[[96..127]])),goto_table:6
> +table=5 priority=10 reg2=1 reg3=2 ct_state=+new-rel, ip, 
> action=ct(zone=NXM_NX_REG4[[0..15]],commit,nat(dst=$2),exec(move:NXM_NX_REG3[[0]]->NXM_NX_CT_LABEL[[0]],move:NXM_NX_REG1[[0..31]]->NXM_NX_CT_LABEL[[96..127]])),goto_table:6
>  dnl Commit new related connections in either direction, which need 'nat'
> -dnl and which inherit the mark (the direction of the original direction
> +dnl and which inherit the label (the direction of the original direction
>  dnl master 

[ovs-dev] [PATCH 4/4 v3] datapath-windows: NAT integration with conntrack

[Yin Lin]

Signed-off-by: Yin Lin 
---
 datapath-windows/ovsext/Actions.c  | 119 -
 datapath-windows/ovsext/Actions.h  |  20 
 datapath-windows/ovsext/Conntrack.c| 188 +
 datapath-windows/ovsext/Conntrack.h|  25 +++--
 datapath-windows/ovsext/ovsext.vcxproj |   2 +
 5 files changed, 272 insertions(+), 82 deletions(-)

diff --git a/datapath-windows/ovsext/Actions.c 
b/datapath-windows/ovsext/Actions.c
index 3bd00a7..5872ca5 100644
--- a/datapath-windows/ovsext/Actions.c
+++ b/datapath-windows/ovsext/Actions.c
@@ -1331,7 +1331,7 @@ PUINT8 OvsGetHeaderBySize(OvsForwardingContext *ovsFwdCtx,
  *  based on the specified key.
  *
  */
-static __inline NDIS_STATUS
+NDIS_STATUS
 OvsUpdateUdpPorts(OvsForwardingContext *ovsFwdCtx,
   const struct ovs_key_udp *udpAttr)
 {
@@ -1378,7 +1378,7 @@ OvsUpdateUdpPorts(OvsForwardingContext *ovsFwdCtx,
  *  based on the specified key.
  *
  */
-static __inline NDIS_STATUS
+NDIS_STATUS
 OvsUpdateTcpPorts(OvsForwardingContext *ovsFwdCtx,
   const struct ovs_key_tcp *tcpAttr)
 {
@@ -1416,12 +1416,125 @@ OvsUpdateTcpPorts(OvsForwardingContext *ovsFwdCtx,
 
 /*
  *
+ * OvsUpdateAddressAndPort --
+ *  Updates the source/destination IP and port fields in
+ *  ovsFwdCtx.curNbl inline based on the specified key.
+ *
+ */
+OvsUpdateAddressAndPort(OvsForwardingContext *ovsFwdCtx,
+UINT32 newAddr, UINT16 newPort,
+BOOLEAN isSource, BOOLEAN isTx)
+{
+PUINT8 bufferStart;
+UINT32 hdrSize;
+OVS_PACKET_HDR_INFO *layers = >layers;
+IPHdr *ipHdr;
+TCPHdr *tcpHdr = NULL;
+UDPHdr *udpHdr = NULL;
+UINT32 *addrField = NULL;
+UINT16 *portField = NULL;
+UINT16 *checkField = NULL;
+BOOLEAN l4Offload = FALSE;
+NDIS_TCP_IP_CHECKSUM_NET_BUFFER_LIST_INFO csumInfo;
+
+ASSERT(layers->value != 0);
+
+if (layers->isTcp || layers->isUdp) {
+hdrSize = layers->l4Offset +
+  layers->isTcp ? sizeof (*tcpHdr) : sizeof (*udpHdr);
+} else {
+hdrSize = layers->l3Offset + sizeof (*ipHdr);
+}
+
+bufferStart = OvsGetHeaderBySize(ovsFwdCtx, hdrSize);
+if (!bufferStart) {
+return NDIS_STATUS_RESOURCES;
+}
+
+ipHdr = (IPHdr *)(bufferStart + layers->l3Offset);
+
+if (layers->isTcp) {
+tcpHdr = (TCPHdr *)(bufferStart + layers->l4Offset);
+} else if (layers->isUdp) {
+udpHdr = (UDPHdr *)(bufferStart + layers->l4Offset);
+}
+
+csumInfo.Value = NET_BUFFER_LIST_INFO(ovsFwdCtx->curNbl,
+  TcpIpChecksumNetBufferListInfo);
+/*
+ * Adjust the IP header inline as dictated by the action, and also update
+ * the IP and the TCP checksum for the data modified.
+ *
+ * In the future, this could be optimized to make one call to
+ * ChecksumUpdate32(). Ignoring this for now, since for the most common
+ * case, we only update the TTL.
+ */
+
+if (isSource) {
+addrField = >saddr;
+if (tcpHdr) {
+portField = >source;
+checkField = >check;
+if (isTx) {
+l4Offload = (csumInfo.Transmit.TcpChecksum != 0);
+}
+}
+else if (udpHdr) {
+portField = >source;
+checkField = >check;
+if (isTx) {
+l4Offload = (csumInfo.Transmit.UdpChecksum != 0);
+}
+}
+} else {
+addrField = >daddr;
+if (tcpHdr) {
+portField = >dest;
+checkField = >check;
+} else if (udpHdr) {
+portField = >dest;
+checkField = >check;
+}
+}
+if (*addrField != newAddr) {
+UINT32 oldAddr = *addrField;
+if (checkField && *checkField != 0) {
+if (l4Offload) {
+/* Recompute IP pseudo checksum */
+*checkField = ~(*checkField);
+*checkField = ChecksumUpdate32(*checkField, oldAddr,
+   newAddr);
+*checkField = ~(*checkField);
+} else {
+*checkField = ChecksumUpdate32(*checkField, oldAddr,
+   newAddr);
+}
+}
+if (ipHdr->check != 0) {
+ipHdr->check = ChecksumUpdate32(ipHdr->check, oldAddr,
+newAddr);
+}
+*addrField = newAddr;
+}
+
+if (portField && *portField != newPort) {
+if (checkField && !l4Offload) {
+*checkField = 

[ovs-dev] [PATCH 3/4 v3] datapath-windows: Add NAT module in conntrack

[Yin Lin]

Signed-off-by: Yin Lin 

Issue: #
Change-Id: I6f37360c36525548b343f0016304015fec8aba7d
---
 datapath-windows/automake.mk|   2 +
 datapath-windows/ovsext/Conntrack-nat.c | 438 
 datapath-windows/ovsext/Conntrack-nat.h |  39 +++
 3 files changed, 479 insertions(+)
 create mode 100644 datapath-windows/ovsext/Conntrack-nat.c
 create mode 100644 datapath-windows/ovsext/Conntrack-nat.h

diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
index 53983ae..296e785 100644
--- a/datapath-windows/automake.mk
+++ b/datapath-windows/automake.mk
@@ -16,7 +16,9 @@ EXTRA_DIST += \
datapath-windows/ovsext/Conntrack-icmp.c \
datapath-windows/ovsext/Conntrack-other.c \
datapath-windows/ovsext/Conntrack-related.c \
+datapath-windows/ovsext/Conntrack-nat.c \
datapath-windows/ovsext/Conntrack-tcp.c \
+datapath-windows/ovsext/Conntrack-nat.h \
datapath-windows/ovsext/Conntrack.c \
datapath-windows/ovsext/Conntrack.h \
datapath-windows/ovsext/Datapath.c \
diff --git a/datapath-windows/ovsext/Conntrack-nat.c 
b/datapath-windows/ovsext/Conntrack-nat.c
new file mode 100644
index 000..17b312c
--- /dev/null
+++ b/datapath-windows/ovsext/Conntrack-nat.c
@@ -0,0 +1,438 @@
+#include "Conntrack-nat.h"
+#include "Jhash.h"
+
+PLIST_ENTRY ovsNatTable = NULL;
+PLIST_ENTRY ovsUnNatTable = NULL;
+static PNDIS_RW_LOCK_EX ovsNatLock;
+
+/*
+ *---
+ * OvsHashNatKey
+ * Hash NAT related fields in a Conntrack key.
+ *---
+ */
+static __inline UINT32
+OvsHashNatKey(const OVS_CT_KEY *key)
+{
+UINT32 hash = 0;
+#define HASH_ADD(field) \
+hash = OvsJhashBytes(>field, sizeof(key->field), hash)
+
+HASH_ADD(src.addr.ipv4_aligned);
+HASH_ADD(dst.addr.ipv4_aligned);
+HASH_ADD(src.port);
+HASH_ADD(dst.port);
+HASH_ADD(zone);
+#undef HASH_ADD
+return hash;
+}
+
+/*
+ *---
+ * OvsNatKeyAreSame
+ * Compare NAT related fields in a Conntrack key.
+ *---
+ */
+static __inline BOOLEAN
+OvsNatKeyAreSame(const OVS_CT_KEY *key1, const OVS_CT_KEY *key2)
+{
+// XXX: Compare IPv6 key as well
+#define FIELD_COMPARE(field) \
+if (key1->field != key2->field) return FALSE
+
+FIELD_COMPARE(src.addr.ipv4_aligned);
+FIELD_COMPARE(dst.addr.ipv4_aligned);
+FIELD_COMPARE(src.port);
+FIELD_COMPARE(dst.port);
+FIELD_COMPARE(zone);
+return TRUE;
+#undef FIELD_COMPARE
+}
+
+/*
+ *---
+ * OvsNaGetBucket
+ * Returns the row of NAT table that has the same hash as the given NAT
+ * hash key. If isReverse is TRUE, returns the row of reverse NAT table
+ * instead.
+ *---
+ */
+static __inline PLIST_ENTRY
+OvsNatGetBucket(const OVS_CT_KEY *key, BOOLEAN isReverse)
+{
+uint32_t hash = OvsHashNatKey(key);
+if (isReverse) {
+return [hash & NAT_HASH_TABLE_MASK];
+} else {
+return [hash & NAT_HASH_TABLE_MASK];
+}
+}
+
+/*
+ *---
+ * OvsNatInit
+ * Initialize NAT related resources.
+ *---
+ */
+NTSTATUS OvsNatInit(POVS_SWITCH_CONTEXT context)
+{
+ASSERT(ovsNatTable == NULL);
+
+/* Init the sync-lock */
+ovsNatLock = NdisAllocateRWLock(context->NdisFilterHandle);
+if (ovsNatLock == NULL) {
+goto failNoMem;
+}
+
+/* Init the Hash Buffer */
+ovsNatTable = OvsAllocateMemoryWithTag(
+sizeof(LIST_ENTRY) * NAT_HASH_TABLE_SIZE,
+OVS_CT_POOL_TAG);
+if (ovsNatTable == NULL) {
+goto freeNatLock;
+}
+
+ovsUnNatTable = OvsAllocateMemoryWithTag(
+sizeof(LIST_ENTRY) * NAT_HASH_TABLE_SIZE,
+OVS_CT_POOL_TAG);
+if (ovsUnNatTable == NULL) {
+goto freeNatTable;
+}
+
+for (int i = 0; i < NAT_HASH_TABLE_SIZE; i++) {
+InitializeListHead([i]);
+InitializeListHead([i]);
+}
+return STATUS_SUCCESS;
+
+freeNatTable:
+OvsFreeMemoryWithTag(ovsNatTable, OVS_CT_POOL_TAG);
+freeNatLock:
+NdisFreeRWLock(ovsNatLock);
+failNoMem:
+return STATUS_INSUFFICIENT_RESOURCES;
+}
+
+/*
+ *
+ * OvsNatFlush
+ * Flushes out all NAT entries that match the given zone.
+ *
+ */
+VOID OvsNatFlush(UINT16 zone)
+{
+LOCK_STATE_EX lockState;
+PLIST_ENTRY link, next;
+NdisAcquireRWLockWrite(ovsNatLock, , 0);
+for 

[ovs-dev] [PATCH 2/4 v3] datapath-windows: Add support for NAT in conntrack

[Yin Lin]

Add support for parsing netlink attributes related to NAT
in conntrack.

Co-Authored-by: Anand Kumar 
Co-Authored-by: Darrell Ball 
Signed-off-by: Yin Lin 
---
 datapath-windows/ovsext/Conntrack.c | 73 -
 datapath-windows/ovsext/Conntrack.h | 17 +
 datapath-windows/ovsext/Flow.c  |  4 +-
 3 files changed, 90 insertions(+), 4 deletions(-)

diff --git a/datapath-windows/ovsext/Conntrack.c 
b/datapath-windows/ovsext/Conntrack.c
index 23de526..404f2dc 100644
--- a/datapath-windows/ovsext/Conntrack.c
+++ b/datapath-windows/ovsext/Conntrack.c
@@ -636,7 +636,8 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,
   UINT16 zone,
   MD_MARK *mark,
   MD_LABELS *labels,
-  PCHAR helper)
+  PCHAR helper,
+  PNAT_ACTION_INFO natInfo)
 {
 NDIS_STATUS status = NDIS_STATUS_SUCCESS;
 POVS_CT_ENTRY entry = NULL;
@@ -645,6 +646,9 @@ OvsCtExecute_(PNET_BUFFER_LIST curNbl,
 UINT64 currentTime;
 NdisGetCurrentSystemTime((LARGE_INTEGER *) );
 
+/* XXX: Not referenced for now */
+UNREFERENCED_PARAMETER(natInfo);
+
 /* Retrieve the Conntrack Key related fields from packet */
 OvsCtSetupLookupCtx(key, zone, , curNbl, layers->l4Offset);
 
@@ -712,11 +716,14 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
 MD_MARK *mark = NULL;
 MD_LABELS *labels = NULL;
 PCHAR helper = NULL;
+NAT_ACTION_INFO natActionInfo;
 PNET_BUFFER_LIST curNbl = fwdCtx->curNbl;
 OVS_PACKET_HDR_INFO *layers = >layers;
 
+NAT_ACTION_INFO natActionInfo;
 NDIS_STATUS status;
 
+memset(, 0, sizeof natActionInfo);
 status = OvsDetectCtPacket(key);
 if (status != NDIS_STATUS_SUCCESS) {
 return status;
@@ -738,6 +745,68 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
 if (ctAttr) {
 labels = NlAttrGet(ctAttr);
 }
+natActionInfo.natAction = NAT_ACTION_NONE;
+ctAttr = NlAttrFindNested(a, OVS_CT_ATTR_NAT);
+if (ctAttr) {
+/* Pares Nested NAT attributes. */
+PNL_ATTR natAttr;
+unsigned int left;
+BOOLEAN hasMinIp = FALSE;
+BOOLEAN hasMinPort = FALSE;
+BOOLEAN hasMaxIp = FALSE;
+BOOLEAN hasMaxPort = FALSE;
+NL_NESTED_FOR_EACH_UNSAFE (natAttr, left, ctAttr) {
+enum ovs_nat_attr sub_type_nest = NlAttrType(natAttr);
+switch(sub_type_nest) {
+case OVS_NAT_ATTR_SRC:
+case OVS_NAT_ATTR_DST:
+natActionInfo.natAction |=
+((sub_type_nest == OVS_NAT_ATTR_SRC)
+? NAT_ACTION_SRC : NAT_ACTION_DST);
+break;
+case OVS_NAT_ATTR_IP_MIN:
+memcpy(,
+   NlAttrData(natAttr), natAttr->nlaLen - NLA_HDRLEN);
+hasMinIp = TRUE;
+break;
+case OVS_NAT_ATTR_IP_MAX:
+memcpy(,
+   NlAttrData(natAttr), natAttr->nlaLen - NLA_HDRLEN);
+hasMaxIp = TRUE;
+break;
+case OVS_NAT_ATTR_PROTO_MIN:
+natActionInfo.minPort = NlAttrGetU16(natAttr);
+hasMinPort = TRUE;
+break;
+case OVS_NAT_ATTR_PROTO_MAX:
+natActionInfo.maxPort = NlAttrGetU16(natAttr);
+hasMaxPort = TRUE;
+break;
+case OVS_NAT_ATTR_PERSISTENT:
+case OVS_NAT_ATTR_PROTO_HASH:
+case OVS_NAT_ATTR_PROTO_RANDOM:
+break;
+}
+}
+if (natActionInfo.natAction == NAT_ACTION_NONE) {
+natActionInfo.natAction = NAT_ACTION_REVERSE;
+}
+if (hasMinIp && !hasMaxIp) {
+memcpy(,
+   ,
+   sizeof(natActionInfo.maxAddr));
+}
+if (hasMinPort && !hasMaxPort) {
+natActionInfo.maxPort = natActionInfo.minPort;
+}
+if (hasMinPort || hasMaxPort) {
+if (natActionInfo.natAction & NAT_ACTION_SRC) {
+natActionInfo.natAction |= NAT_ACTION_SRC_PORT;
+} else if (natActionInfo.natAction & NAT_ACTION_DST) {
+natActionInfo.natAction |= NAT_ACTION_DST_PORT;
+}
+}
+}
 ctAttr = NlAttrFindNested(a, OVS_CT_ATTR_HELPER);
 if (ctAttr) {
 helper = NlAttrGetString(ctAttr);
@@ -751,7 +820,7 @@ OvsExecuteConntrackAction(OvsForwardingContext *fwdCtx,
 }
 
 status = OvsCtExecute_(curNbl, key, layers,
-   commit, zone, mark, labels, helper);
+   commit, zone, mark, labels, helper, );
 return status;
 }
 
diff --git a/datapath-windows/ovsext/Conntrack.h 
b/datapath-windows/ovsext/Conntrack.h
index 87d7eeb..1ad289f 100644
--- a/datapath-windows/ovsext/Conntrack.h
+++ b/datapath-windows/ovsext/Conntrack.h

[ovs-dev] [PATCH 1/4 v3] datapath-windows: Pass fwdCtx to conntrack

[Yin Lin]

---
 datapath-windows/ovsext/Actions.c   | 61 ++---
 datapath-windows/ovsext/Actions.h   | 58 +++
 datapath-windows/ovsext/Conntrack.c |  5 +--
 datapath-windows/ovsext/Conntrack.h |  4 +--
 4 files changed, 65 insertions(+), 63 deletions(-)

diff --git a/datapath-windows/ovsext/Actions.c 
b/datapath-windows/ovsext/Actions.c
index 46f84bc..3bd00a7 100644
--- a/datapath-windows/ovsext/Actions.c
+++ b/datapath-windows/ovsext/Actions.c
@@ -71,63 +71,6 @@ typedef struct _OVS_ACTION_STATS {
 OVS_ACTION_STATS ovsActionStats;
 
 /*
- * There a lot of data that needs to be maintained while executing the pipeline
- * as dictated by the actions of a flow, across different functions at 
different
- * levels. Such data is put together in a 'context' structure. Care should be
- * exercised while adding new members to the structure - only add ones that get
- * used across multiple stages in the pipeline/get used in multiple functions.
- */
-typedef struct OvsForwardingContext {
-POVS_SWITCH_CONTEXT switchContext;
-/* The NBL currently used in the pipeline. */
-PNET_BUFFER_LIST curNbl;
-/* NDIS forwarding detail for 'curNbl'. */
-PNDIS_SWITCH_FORWARDING_DETAIL_NET_BUFFER_LIST_INFO fwdDetail;
-/* Array of destination ports for 'curNbl'. */
-PNDIS_SWITCH_FORWARDING_DESTINATION_ARRAY destinationPorts;
-/* send flags while sending 'curNbl' into NDIS. */
-ULONG sendFlags;
-/* Total number of output ports, used + unused, in 'curNbl'. */
-UINT32 destPortsSizeIn;
-/* Total number of used output ports in 'curNbl'. */
-UINT32 destPortsSizeOut;
-/*
- * If 'curNbl' is not owned by OVS, they need to be tracked, if they need 
to
- * be freed/completed.
- */
-OvsCompletionList *completionList;
-/*
- * vport number of 'curNbl' when it is passed from the PIF bridge to the 
INT
- * bridge. ie. during tunneling on the Rx side.
- */
-UINT32 srcVportNo;
-
-/*
- * Tunnel key:
- * - specified in actions during tunneling Tx
- * - extracted from an NBL during tunneling Rx
- */
-OvsIPv4TunnelKey tunKey;
-
-/*
- * Tunneling - Tx:
- * To store the output port, when it is a tunneled port. We don't foresee
- * multiple tunneled ports as outport for any given NBL.
- */
-POVS_VPORT_ENTRY tunnelTxNic;
-
-/*
- * Tunneling - Rx:
- * Points to the Internal port on the PIF Bridge, if the packet needs to be
- * de-tunneled.
- */
-POVS_VPORT_ENTRY tunnelRxNic;
-
-/* header information */
-OVS_PACKET_HDR_INFO layers;
-} OvsForwardingContext;
-
-/*
  * --
  * OvsInitForwardingCtx --
  * Function to init/re-init the 'ovsFwdCtx' context as the actions pipeline
@@ -2032,8 +1975,8 @@ OvsDoExecuteActions(POVS_SWITCH_CONTEXT switchContext,
 }
 }
 
-status = OvsExecuteConntrackAction(ovsFwdCtx.curNbl, layers,
-   key, (const PNL_ATTR)a);
+status = OvsExecuteConntrackAction(, key,
+   (const PNL_ATTR)a);
 if (status != NDIS_STATUS_SUCCESS) {
 OVS_LOG_ERROR("CT Action failed");
 dropReason = L"OVS-conntrack action failed";
diff --git a/datapath-windows/ovsext/Actions.h 
b/datapath-windows/ovsext/Actions.h
index c56c260..1ce6c20 100644
--- a/datapath-windows/ovsext/Actions.h
+++ b/datapath-windows/ovsext/Actions.h
@@ -20,6 +20,64 @@
 #include "Switch.h"
 #include "PacketIO.h"
 
+
+/*
+ * There a lot of data that needs to be maintained while executing the pipeline
+ * as dictated by the actions of a flow, across different functions at 
different
+ * levels. Such data is put together in a 'context' structure. Care should be
+ * exercised while adding new members to the structure - only add ones that get
+ * used across multiple stages in the pipeline/get used in multiple functions.
+ */
+typedef struct OvsForwardingContext {
+POVS_SWITCH_CONTEXT switchContext;
+/* The NBL currently used in the pipeline. */
+PNET_BUFFER_LIST curNbl;
+/* NDIS forwarding detail for 'curNbl'. */
+PNDIS_SWITCH_FORWARDING_DETAIL_NET_BUFFER_LIST_INFO fwdDetail;
+/* Array of destination ports for 'curNbl'. */
+PNDIS_SWITCH_FORWARDING_DESTINATION_ARRAY destinationPorts;
+/* send flags while sending 'curNbl' into NDIS. */
+ULONG sendFlags;
+/* Total number of output ports, used + unused, in 'curNbl'. */
+UINT32 destPortsSizeIn;
+/* Total number of used output ports in 'curNbl'. */
+UINT32 destPortsSizeOut;
+/*
+ * If 'curNbl' is not owned by OVS, they need to be tracked, if they need 
to
+ * be freed/completed.
+ */
+OvsCompletionList *completionList;
+/*
+ * vport number of 'curNbl' when it is passed from the PIF bridge to the 
INT

[ovs-dev] Bug#857178: 857178 subscribe

[Pablo Di Noto]

Also found this issue.
Brand new Debian testing, minimal netinstall.

Eventually, systemd timed out the script and the configuration went on.

root@c3:~# systemctl status openvswitch-switch.service
● openvswitch-switch.service - LSB: Open vSwitch switch
   Loaded: loaded (/etc/init.d/openvswitch-switch; generated; vendor
preset: enabled)
   Active: active (running) since Mon 2017-04-10 14:19:38 -03; 4h 35min ago
 Docs: man:systemd-sysv-generator(8)
  Process: 834 ExecStart=/etc/init.d/openvswitch-switch start (code=exited,
status=0/SUCCESS)
Tasks: 7 (limit: 4915)
   CGroup: /system.slice/openvswitch-switch.service
   ├─651 ovsdb-server: monitoring pid 652 (healthy)
   ├─652 ovsdb-server /etc/openvswitch/conf.db -vconsole:emer
-vsyslog:err -vfile:info --remote=punix:/var/run/openvswitch/db.sock
--private-key
   ├─669 ovs-vswitchd: monitoring pid 670 (healthy)
   └─670 ovs-vswitchd unix:/var/run/openvswitch/db.sock
-vconsole:emer -vsyslog:err -vfile:info --mlockall --no-chdir
--log-file=/var/log/openvs

Apr 10 14:17:18 c3 openvswitch-switch[834]: ovsdb-server is already running.
Apr 10 14:17:18 c3 openvswitch-switch[834]: ovs-vswitchd is already running.
Apr 10 14:17:18 c3 openvswitch-switch[834]: Enabling remote OVSDB managers.
Apr 10 14:17:18 c3 openvswitch-switch[834]: ifup: waiting for lock on
/run/network/ifstate.ovsbr0
Apr 10 14:19:38 c3 openvswitch-switch[557]: Starting openvswitch-switch
(via systemctl): openvswitch-switch.serviceTerminated
Apr 10 14:19:38 c3 openvswitch-switch[557]:  failed!
Apr 10 14:19:38 c3 ovs-vsctl[1083]: ovs|1|vsctl|INFO|Called as
ovs-vsctl --timeout=5 -- --may-exist add-port ovsbr0 eth0 --
Apr 10 14:19:38 c3 openvswitch-switch[557]:
/etc/network/if-pre-up.d/openvswitch:
53: /etc/network/if-pre-up.d/openvswitch: ifconfig: not found
Apr 10 14:19:38 c3 openvswitch-switch[834]: ifup: interface ovsbr0 already
configured
Apr 10 14:19:38 c3 systemd[1]: Started LSB: Open vSwitch switch.

Using

openvswitch-common 2.6.2~pre+git20161223-3
openvswitch-switch 2.6.2~pre+git20161223-3

2017-04-10 18:57 GMT-03:00 Pablo Di Noto :

>
> Also found this issue.
> Brand new Debian testing, minimal netinstall.
>
> Eventually, systemd timed out the script and the configuration went on.
>
> root@c3:~# systemctl status openvswitch-switch.service
> ● openvswitch-switch.service - LSB: Open vSwitch switch
>Loaded: loaded (/etc/init.d/openvswitch-switch; generated; vendor
> preset: enabled)
>Active: active (running) since Mon 2017-04-10 14:19:38 -03; 4h 35min ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 834 ExecStart=/etc/init.d/openvswitch-switch start
> (code=exited, status=0/SUCCESS)
> Tasks: 7 (limit: 4915)
>CGroup: /system.slice/openvswitch-switch.service
>├─651 ovsdb-server: monitoring pid 652 (healthy)
>├─652 ovsdb-server /etc/openvswitch/conf.db -vconsole:emer
> -vsyslog:err -vfile:info --remote=punix:/var/run/openvswitch/db.sock
> --private-key
>├─669 ovs-vswitchd: monitoring pid 670 (healthy)
>└─670 ovs-vswitchd unix:/var/run/openvswitch/db.sock
> -vconsole:emer -vsyslog:err -vfile:info --mlockall --no-chdir
> --log-file=/var/log/openvs
>
> Apr 10 14:17:18 c3 openvswitch-switch[834]: ovsdb-server is already
> running.
> Apr 10 14:17:18 c3 openvswitch-switch[834]: ovs-vswitchd is already
> running.
> Apr 10 14:17:18 c3 openvswitch-switch[834]: Enabling remote OVSDB managers.
> Apr 10 14:17:18 c3 openvswitch-switch[834]: ifup: waiting for lock on
> /run/network/ifstate.ovsbr0
> Apr 10 14:19:38 c3 openvswitch-switch[557]: Starting openvswitch-switch
> (via systemctl): openvswitch-switch.serviceTerminated
> Apr 10 14:19:38 c3 openvswitch-switch[557]:  failed!
> Apr 10 14:19:38 c3 ovs-vsctl[1083]: ovs|1|vsctl|INFO|Called as
> ovs-vsctl --timeout=5 -- --may-exist add-port ovsbr0 eth0 --
> Apr 10 14:19:38 c3 openvswitch-switch[557]: 
> /etc/network/if-pre-up.d/openvswitch:
> 53: /etc/network/if-pre-up.d/openvswitch: ifconfig: not found
> Apr 10 14:19:38 c3 openvswitch-switch[834]: ifup: interface ovsbr0 already
> configured
> Apr 10 14:19:38 c3 systemd[1]: Started LSB: Open vSwitch switch.
>
> Using
>
> openvswitch-common 2.6.2~pre+git20161223-3
> openvswitch-switch 2.6.2~pre+git20161223-3
>
>
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 3/3 v2] datapath-windows: NAT integration with conntrack

[Yin Lin]

Hi Alin,

Was the checksum error observed in my v2 patch? In v1 patch, I did not
consider the TCP offloading case, which result in TCP checksum error when
checksum computing is offloaded. It's already fixed in v2. If you are still
seeing errors, let me know your setup so I can take a look. Thanks!

Best regards,
Yin Lin

On Thu, Apr 6, 2017 at 7:39 PM, Alin Serdean <
aserd...@cloudbasesolutions.com> wrote:

> Hi Yin,
>
> I'm back sorry it took a while .
>
> When applying `OvsUpdateAddressAndPort` for some reason there still is a
> problem with the checksums.
>
> There are two aspects which apparently are hit for some reason:
> 1. normal packet.
> 2. tcp segment.
>
> If I disable tcp/udp checksums(on the NIC) normal packets have the right
> checksums. However, the tcp segments checksums are still wrong.
>
> If I apply a full blown checksum using ` OvsApplySWChecksumOnNB` and `
> OvsTcpSegmentNBL`(just for checksum computations) things are fine with
> tcp/udp checksum enabled/disabled and lso enabled/disabled.
>
> From what I can think of the pseudochecksums are wrong when being sent
> down to a NIC.
>
> I'll try to dig further into this issue since what you apply here is the
> same thing we apply on the set ip/tcp port actions and that works fine.
>
> Thanks,
> Alin.
>
> > -Original Message-
> > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > boun...@openvswitch.org] On Behalf Of Yin Lin
> > Sent: Thursday, March 23, 2017 12:12 AM
> > To: d...@openvswitch.org
> > Subject: [ovs-dev] [PATCH 3/3 v2] datapath-windows: NAT integration with
> > conntrack
> >
> > Signed-off-by: Yin Lin 
> ___
> 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 v2] python: Allow tuning the session probe_interval from IDL

[Lance Richardson]

- Original Message -
> From: "Lance Richardson" 
> To: "Terry Wilson" 
> Cc: "ovs dev" , "Lucas Alvares Gomes" 
> 
> Sent: Monday, 10 April, 2017 2:01:39 PM
> Subject: Re: [ovs-dev] [PATCH v2] python: Allow tuning the session 
> probe_interval from IDL
> 
> > From: "Terry Wilson" 
> > To: "Lucas Alvares Gomes" 
> > Cc: "ovs dev" 
> > Sent: Monday, 10 April, 2017 1:01:31 PM
> > Subject: Re: [ovs-dev] [PATCH v2] python: Allow tuning the session
> > probe_interval from IDL
> > 
> > ovsdb-server has the ability to create additional servers based on a
> > DB contents. For the Open_vSwitch schema, that's the Manager table and
> > the Open_vSwitch table's manager_options column.
> > 
> > The ovsdb-server code refers to these as "remotes". If these remotes
> > have a max_backoff/inactivity_probe column, those values will be set.
> > inactivity_probe is the column that will determine the probe_interval
> > for the RPC server that is launched.
> > 
> > According to documentation (and the implementation in the "olden
> > days"), these remotes are set from the DB by passing
> > 
> >   --remote=db:DATABASE_NAME,TABLE_NAME,COLUMN
> > 
> > to ovsdb-server. For the Open_vSwitch case, that's
> > 
> >   --remote=db:Open_vSwitch,Open_vSwitch,manager_options.
> > 
> > In real life, this actually takes place by ovs-ctl calling
> > 
> > # ovs-appctl -t ovsdb-server ovsdb-server/add-remote \
> >   db:Open_vSwitch,Open_vSwitch,manager_options
> > 
> > after ovs-vswitchd has started.
> > 
> > OVN, on the other hand, does not appear to have a Manager-like table
> > to set up remotes and configure them with inactivity_probes, etc. The
> > ovn-ctl script just hard codes the ptcp:$DB_NB_PORT:$DB_NB_ADDR remote
> > when launching ovsdb-server for north/southbound db access.
> > 
> 
> Hi Terry,
> 
> Actually in OVS 2.7 we have "Connection" and "SSL" tables in ovn-sb and
> ovn-nb.
> 
> See commits:
> 
>     1047182 ovn-sb: remote connection management in sb db

and, more relevant:

  7fff4eb ovn-southbound: Implement read-only connection support.

>     821302c ovn-nb: remote connection management in nb db
> 
> Regards,
> 
>    Lance
> 
> > If we want to be consistent with how OVS does things, we would need to
> > create something like the Manager table and make it possible for
> > ovn-ctl to call ovs-appctl to add the remotes and configure them.
> > 
> > Related, I see ovn-controller has code to set the probe interval via
> > the local Open_vSwitch db's
> > Open_vSwitch.external_ids:ovn-remote-probe-interval. The patch that
> > added that also added ovsdb-idl.h's ovsdb_idl_set_probe_interval()
> > which is a similar solution the the one above for the Python code.
> > 
> > I don't have enough "big picture" OVN knowledge yet to know whether
> > this (and the ovn-remote-probe-interval) patch is the way to go or
> > whether independently configuring the connections via the db like
> > Open_vSwitch db is the way. But since I'd had some run-ins with
> > probe_interval via Neutron code, I thought I'd at least put what I
> > knew out there.
> > 
> > Terry
> > ___
> > 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
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] python: Allow tuning the session probe_interval from IDL

[Lance Richardson]

> From: "Terry Wilson" 
> To: "Lucas Alvares Gomes" 
> Cc: "ovs dev" 
> Sent: Monday, 10 April, 2017 1:01:31 PM
> Subject: Re: [ovs-dev] [PATCH v2] python: Allow tuning the session 
> probe_interval from IDL
> 
> ovsdb-server has the ability to create additional servers based on a
> DB contents. For the Open_vSwitch schema, that's the Manager table and
> the Open_vSwitch table's manager_options column.
> 
> The ovsdb-server code refers to these as "remotes". If these remotes
> have a max_backoff/inactivity_probe column, those values will be set.
> inactivity_probe is the column that will determine the probe_interval
> for the RPC server that is launched.
> 
> According to documentation (and the implementation in the "olden
> days"), these remotes are set from the DB by passing
> 
>   --remote=db:DATABASE_NAME,TABLE_NAME,COLUMN
> 
> to ovsdb-server. For the Open_vSwitch case, that's
> 
>   --remote=db:Open_vSwitch,Open_vSwitch,manager_options.
> 
> In real life, this actually takes place by ovs-ctl calling
> 
> # ovs-appctl -t ovsdb-server ovsdb-server/add-remote \
>   db:Open_vSwitch,Open_vSwitch,manager_options
> 
> after ovs-vswitchd has started.
> 
> OVN, on the other hand, does not appear to have a Manager-like table
> to set up remotes and configure them with inactivity_probes, etc. The
> ovn-ctl script just hard codes the ptcp:$DB_NB_PORT:$DB_NB_ADDR remote
> when launching ovsdb-server for north/southbound db access.
> 

Hi Terry,

Actually in OVS 2.7 we have "Connection" and "SSL" tables in ovn-sb and
ovn-nb.

See commits:

    1047182 ovn-sb: remote connection management in sb db
    821302c ovn-nb: remote connection management in nb db

Regards,

   Lance

> If we want to be consistent with how OVS does things, we would need to
> create something like the Manager table and make it possible for
> ovn-ctl to call ovs-appctl to add the remotes and configure them.
> 
> Related, I see ovn-controller has code to set the probe interval via
> the local Open_vSwitch db's
> Open_vSwitch.external_ids:ovn-remote-probe-interval. The patch that
> added that also added ovsdb-idl.h's ovsdb_idl_set_probe_interval()
> which is a similar solution the the one above for the Python code.
> 
> I don't have enough "big picture" OVN knowledge yet to know whether
> this (and the ovn-remote-probe-interval) patch is the way to go or
> whether independently configuring the connections via the db like
> Open_vSwitch db is the way. But since I'd had some run-ins with
> probe_interval via Neutron code, I thought I'd at least put what I
> knew out there.
> 
> Terry
> ___
> 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] Minutes: OvS Offload Discussion at Netdev 2.1

[Simon Horman]

On Mon, Apr 10, 2017 at 09:59:57AM -0700, Joe Stringer wrote:
> Thanks Simon. I also raised with a few people after the discussion about
> how we should document this functionality​. Specifically, whether there
> should be an 'experimental' or 'beta' tag associated. I believe that this
> seemed reasonable to the people I discussed this with.

Thanks Joe,

FWIW that sounds reasonable to me.

> On 8/04/2017 16:48, "Simon Horman"  wrote:
> 
> At Netdev 2.1 a meeting was held to discuss OvS offload.  Minutes of the
> discussion follow. I apologise in advance for any errors or omissions;
> doubly for any errors in the attendee list.
> 
> Topic: OVS Hardware Offload Using TC
> Date: 7th April 2017
> Location: Netdev 2.1, Montreal
> Attendees: Aaron Conole, Ben LaHaise, Eran Ben Elisha, Hannes Frederic Sowa,
>   Jakub Kicinski, Jiri Pirko, Joe Stringer, John Fastabend, Nick Viljoen,
>   Rashid Khan, Rony Efraim, Simon Horman
> 
> Joe raised 2 concerns:
> 
> 1) How to enable users to understand whether offload is
>successful and if not, why not?
> 
>   a) There is functionality in the v7[1] patchset to report which flows
>  are present in hardware.
> 
>   b) New error reporting infrastructure from the kernel is forthcoming It
>  should allow TC to provide more error information if a flow can't be
>  added to hardware. This could be made available to users - e.g. logged
>  - to allow them better understand the reason for the failure.
> 
> 2) Maintenance burden falling on existing maintainers
> 
>   a) Simon offered to take some of the maintenance burden
>  immediately as he is already a committer.
> 
>   b) The aim is to ensure that in future there are other committers
>  who are interested in this feature.
> 
>   There was consensus that if the feature-set does not grow there should be
>   discussion of deprecating the HW offload support provided by [1].
> 
> Joe raised issue of whether OVS should probe hardware capabilities at
> runtime.
> John suggested this may be complex; potential combinatorial set is too
> large.
> 
> Rony then raised the increased complexity of using multiple NICs of
> different types with different offload capabilities, this was tabled to a
> later date.
> 
> Joe has expressed a desire for more testing. There was a general agreement
> to contribute tests.
> 
> [1] [PATCH ovs V7 00/24] Introducing HW offload support for openvswitch
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2] python: Allow tuning the session probe_interval from IDL

[Terry Wilson]

ovsdb-server has the ability to create additional servers based on a
DB contents. For the Open_vSwitch schema, that's the Manager table and
the Open_vSwitch table's manager_options column.

The ovsdb-server code refers to these as "remotes". If these remotes
have a max_backoff/inactivity_probe column, those values will be set.
inactivity_probe is the column that will determine the probe_interval
for the RPC server that is launched.

According to documentation (and the implementation in the "olden
days"), these remotes are set from the DB by passing

  --remote=db:DATABASE_NAME,TABLE_NAME,COLUMN

to ovsdb-server. For the Open_vSwitch case, that's

  --remote=db:Open_vSwitch,Open_vSwitch,manager_options.

In real life, this actually takes place by ovs-ctl calling

# ovs-appctl -t ovsdb-server ovsdb-server/add-remote \
  db:Open_vSwitch,Open_vSwitch,manager_options

after ovs-vswitchd has started.

OVN, on the other hand, does not appear to have a Manager-like table
to set up remotes and configure them with inactivity_probes, etc. The
ovn-ctl script just hard codes the ptcp:$DB_NB_PORT:$DB_NB_ADDR remote
when launching ovsdb-server for north/southbound db access.

If we want to be consistent with how OVS does things, we would need to
create something like the Manager table and make it possible for
ovn-ctl to call ovs-appctl to add the remotes and configure them.

Related, I see ovn-controller has code to set the probe interval via
the local Open_vSwitch db's
Open_vSwitch.external_ids:ovn-remote-probe-interval. The patch that
added that also added ovsdb-idl.h's ovsdb_idl_set_probe_interval()
which is a similar solution the the one above for the Python code.

I don't have enough "big picture" OVN knowledge yet to know whether
this (and the ovn-remote-probe-interval) patch is the way to go or
whether independently configuring the connections via the db like
Open_vSwitch db is the way. But since I'd had some run-ins with
probe_interval via Neutron code, I thought I'd at least put what I
knew out there.

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

Re: [ovs-dev] Minutes: OvS Offload Discussion at Netdev 2.1

[Joe Stringer]

Thanks Simon. I also raised with a few people after the discussion about
how we should document this functionality​. Specifically, whether there
should be an 'experimental' or 'beta' tag associated. I believe that this
seemed reasonable to the people I discussed this with.

On 8/04/2017 16:48, "Simon Horman"  wrote:

At Netdev 2.1 a meeting was held to discuss OvS offload.  Minutes of the
discussion follow. I apologise in advance for any errors or omissions;
doubly for any errors in the attendee list.

Topic: OVS Hardware Offload Using TC
Date: 7th April 2017
Location: Netdev 2.1, Montreal
Attendees: Aaron Conole, Ben LaHaise, Eran Ben Elisha, Hannes Frederic Sowa,
  Jakub Kicinski, Jiri Pirko, Joe Stringer, John Fastabend, Nick Viljoen,
  Rashid Khan, Rony Efraim, Simon Horman

Joe raised 2 concerns:

1) How to enable users to understand whether offload is
   successful and if not, why not?

  a) There is functionality in the v7[1] patchset to report which flows
 are present in hardware.

  b) New error reporting infrastructure from the kernel is forthcoming It
 should allow TC to provide more error information if a flow can't be
 added to hardware. This could be made available to users - e.g. logged
 - to allow them better understand the reason for the failure.

2) Maintenance burden falling on existing maintainers

  a) Simon offered to take some of the maintenance burden
 immediately as he is already a committer.

  b) The aim is to ensure that in future there are other committers
 who are interested in this feature.

  There was consensus that if the feature-set does not grow there should be
  discussion of deprecating the HW offload support provided by [1].

Joe raised issue of whether OVS should probe hardware capabilities at
runtime.
John suggested this may be complex; potential combinatorial set is too
large.

Rony then raised the increased complexity of using multiple NICs of
different types with different offload capabilities, this was tabled to a
later date.

Joe has expressed a desire for more testing. There was a general agreement
to contribute tests.

[1] [PATCH ovs V7 00/24] Introducing HW offload support for openvswitch
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 2/2] netdev-dpdk: Show Rx checksum status when false.

[Chandran, Sugesh]

Regards
_Sugesh


> -Original Message-
> From: Kevin Traynor [mailto:ktray...@redhat.com]
> Sent: Tuesday, April 4, 2017 6:35 AM
> To: d...@openvswitch.org
> Cc: Kevin Traynor ; Chandran, Sugesh
> 
> Subject: [PATCH 2/2] netdev-dpdk: Show Rx checksum status when false.
> 
> Currently ovs-appctl dpctl/show only shows the Rx checksum offload status
> when true. Change to also show the status when false.
> 
> Cc: Sugesh Chandran 
> Signed-off-by: Kevin Traynor 
> ---
>  lib/netdev-dpdk.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index d5a9800..b1fecfa
> 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -1092,4 +1092,6 @@ netdev_dpdk_get_config(const struct netdev
> *netdev, struct smap *args)
>  if (dev->hw_ol_features & NETDEV_RX_CHECKSUM_OFFLOAD) {
>  smap_add(args, "rx_csum_offload", "true");
> +} else {
> +smap_add(args, "rx_csum_offload", "false");
[Sugesh] Thank you for adding it, I verified in my test setup.

>  }
>  }
> --
> 1.8.3.1

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

Re: [ovs-dev] [PATCH 1/2] netdev-dpdk: Fix Rx checksum reconfigure.

[Chandran, Sugesh]

Thank you for the patch,
Please see the comment below.

Regards
_Sugesh

> -Original Message-
> From: Kevin Traynor [mailto:ktray...@redhat.com]
> Sent: Tuesday, April 4, 2017 6:35 AM
> To: d...@openvswitch.org
> Cc: Kevin Traynor ; Chandran, Sugesh
> 
> Subject: [PATCH 1/2] netdev-dpdk: Fix Rx checksum reconfigure.
> 
> Rx checksum offload is enabled by default where available, with
> reconfiguration through OVSDB options:rx-checksum-offload.
> However, setting rx-checksum-offload does not result in a reconfiguration of
> the NIC.
> 
> Fix that by checking if the requested port config features (e.g. rx checksum
> offload) are currently applied on the NIC and if not, perform a
> reconfiguration.
> 
> Fixes: 1a2bb11817a4 ("netdev-dpdk: Enable Rx checksum offloading feature
> on DPDK physical ports.")
> Cc: Sugesh Chandran 
> Signed-off-by: Kevin Traynor 
> ---
>  lib/netdev-dpdk.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c index ddc651b..d5a9800
> 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -374,4 +374,5 @@ struct netdev_dpdk {
>  int requested_rxq_size;
>  int requested_txq_size;
> +uint32_t requested_hwol;
> 
>  /* Number of rx/tx descriptors for physical devices */ @@ -647,5 +648,5
> @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, int n_rxq, int
> n_txq)
>  conf.rxmode.max_rx_pkt_len = 0;
>  }
> -conf.rxmode.hw_ip_checksum = (dev->hw_ol_features &
> +conf.rxmode.hw_ip_checksum = (dev->requested_hwol &
>NETDEV_RX_CHECKSUM_OFFLOAD) != 0;
>  /* A device may report more queues than it makes available (this has @@
> -701,4 +702,5 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev,
> int n_rxq, int n_txq)
>  dev->up.n_rxq = n_rxq;
>  dev->up.n_txq = n_txq;
> +dev->hw_ol_features = dev->requested_hwol;
> 
>  return 0;
> @@ -718,5 +720,5 @@ dpdk_eth_checksum_offload_configure(struct
> netdev_dpdk *dev)
>   DEV_RX_OFFLOAD_IPV4_CKSUM;
>  rte_eth_dev_info_get(dev->port_id, );
> -rx_csum_ol_flag = (dev->hw_ol_features &
> NETDEV_RX_CHECKSUM_OFFLOAD) != 0;
> +rx_csum_ol_flag = (dev->requested_hwol &
> + NETDEV_RX_CHECKSUM_OFFLOAD) != 0;
> 
>  if (rx_csum_ol_flag &&
> @@ -725,5 +727,5 @@ dpdk_eth_checksum_offload_configure(struct
> netdev_dpdk *dev)
>  VLOG_WARN_ONCE("Rx checksum offload is not supported on device
> %d",
> dev->port_id);
> -dev->hw_ol_features &= ~NETDEV_RX_CHECKSUM_OFFLOAD;
> +dev->requested_hwol &= ~NETDEV_RX_CHECKSUM_OFFLOAD;
>  return;
>  }
> @@ -871,4 +873,5 @@ common_construct(struct netdev *netdev, unsigned
> int port_no,
>  /* Initilize the hardware offload flags to 0 */
>  dev->hw_ol_features = 0;
> +dev->requested_hwol = 0;
> 
>  dev->flags = NETDEV_UP | NETDEV_PROMISC; @@ -1259,5 +1262,5 @@
> netdev_dpdk_set_config(struct netdev *netdev, const struct smap *args,
>  != 0;
>  if (temp_flag != rx_chksm_ofld) {
> -dev->hw_ol_features ^= NETDEV_RX_CHECKSUM_OFFLOAD;
> +dev->requested_hwol ^= NETDEV_RX_CHECKSUM_OFFLOAD;
>  dpdk_eth_checksum_offload_configure(dev);
>  }
> @@ -3124,5 +3127,6 @@ netdev_dpdk_reconfigure(struct netdev *netdev)
>  && 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->hw_ol_features == dev->requested_hwol) {
>  /* Reconfiguration is unnecessary */
[Sugesh] The patch fixes the issue however I believe these checks has to be 
moved to the corresponding functions than here. May be that looks cleaner.  Any 
configuration change that happen to a netdev validated at the corresponding 
functions than in a common reconfigure. That can avoid the need of 2 struct 
element for every param.
I verified the patch and now it reloads the NIC configuration when there is a 
change.



> 
> --
> 1.8.3.1

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

[ovs-dev] [PATCH v2] doc: Link to release FAQ from DPDK install guide

[Stephen Finucane]

I wanted to find the mappings of DPDK versions to OVS versions. This was
a little more difficult than expected. Resolve the issue by linking to
it from the DPDK install guide.

Signed-off-by: Stephen Finucane 
---
v2:
- Add a link to the releases FAQ from the installation section of the
  index page
---
 Documentation/index.rst  | 3 ++-
 Documentation/intro/install/dpdk.rst | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index d81e9ba..5210a56 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -58,7 +58,8 @@ vSwitch? Start here.
   :doc:`intro/install/netbsd` |
   :doc:`intro/install/windows` |
   :doc:`intro/install/xenserver` |
-  :doc:`intro/install/dpdk`
+  :doc:`intro/install/dpdk` |
+  :doc:`Installation FAQs `
 
 - **Tutorials:** :doc:`tutorials/ovs-advanced` |
   :doc:`tutorials/ovn-sandbox`
diff --git a/Documentation/intro/install/dpdk.rst 
b/Documentation/intro/install/dpdk.rst
index b947bd5..f29ac05 100644
--- a/Documentation/intro/install/dpdk.rst
+++ b/Documentation/intro/install/dpdk.rst
@@ -29,6 +29,11 @@ This document describes how to build and install Open 
vSwitch using a DPDK
 datapath. Open vSwitch can use the DPDK library to operate entirely in
 userspace.
 
+.. seealso::
+
+The :doc:`releases FAQ ` lists support for the required
+versions of DPDK for each version of Open vSwitch.
+
 Build requirements
 --
 
-- 
2.9.3

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

Re: [ovs-dev] [PATCH] doc: Link to release FAQ from DPDK install guide

[Stephen Finucane]

On Fri, 2017-04-07 at 15:28 +, Darrell Ball wrote:
> 
> On 4/7/17, 6:58 AM, "ovs-dev-boun...@openvswitch.org on behalf of
> Stephen Finucane"  e...@that.guru> wrote:
> 
> I wanted to find the mappings of DPDK versions to OVS versions.
> This was
> a little more difficult than expected. Resolve the issue by
> linking to
> it from the DPDK install guide.
> 
> Signed-off-by: Stephen Finucane 
> ---
>  Documentation/intro/install/dpdk.rst | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/intro/install/dpdk.rst
> b/Documentation/intro/install/dpdk.rst
> index b947bd5..f29ac05 100644
> --- a/Documentation/intro/install/dpdk.rst
> +++ b/Documentation/intro/install/dpdk.rst
> @@ -29,6 +29,11 @@ This document describes how to build and
> install Open vSwitch using a DPDK
>  datapath. Open vSwitch can use the DPDK library to operate
> entirely in
>  userspace.
>  
> +.. seealso::
> +
> +The :doc:`releases FAQ ` lists support for
> the required
> +versions of DPDK for each version of Open vSwitch.
> +
> 
> If it is not intuitive to follow the path 
> Open vswitch Documentation -> FAQ -> Releases, 
> then perhaps it means
> “Releases” should also be linked at the same level as Installation
> Guides, Tutorials etc
> Releases is really one of first high topics people are interested in.

That would apply if you're navigating the docs from '/' and I see merit
in doing that. I'll reroll a v2 shortly. However, this wouldn't help
users navigating to the page from Google (like I was) and I think we
should keep this change itself.

> 
>  Build requirements
>  --
>  
> -- 
> 2.9.3
> 

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

Re: [ovs-dev] [PATCH 2/2] selinux: enable dpdk permissions

[Aaron Conole]

Hi Ansis,

Ansis Atteka  writes:

> On 29 March 2017 at 12:25, Aaron Conole  wrote:
>
> Thanks for doing this. I should have probably built OVS with your patch, but 
> since my RHEL setup is down
> at the moment, then I will do that later. Anyway see my comments inline.

Thank you so much for the review.

>  Set the selinux permissions for DPDK.  After this patch, the openvswitch
>  context label has access to the following resources:
>* hugepage filesystems
>* vfio devices
>* additional unix socket permissions
>* additional filesystem permissions 
>
>  Additionally, the openvswitch policy is now stored as template file to be
>  built up based on options passed to configure.
>
> Instead of ./configuring fixed policy at build time there is also SELinux 
> booleans feature. See
> https://wiki.gentoo.org/wiki/SELinux/Tutorials/Using_SELinux_booleans for 
> more details. I know
> that other open source projects use that feature to loosen-up their SELinux 
> policies to enable certain
> functional features at run-time that otherwise are disabled by default.

Cool, I didn't know much about it.  I'll look at it.

> While I haven't looked in that SELinux area deeply enough, is there a reason, 
> you don't want to use
> SElinux booleans to allow access to DPDK related resources at run-time? The 
> only obvious argument to
> me is that it would requires administrator to explicitly invoke the setsebool 
> call.

So, I guess first thing was I didn't know about selinux boolean.  I'll
look at it, and follow up.  I guess having to do manual intervention is
a bit inconvenient in my opinion.  And my thinking is that most
distributions who want SELinux + DPDK would just implement a policy like
I do to make it easier for the user.

But I will take a look at it.

>  Signed-off-by: Aaron Conole 
>
>  ---
>   selinux/automake.mk  |  1 +
>   selinux/openvswitch-custom.te| 16 
>   selinux/openvswitch-custom.te.in | 40
>  
>   3 files changed, 41 insertions(+), 16 deletions(-)
>   delete mode 100644 selinux/openvswitch-custom.te
>   create mode 100644 selinux/openvswitch-custom.te.in
>
>  diff --git a/selinux/automake.mk b/selinux/automake.mk
>  index 1088f36..6fc30b3 100644
>  --- a/selinux/automake.mk
>  +++ b/selinux/automake.mk
>  @@ -6,4 +6,5 @@
>   # without warranty of any kind.
>
>   EXTRA_DIST += \
>  +selinux/openvswitch-custom.te.in \
>
>   selinux/openvswitch-custom.te
>  diff --git a/selinux/openvswitch-custom.te b/selinux/openvswitch-custom.te
>  deleted file mode 100644
>  index 47ddb56..000
>  --- a/selinux/openvswitch-custom.te
>  +++ /dev/null
>  @@ -1,16 +0,0 @@
>  -module openvswitch-custom 1.0.1;
>  -
>  -require {
>  -type openvswitch_t;
>  -type openvswitch_tmp_t;
>  -type ifconfig_exec_t;
>  -type hostname_exec_t;
>  -class netlink_socket { setopt getopt create connect getattr write 
> read };
>  -class file { write getattr read open execute execute_no_trans };
>  -}
>  -
>  -#= openvswitch_t ==
>  -allow openvswitch_t self:netlink_socket { setopt getopt create connect 
> getattr write read };
>  -allow openvswitch_t hostname_exec_t:file { read getattr open execute 
> execute_no_trans };
>  -allow openvswitch_t ifconfig_exec_t:file { read getattr open execute 
> execute_no_trans };
>  -allow openvswitch_t openvswitch_tmp_t:file { execute execute_no_trans };
>  diff --git a/selinux/openvswitch-custom.te.in 
> b/selinux/openvswitch-custom.te.in
>  new file mode 100644
>  index 000..3a0afc6
>  --- /dev/null
>  +++ b/selinux/openvswitch-custom.te.in
>  @@ -0,0 +1,40 @@
>  +module openvswitch-custom 1.0.1;
>  +
>  +require {
>  +type openvswitch_t;
>  +type openvswitch_tmp_t;
>  +type ifconfig_exec_t;
>  +type hostname_exec_t;
>  +class netlink_socket { setopt getopt create connect getattr write 
> read };
>  +class file { write getattr read open execute execute_no_trans };
>  +}
>  +
>  +define(`dpdk_perms', `
>  +   gen_require(`
>  +   type vfio_device_t;
>  +   type kernel_t;
>  +   type hugetlbfs_t;
>  +   class file { write getattr read open execute execute_no_trans
>  +   create unlink };
>  +   class chr_file { write getattr read open ioctl };
>  +   class unix_stream_socket { write getattr read connectto 
> connect
>  +setopt getopt sendto accept bind recvfrom 
> acceptfrom };
>  +   class dir { write remove_name add_name lock read };
>  +   ')
>  +
>  +   allow $1_t vfio_device_t:chr_file { read write open ioctl getattr };
>  +   allow $1_t hugetlbfs_t:dir { write remove_name add_name lock read };
>  +   allow $1_t hugetlbfs_t:file { create unlink };
>  +   allow 

[ovs-dev] 邮件系统备案提醒

[postmaster]

这是一封 HTML 格式的邮件，请以网页方式查看邮件。
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [RFC 1/4] doc: Add man page section to documentation guide

[Stephen Finucane]

We also replace 'reST' with the far more common 'rST'.

Signed-off-by: Stephen Finucane 
---
 .../internals/contributing/documentation-style.rst | 84 +++---
 1 file changed, 76 insertions(+), 8 deletions(-)

diff --git a/Documentation/internals/contributing/documentation-style.rst 
b/Documentation/internals/contributing/documentation-style.rst
index 9fe473c..0ba5e54 100644
--- a/Documentation/internals/contributing/documentation-style.rst
+++ b/Documentation/internals/contributing/documentation-style.rst
@@ -41,17 +41,17 @@ documents found in the project tree.
 reStructuredText vs. Sphinx
 ---
 
-`reStructuredText (reST)`__ is the syntax, while `Sphinx`__ is a documentation
-generator.  Sphinx introduces a number of extensions to reST, like the
-``:ref:`` role, which can and should be used in documentation, but these will
-not work correctly on GitHub. As such, these extensions should not be used in
-any documentation in the root level, such as the ``README``.
+`reStructuredText (rST)`__ is the syntax, while `Sphinx`__ is a documentation
+generator.  Sphinx introduces a number of extensions to rST, like the ``:ref:``
+role, which can and should be used in documentation, but these will not work
+correctly on GitHub. As such, these extensions should not be used in any
+documentation in the root level, such as the ``README``.
 
 __ http://docutils.sourceforge.net/rst.html
 __ http://www.sphinx-doc.org/
 
-reST Conventions
-
+rST Conventions
+---
 
 Basics
 ~~
@@ -59,7 +59,7 @@ Basics
 Many of the basic documentation guidelines match those of the
 :doc:`coding-style`.
 
-- Use reStructuredText (reST) for all documentation.
+- Use reStructuredText (rST) for all documentation.
 
   Sphinx extensions can be used, but only for documentation in the
   ``Documentation`` folder.
@@ -90,6 +90,12 @@ File Names
 
 - Use hyphens as space delimiters. For example: ``my-readme-document.rst``
 
+  .. note::
+
+ An exception to this rule is any man pages, which take an trailing number
+ corresponding to the number of arguments required. This number is preceded
+ by an underscore.
+
 - Use lowercase filenames.
 
   .. note::
@@ -285,6 +291,68 @@ Comments
   .. TODO(stephenfin) This section needs some work. This TODO will not
  appear in the final generated document, however.
 
+Man Pages
+-
+
+In addition to the above, man pages have some specific requirements:
+
+- You **must** define the following sections:
+
+  - Synopsis
+
+  - Description
+
+  - Options
+
+  Note that `NAME` is not included - this is automatically generated by Sphinx
+  and should not be manually defined. Also note that these do not need to be
+  uppercase - Sphinx will do this automatically.
+
+  Additional sections are allowed. Refer to `man-pages(8)` for information on
+  the sections generally allowed.
+
+- You **must not** define a `NAME` section.
+
+  See above.
+
+- The `OPTIONS` section must describe arguments and options using the
+  `program`__ and `option`__ directives.
+
+  This ensures the output is formatted correctly and that you can
+  cross-reference various programs and commands from the documentation. For
+  example::
+
+  .. program:: ovs-do-something
+
+  .. option:: -f, --force
+
+  Force the operation
+
+  .. option:: -b , --bridge 
+
+  Name or ID of bridge
+
+  .. important::
+
+ Option argument names should be enclosed in angle brackets, as above.
+
+- Any references to the application or any other Open vSwitch application must
+  be marked up using the `program` role.
+
+  This allows for easy linking in the HTML output and correct formatting in the
+  man page output. For example::
+
+  To do something, run :program:`ovs-do-something`.
+
+- The man page must be included in the list of man page documents found in
+  `conf.py`__
+
+Refer to existing man pages for worked examples.
+
+__ http://www.sphinx-doc.org/en/stable/domains.html#directive-program
+__ http://www.sphinx-doc.org/en/stable/domains.html#directive-option
+__ http://www.sphinx-doc.org/en/stable/config.html#confval-man_pages
+
 Writing Style
 -
 
-- 
2.9.3

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

[ovs-dev] [RFC 3/4] doc: Convert ovs-test to rST

[Stephen Finucane]

Signed-off-by: Stephen Finucane 
---
See comment on the previous change
---
 Documentation/automake.mk   |   2 +
 Documentation/conf.py   |   3 +
 Documentation/ref/index.rst |   1 +
 Documentation/ref/ovs-test.rst  | 165 
 Documentation/ref/ovs-vlan-test.rst |  11 +--
 debian/openvswitch-test.manpages|   1 -
 manpages.mk |  10 ---
 utilities/automake.mk   |   3 -
 8 files changed, 175 insertions(+), 21 deletions(-)
 create mode 100644 Documentation/ref/ovs-test.rst

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 2d62a6a..7b6de65 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -90,6 +90,7 @@ DOC_SOURCE = \
Documentation/internals/contributing/libopenvswitch-abi.rst \
Documentation/internals/contributing/submitting-patches.rst \
Documentation/ref/index.rst \
+   Documentation/ref/ovs-test.rst \
Documentation/ref/ovs-vlan-test.rst \
Documentation/requirements.txt
 
@@ -118,6 +119,7 @@ ALL_LOCAL += docs-check
 CLEANFILES += docs-check
 
 man_MANS += \
+   $(SPHINXBUILDDIR)/man/ovs-test.1 \
$(SPHINXBUILDDIR)/man/ovs-vlan-test.1
 
 check-docs:
diff --git a/Documentation/conf.py b/Documentation/conf.py
index e40302c..28008ed 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -312,6 +312,9 @@ latex_documents = [
 # One entry per manual page. List of tuples
 # (source start file, name, description, authors, manual section).
 man_pages = [
+('ref/ovs-test', 'ovs-test',
+ u'Check Linux drivers for performance, vlan and L3 tunneling problems',
+ [author], 1),
 ('ref/ovs-vlan-test', 'ovs-vlan-test',
  u'Check Linux drivers for problems with vlan traffic',
  [author], 1)
diff --git a/Documentation/ref/index.rst b/Documentation/ref/index.rst
index 1e0d413..635f4df 100644
--- a/Documentation/ref/index.rst
+++ b/Documentation/ref/index.rst
@@ -39,6 +39,7 @@ time:
 .. toctree::
:maxdepth: 3
 
+   ovs-test
ovs-vlan-test
 
 The remainder are still in roff format can be found below:
diff --git a/Documentation/ref/ovs-test.rst b/Documentation/ref/ovs-test.rst
new file mode 100644
index 000..164068d
--- /dev/null
+++ b/Documentation/ref/ovs-test.rst
@@ -0,0 +1,165 @@
+
+ovs-test
+
+
+Synopsis
+
+
+::
+
+ovs-test -s port
+
+ovs-test -c server1 server2 [-b targetbandwidth] [-i testinterval] [-d]
+  [-l vlantag] [-t tunnelmodes]
+
+Description
+===
+
+The :program:`ovs-test` program may be used to check for problems sending
+802.1Q or GRE traffic that Open vSwitch may uncover. These problems, for
+example, can occur when Open vSwitch is used to send 802.1Q traffic through
+physical interfaces running certain drivers of certain Linux kernel versions.
+To run a test, configure IP addresses on `server1` and `server2` for interfaces
+you intended to test. These interfaces could also be already configured OVS
+bridges that have a physical interface attached to them. Then, on one of the
+nodes, run :program:`ovs-test` in server mode and on the other node run it in
+client mode. The client will connect to :program:`ovs-test` server and schedule
+tests between both of them. The :program:`ovs-test` client will perform UDP and
+TCP tests.
+
+UDP tests can report packet loss and achieved bandwidth for various datagram
+sizes. By default target bandwidth for UDP tests is 1Mbit/s.
+
+TCP tests report only achieved bandwidth, because kernel TCP stack takes care
+of flow control and packet loss. TCP tests are essential to detect potential
+TSO related issues.
+
+To determine whether Open vSwitch is encountering any problems, the user must
+compare packet loss and achieved bandwidth in a setup where traffic is being
+directly sent and in one where it is not. If in the 802.1Q or L3 tunneled tests
+both :program:`ovs-test` processes are unable to communicate or the achieved
+bandwidth is much lower compared to direct setup, then, most likely, Open
+vSwitch has encountered a pre-existing kernel or driver bug.
+
+Some examples of the types of problems that may be encountered are:
+
+- When NICs use VLAN stripping on receive they must pass a pointer to a
+  `vlan_group` when reporting the stripped tag to the networking core. If no
+  `vlan_group` is in use then some drivers just drop the extracted tag.
+  Drivers are supposed to only enable stripping if a `vlan_group` is registered
+  but not all of them do that.
+
+- On receive, some drivers handle priority tagged packets specially and don't
+  pass the tag onto the network stack at all, so Open vSwitch never has a
+  chance to see it.
+
+- Some drivers size their receive buffers based on whether a `vlan_group` is
+  enabled, meaning that a maximum size packet with a VLAN tag will not fit if
+  no `vlan_group` is configured.
+
+- On transmit, some drivers expect that VLAN 

[ovs-dev] [RFC 2/4] doc: Convert ovs-vlan-test to rST

[Stephen Finucane]

Let's start with a simple one that lets us focus on setting up most of
the required "infrastructure" for building man pages using Sphinx.

There are a couple of things worth noting here:

- The 'check-htmldocs' target becomes 'check-docs' as its now
  responsible for building man page docs too.

- The outputted file will always have a '.1' suffix. This is Sphinx's
  decision, and likely stems from the man page guidelines [1] which
  state that "the name of the man page's source file...is the name of
  the command, function or file name, followed by a dot, followed by the
  section character".

Other than that, hurrah for (mostly) legible syntaxes.

[1] http://www.tldp.org/HOWTO/Man-Page/q2.html

Signed-off-by: Stephen Finucane 
---
I don't know if this is correctly integrated into the docs build system
or not. I need someone to double check this for me. In particular, I
think I need to integrate the 'dh_sphinxdoc' package [2] into the Debian
build but I've no idea how to.

[2] http://manpages.ubuntu.com/manpages/zesty/man1/dh_sphinxdoc.1.html
---
 Documentation/automake.mk  |  17 +--
 Documentation/conf.py  |   3 +-
 .../internals/contributing/documentation-style.rst |   3 +-
 Documentation/intro/install/documentation.rst  |   4 +-
 Documentation/ref/index.rst|  16 ++-
 Documentation/ref/ovs-vlan-test.rst| 117 +
 debian/openvswitch-switch.manpages |   1 -
 manpages.mk|  10 --
 utilities/automake.mk  |   3 -
 9 files changed, 145 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/ref/ovs-vlan-test.rst

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 1fd452b..2d62a6a 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -59,7 +59,6 @@ DOC_SOURCE = \
Documentation/howto/vlan.png \
Documentation/howto/vlan.rst \
Documentation/howto/vtep.rst \
-   Documentation/ref/index.rst \
Documentation/faq/index.rst \
Documentation/faq/configuration.rst \
Documentation/faq/contributing.rst \
@@ -90,6 +89,8 @@ DOC_SOURCE = \
Documentation/internals/contributing/documentation-style.rst \
Documentation/internals/contributing/libopenvswitch-abi.rst \
Documentation/internals/contributing/submitting-patches.rst \
+   Documentation/ref/index.rst \
+   Documentation/ref/ovs-vlan-test.rst \
Documentation/requirements.txt
 
 EXTRA_DIST += $(DOC_SOURCE)
@@ -110,18 +111,20 @@ sphinx_verbose_ = $(sphinx_verbose_@AM_DEFAULT_V@)
 sphinx_verbose_0 = -q
 
 if HAVE_SPHINX
-htmldocs-check: $(DOC_SOURCE)
+docs-check: $(DOC_SOURCE)
$(AM_V_GEN)$(SPHINXBUILD) $(sphinx_verbose) -b html $(ALLSPHINXOPTS) 
$(SPHINXBUILDDIR)/html && touch $@
-ALL_LOCAL += htmldocs-check
-CLEANFILES += htmldocs-check
+   $(AM_V_GEN)$(SPHINXBUILD) $(sphinx_verbose) -b man $(ALLSPHINXOPTS) 
$(SPHINXBUILDDIR)/man && touch $@
+ALL_LOCAL += docs-check
+CLEANFILES += docs-check
+
+man_MANS += \
+   $(SPHINXBUILDDIR)/man/ovs-vlan-test.1
 
 check-docs:
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(SPHINXBUILDDIR)/linkcheck
 
 clean-docs:
-   rm -rf $(SPHINXBUILDDIR)/doctrees
-   rm -rf $(SPHINXBUILDDIR)/html
-   rm -rf $(SPHINXBUILDDIR)/linkcheck
+   rm -rf $(SPHINXBUILDDIR)
 CLEAN_LOCAL += clean-docs
 endif
 .PHONY: check-docs
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 6a924b3..e40302c 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -312,7 +312,8 @@ latex_documents = [
 # One entry per manual page. List of tuples
 # (source start file, name, description, authors, manual section).
 man_pages = [
-(master_doc, 'openvswitch', u'Open vSwitch Documentation',
+('ref/ovs-vlan-test', 'ovs-vlan-test',
+ u'Check Linux drivers for problems with vlan traffic',
  [author], 1)
 ]
 
diff --git a/Documentation/internals/contributing/documentation-style.rst 
b/Documentation/internals/contributing/documentation-style.rst
index 0ba5e54..fcf3b9e 100644
--- a/Documentation/internals/contributing/documentation-style.rst
+++ b/Documentation/internals/contributing/documentation-style.rst
@@ -347,7 +347,8 @@ In addition to the above, man pages have some specific 
requirements:
 - The man page must be included in the list of man page documents found in
   `conf.py`__
 
-Refer to existing man pages for worked examples.
+Refer to existing man pages, such as :doc:`/ref/ovs-vlan-test` for a worked
+example.
 
 __ http://www.sphinx-doc.org/en/stable/domains.html#directive-program
 __ http://www.sphinx-doc.org/en/stable/domains.html#directive-option
diff --git a/Documentation/intro/install/documentation.rst 
b/Documentation/intro/install/documentation.rst
index 94af950..0eeeab1 100644
--- a/Documentation/intro/install/documentation.rst
+++ 

[ovs-dev] [RFC 4/4] doc: Remove latex output configuration

[Stephen Finucane]

We don't care about building LaTeX documentation, so there's no need to
keep this build cruft around.

Signed-off-by: Stephen Finucane 
---
 Documentation/automake.mk | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Documentation/automake.mk b/Documentation/automake.mk
index 7b6de65..7a3c078 100644
--- a/Documentation/automake.mk
+++ b/Documentation/automake.mk
@@ -103,9 +103,7 @@ SPHINXSRCDIR = $(srcdir)/Documentation
 SPHINXBUILDDIR = $(builddir)/Documentation/_build
 
 # Internal variables.
-PAPEROPT_a4 = -D latex_paper_size=a4
-PAPEROPT_letter = -D latex_paper_size=letter
-ALLSPHINXOPTS = -W -n -d $(SPHINXBUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) 
$(SPHINXOPTS) $(SPHINXSRCDIR)
+ALLSPHINXOPTS = -W -n -d $(SPHINXBUILDDIR)/doctrees $(SPHINXOPTS) 
$(SPHINXSRCDIR)
 
 sphinx_verbose = $(sphinx_verbose_@AM_V@)
 sphinx_verbose_ = $(sphinx_verbose_@AM_DEFAULT_V@)
-- 
2.9.3

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

[ovs-dev] [RFC 0/4] Introduce Sphinx for man pages

[Stephen Finucane]

This series introduces the use of Sphinx for building man pages. There are a
couple of reasons for doing this:

- roff is ruff to write

  Sorry. roff is an old markup format that's mostly used for man pages today.
  While certainly not impossible to parse, it isn't very pleasant to either
  read or write (as evidenced by the XML-roff toolchain used for the OVN
  sources). Sphinx/rST isn't perfect but it's certainly easier on the eyes.

- Sphinx/rST über alles

  We already use Sphinx for every other bit of documentation in the toolchain.
  Why force people to learn a second syntax for man pages?

- Integration with other documentation

  By building with Sphinx, we can do basic things like output the man pages as
  part of the documentation along with more advanced things like
  cross-referencing applications from elesewhere in the docs.

This series begins work on converting the docs, starting with two small
utilities: ovs-test and ovs-vlan-test. We can use these to tease out any issues
we might have with the idea before expanding this to more complex man pages
(ovs-vsctl, I'm looking at you). The eventual goal would be to move all man
pages to rST/Sphinx.
---
I meant to send this months ago, but I completely forgot about it. It's
unfinished, as evidenced by the commit footers. However, I think with a little
help from the maintainers of the packaging in OVS, it will be easy push this
over the line and move onto the bigger, more important man pages.

Stephen Finucane (4):
  doc: Add man page section to documentation guide
  doc: Convert ovs-vlan-test to rST
  doc: Convert ovs-test to rST
  doc: Remove latex output configuration

 Documentation/automake.mk  |  23 +--
 Documentation/conf.py  |   6 +-
 .../internals/contributing/documentation-style.rst |  85 ++-
 Documentation/intro/install/documentation.rst  |   4 +-
 Documentation/ref/index.rst|  17 ++-
 Documentation/ref/ovs-test.rst | 165 +
 Documentation/ref/ovs-vlan-test.rst| 114 ++
 debian/openvswitch-switch.manpages |   1 -
 debian/openvswitch-test.manpages   |   1 -
 manpages.mk|  20 ---
 utilities/automake.mk  |   6 -
 11 files changed, 389 insertions(+), 53 deletions(-)
 create mode 100644 Documentation/ref/ovs-test.rst
 create mode 100644 Documentation/ref/ovs-vlan-test.rst

-- 
2.9.3

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

Re: [ovs-dev] [PATCH v3] netdev-dpdk: leverage the mempool offload support

[Kevin Traynor]

On 03/24/2017 07:27 AM, Hemant Agrawal wrote:
> DPDK 16.07 introduced the support for mempool offload support.
> rte_pktmbuf_pool_create is the recommended method for creating pktmbuf
> pools. Buffer pools created with rte_mempool_create may not get offloaded
> to the underlying offloaded mempools.
> 
> This patch, changes the rte_mempool_create to use helper wrapper
> "rte_pktmbuf_pool_create" provided by dpdk, so that it can leverage
> offloaded mempools.
> 
> Signed-off-by: Hemant Agrawal 
> ---
> v3:
>  * adding OVS_UNUSED for mp parameter
> 
> v2:
>  * removing rte_pktmbuf_init as per review comment

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

Re: [ovs-dev] [PATCH] netdev-dpdk: Enable INDIRECT_DESC on DPDK vHostUser.

[Kevin Traynor]

On 04/10/2017 08:03 AM, Darrell Ball wrote:
> 
> 
> On 4/5/17, 7:52 AM, "ovs-dev-boun...@openvswitch.org on behalf of O Mahony, 
> Billy"  billy.o.mah...@intel.com> wrote:
> 
> > -Original Message-
> > From: Kevin Traynor [mailto:ktray...@redhat.com]
> > Sent: Wednesday, April 5, 2017 2:58 PM
> > To: O Mahony, Billy ; Maxime Coquelin
> > ; d...@openvswitch.org
> > Subject: Re: [ovs-dev] [PATCH] netdev-dpdk: Enable INDIRECT_DESC on
> > DPDK vHostUser.
> > 
> > On 03/20/2017 11:18 AM, O Mahony, Billy wrote:
> > > Hi Maxime,
> > >
> > >> -Original Message-
> > >> From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> > >> Sent: Friday, March 17, 2017 9:48 AM
> > >> To: O Mahony, Billy ; d...@openvswitch.org
> > >> Subject: Re: [ovs-dev] [PATCH] netdev-dpdk: Enable INDIRECT_DESC on
> > >> DPDK vHostUser.
> > >>
> > >> Hi Billy,
> > >>
> > >> On 03/01/2017 01:36 PM, Billy O'Mahony wrote:
> > >>> Hi All,
> > >>>
> > >>> I'm creating this patch on the basis of performance results outlined
> > >>> below. In summary it appears that enabling INDIRECT_DESC on DPDK
> > >>> vHostUser ports leads to very large increase in performance when
> > >>> using linux stack applications in the guest with no noticable
> > >>> performance drop for DPDK based applications in the guest.
> > >>>
> > >>> Test#1 (VM-VM iperf3 performance)
> > >>>  VMs use DPDK vhostuser ports
> > >>>  OVS bridge is configured for normal action.
> > >>>  OVS version 603381a (on 2.7.0 branch but before release,
> > >>>  also seen on v2.6.0 and v2.6.1)  DPDK v16.11  QEMU v2.5.0 (also
> > >>> seen with v2.7.1)
> > >>>
> > >>>  Results:
> > >>>   INDIRECT_DESC enabled5.30 Gbit/s
> > >>>   INDIRECT_DESC disabled   0.05 Gbit/s
> > >> This is indeed a big gain.
> > >> However, isn't there a problem when indirect descriptors are 
> disabled?
> > >> 0.05 Gbits/s is very low, no?
> > >
> > > [[BO'M]] Yes the disabling of the indirect descriptors feature 
> appears to be
> > what causes the very low test result. And the root cause may actually be
> > related to this bug
> > https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1668829 .
> > However, turning on the indirect descriptors certainly helps greatly.
> > >
> > >>
> > >> Could you share the iperf3 command line you used?
> > >
> > >  [[BO'M]] In the server VM "iperf3 -s" and in the client "iperf3 -c 
>  > addr> -t 30". -t 30 is the duration (secs) of the test. OVS-DPDK bridge 
> was set
> > to use normal action.
> > >
> > Hi Billy,
> > 
> > I ran the iperf test on master and I see very different results than 
> you got?
> > 
> > mrg on/indirect off: 7.10 Gbps
> > mrg off/indirect off: 5.05 Gbps
> > mrg off/indirect on: 7.15 Gbps
> 
> [[BO'M]] 
> Hi Kevin,
> 
> By those figures the performance is still +40% in the right direction for 
> using indirect descriptors.
> 
> What version of qemu did you use? (if as per the Launchpad bug qemu is a 
> root cause here). Also in that case kernel versions may be significant.
> 
> I was using qemu 2.5 (tagged release, built locally) and Ubuntu 16.04.01 
> with 4.04 kernel in the guest. 
> 
> I can retry the tests with head of master when I get a chance but the 
> patch is still offering a large improvement.
> 
> Cheers,
> Billy.
> 
> I tried it as well, on one server…
> Test#1 (VM-VM iperf3 performance):
> DPDK v16.11  QEMU v2.5.0, OVS 2.7.0 branch also before release/similar 
> relevant content.
> mrg off
> Indirect off: 0.164 Gbps
> Indirect on: 2.01Gbps
> 
> Are there any significant reasons not to merge this patch ?
>  

No, I think it's ok to merge. I did some additional testing with % loss
and DPDK in the guest and did not see any significant difference.

Acked-by: Kevin Traynor 

> > 
> > Kevin.
> > 
> > >>
> > >>> Test#2  (Phy-VM-Phy RFC2544 Throughput)  DPDK PMDs are polling NIC,
> > >>> DPDK loopback app running in guest.
> > >>>  OVS bridge is configured with port forwarding to VM (via
> > >>> dpdkvhostuser
> > >> ports).
> > >>>  OVS version 603381a (on 2.7.0 branch but before release),
> > >>>  other versions not tested.
> > >>>  DPDK v16.11
> > >>>  QEMU v2.5.0 (also seen with v2.7.1)
> > >>>
> > >>>  Results:
> > >>>   INDIRECT_DESC enabled2.75 Mpps @64B pkts (0.176 Gbit/s)
> > >>>   INDIRECT_DESC disabled   2.75 Mpps @64B pkts (0.176 Gbit/s)
> > >>
> > >> Is this with 0% packet loss?
> > > [[BO'M]] Yes. To an accuracy of .05 Mpps.
> > >>
> > >> Regards,
> > >> Maxime
> > > 

[ovs-dev] [PATCH v2] python: Allow tuning the session probe_interval from IDL

[Lucas Alvares Gomes]

This patch is adding a new parameter called "probe_interval" to the
constructor of the Idl class. This new parameter will be used to tune
the database connection probing for that IDL session, some users might
want to tune it to be less agressive than the current 5s default in OVS
or even disable it.

Reported-at: https://bugs.launchpad.net/networking-ovn/+bug/1680146
Signed-off-by: Lucas Alvares Gomes 
---
v2: Change the probe interval before the connection is opened

 python/ovs/db/idl.py  | 12 +---
 python/ovs/jsonrpc.py | 11 +--
 2 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py
index 079a03ba1..60548bcf5 100644
--- a/python/ovs/db/idl.py
+++ b/python/ovs/db/idl.py
@@ -94,7 +94,7 @@ class Idl(object):
 IDL_S_MONITOR_REQUESTED = 1
 IDL_S_MONITOR_COND_REQUESTED = 2

-def __init__(self, remote, schema):
+def __init__(self, remote, schema, probe_interval=None):
 """Creates and returns a connection to the database named
'db_name' on
 'remote', which should be in a form acceptable to
 ovs.jsonrpc.session.open().  The connection will maintain an
in-memory
@@ -112,7 +112,12 @@ class Idl(object):
 As a convenience to users, 'schema' may also be an instance of the
 SchemaHelper class.

-The IDL uses and modifies 'schema' directly."""
+The IDL uses and modifies 'schema' directly.
+
+If "probe_interval" is zero it disables the connection keepalive
+feature. If non-zero the value will be forced to at least 1000
+milliseconds. If None it will just use the default value in OVS.
+"""

 assert isinstance(schema, SchemaHelper)
 schema = schema.get_idl_schema()
@@ -120,7 +125,8 @@ class Idl(object):
 self.tables = schema.tables
 self.readonly = schema.readonly
 self._db = schema
-self._session = ovs.jsonrpc.Session.open(remote)
+self._session = ovs.jsonrpc.Session.open(remote,
+probe_interval=probe_interval)
 self._monitor_request_id = None
 self._last_seqno = None
 self.change_seqno = 0
diff --git a/python/ovs/jsonrpc.py b/python/ovs/jsonrpc.py
index 69f7abeb8..09e9c8b0a 100644
--- a/python/ovs/jsonrpc.py
+++ b/python/ovs/jsonrpc.py
@@ -376,7 +376,7 @@ class Session(object):
 self.seqno = 0

 @staticmethod
-def open(name):
+def open(name, probe_interval=None):
 """Creates and returns a Session that maintains a JSON-RPC session
to
 'name', which should be a string acceptable to ovs.stream.Stream or
 ovs.stream.PassiveStream's initializer.
@@ -387,7 +387,12 @@ class Session(object):
 If 'name' is a passive connection method, e.g. "ptcp:", the new
session
 listens for connections to 'name'.  It maintains at most one
connection
 at any given time.  Any new connection causes the previous one (if
any)
-to be dropped."""
+to be dropped.
+
+If "probe_interval" is zero it disables the connection keepalive
+feature. If non-zero the value will be forced to at least 1000
+milliseconds. If None it will just use the default value in OVS.
+"""
 reconnect = ovs.reconnect.Reconnect(ovs.timeval.msec())
 reconnect.set_name(name)
 reconnect.enable(ovs.timeval.msec())
@@ -397,6 +402,8 @@ class Session(object):

 if not ovs.stream.stream_or_pstream_needs_probes(name):
 reconnect.set_probe_interval(0)
+elif probe_interval is not None:
+reconnect.set_probe_interval(probe_interval)

 return Session(reconnect, None)

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

[ovs-dev] nouveau

[Telephone 0176243081]

.ReadMsgBody { WIDTH: 100% } .ExternalClass { WIDTH: 100% } HTML {
PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px;
PADDING-RIGHT: 0px } BODY { HEIGHT: 100%; WIDTH: 100% !important;
PADDING-BOTTOM: 20px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px;
PADDING-RIGHT: 0px } TABLE { TEXT-ALIGN: left } [name='bloc'] {
MARGIN-BOTTOM: 0px; BORDER-TOP: #00 0px solid; BORDER-RIGHT:
#00 0px solid; MARGIN-TOP: 0px; BORDER-BOTTOM: #00 0px solid;
BORDER-LEFT: #00 0px solid } [name='bloc'] TD { PADDING-BOTTOM:
2px; PADDING-TOP: 2px; PADDING-LEFT: 2px; PADDING-RIGHT: 2px }
[name='column'] { BORDER-TOP: #00 0px solid; BORDER-RIGHT: #00
0px solid; VERTICAL-ALIGN: top; BORDER-BOTTOM: #00 0px solid;
BORDER-LEFT: #00 0px solid } [name='objetText'] TD { FONT-SIZE:
12px; FONT-FAMILY: Verdana, Geneva, sans-serif; COLOR: #00;
PADDING-BOTTOM: 3px; -MS-TEXT-SIZE-ADJUST: 100%; TEXT-ALIGN: left;
PADDING-TOP: 3px; PADDING-LEFT: 3px; LINE-HEIGHT: 1.5; PADDING-RIGHT:
3px; -webkit-text-size-adjust: 100% } [name='objetImage'] TD {
MAX-WIDTH: 0px; PADDING-BOTTOM: 3px; TEXT-ALIGN: center; PADDING-TOP:
3px; PADDING-LEFT: 3px; PADDING-RIGHT: 3px } [name='objetButton'] TD {
PADDING-BOTTOM: 3px; TEXT-ALIGN: center; PADDING-TOP: 3px;
PADDING-LEFT: 3px; PADDING-RIGHT: 3px } [name='objetSocial'] TD {
PADDING-BOTTOM: 3px; TEXT-ALIGN: center; PADDING-TOP: 3px;
PADDING-LEFT: 3px; PADDING-RIGHT: 3px } [name='objetDivider'] TD {
PADDING-BOTTOM: 3px; PADDING-TOP: 3px; PADDING-LEFT: 3px;
PADDING-RIGHT: 3px } [name='objetSpacer'] TD { PADDING-BOTTOM: 3px;
PADDING-TOP: 3px; PADDING-LEFT: 3px; PADDING-RIGHT: 3px }
[name='objetVideo'] TD { MAX-WIDTH: 0px; PADDING-BOTTOM: 3px;
TEXT-ALIGN: center; PADDING-TOP: 3px; PADDING-LEFT: 3px; PADDING-RIGHT:
3px } [name='objetShare'] TD { MAX-WIDTH: 0px; PADDING-BOTTOM: 3px;
TEXT-ALIGN: center; PADDING-TOP: 3px; PADDING-LEFT: 3px; PADDING-RIGHT:
3px } [name='objetImage'] IMG { BORDER-LEFT-WIDTH: 0px; MAX-WIDTH:
100%; BORDER-RIGHT-WIDTH: 0px; BORDER-BOTTOM-WIDTH: 0px;
BORDER-TOP-WIDTH: 0px } [name='objetButton'] A DIV { FONT-SIZE: 16px;
BORDER-TOP: #ff 1px solid; HEIGHT: 50px; FONT-FAMILY: Arial,
Helvetica, sans-serif; BORDER-RIGHT: #ff 1px solid; WIDTH: 150px;
BORDER-BOTTOM: #ff 1px solid; FONT-WEIGHT: bold; COLOR: #ff;
MARGIN-LEFT: auto; BORDER-LEFT: #ff 1px solid; BACKGROUND-COLOR:
#ff; MARGIN-RIGHT: auto; border-radius: 5px } [name='objetSocial']
A IMG { PADDING-LEFT: 2px; PADDING-RIGHT: 2px } [name='objetDivider']
DIV { MARGIN-BOTTOM: 2px; BORDER-TOP: #00 1px dotted; MARGIN-TOP:
2px } [name='objetSpacer'] DIV { BORDER-LEFT-WIDTH: 0px; HEIGHT: 20px;
BORDER-RIGHT-WIDTH: 0px; BORDER-BOTTOM-WIDTH: 0px; BORDER-TOP-WIDTH:
0px } [name='objetVideo'] IMG { BORDER-LEFT-WIDTH: 0px; MAX-WIDTH:
100%; BORDER-RIGHT-WIDTH: 0px; BORDER-BOTTOM-WIDTH: 0px;
BORDER-TOP-WIDTH: 0px } [name='objetShare'] IMG { BORDER-LEFT-WIDTH:
0px; MAX-WIDTH: 100%; BORDER-RIGHT-WIDTH: 0px; BORDER-BOTTOM-WIDTH:
0px; BORDER-TOP-WIDTH: 0px } .{ } .dragableObjet { } UNKNOWN { }
[name='end']{} @media only screen and (max-width: 480px){
[id='messageEval']{display:none;} body{width:100% !important;
min-width:100% !important;} table[class="flexibleContainer"]
{width:100% !important;} td[class="flexibleContainerCell"] {width:100%
!important;} td[class="flexibleContainerBox"]{display:block; width:100%
!important;} td[class="flexibleContainerBoxNext"]{padding-top:10px
!important; padding-left:0px !important; display: block; width:100%
!important;} [name='bloc'] TD {PADDING-LEFT:0px; PADDING-RIGHT:0px} img
{width: auto !important; height: auto !important;} img[name="1923"]
{width: 10px !important; height: 10px !important; display:none;} }



















Formation au métier de Magnétiseur



















































Guérir par les Mains ? Nos formations sont réputées et vous
permettront de vous installer à votre compte ou, l'utiliser pour votre
plaisir personnel Paris, Lyon, Marseille, Toulouse, Nantes, Strasbourg,
Le Havre ... Vous pouvez nous contacter au
01.80.91.85.24 ou alors, cliquez sur la photo pour
visiter notre site 







. . . .  .









.

Pour vous désinscrire, répondez à ce mail en mettant STOP dans l'objet














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

Re: [ovs-dev] [PATCH] netdev-dpdk: Enable INDIRECT_DESC on DPDK vHostUser.

[Darrell Ball]

On 4/5/17, 7:52 AM, "ovs-dev-boun...@openvswitch.org on behalf of O Mahony, 
Billy"  
wrote:

> -Original Message-
> From: Kevin Traynor [mailto:ktray...@redhat.com]
> Sent: Wednesday, April 5, 2017 2:58 PM
> To: O Mahony, Billy ; Maxime Coquelin
> ; d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH] netdev-dpdk: Enable INDIRECT_DESC on
> DPDK vHostUser.
> 
> On 03/20/2017 11:18 AM, O Mahony, Billy wrote:
> > Hi Maxime,
> >
> >> -Original Message-
> >> From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> >> Sent: Friday, March 17, 2017 9:48 AM
> >> To: O Mahony, Billy ; d...@openvswitch.org
> >> Subject: Re: [ovs-dev] [PATCH] netdev-dpdk: Enable INDIRECT_DESC on
> >> DPDK vHostUser.
> >>
> >> Hi Billy,
> >>
> >> On 03/01/2017 01:36 PM, Billy O'Mahony wrote:
> >>> Hi All,
> >>>
> >>> I'm creating this patch on the basis of performance results outlined
> >>> below. In summary it appears that enabling INDIRECT_DESC on DPDK
> >>> vHostUser ports leads to very large increase in performance when
> >>> using linux stack applications in the guest with no noticable
> >>> performance drop for DPDK based applications in the guest.
> >>>
> >>> Test#1 (VM-VM iperf3 performance)
> >>>  VMs use DPDK vhostuser ports
> >>>  OVS bridge is configured for normal action.
> >>>  OVS version 603381a (on 2.7.0 branch but before release,
> >>>  also seen on v2.6.0 and v2.6.1)  DPDK v16.11  QEMU v2.5.0 (also
> >>> seen with v2.7.1)
> >>>
> >>>  Results:
> >>>   INDIRECT_DESC enabled5.30 Gbit/s
> >>>   INDIRECT_DESC disabled   0.05 Gbit/s
> >> This is indeed a big gain.
> >> However, isn't there a problem when indirect descriptors are disabled?
> >> 0.05 Gbits/s is very low, no?
> >
> > [[BO'M]] Yes the disabling of the indirect descriptors feature appears 
to be
> what causes the very low test result. And the root cause may actually be
> related to this bug
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1668829 .
> However, turning on the indirect descriptors certainly helps greatly.
> >
> >>
> >> Could you share the iperf3 command line you used?
> >
> >  [[BO'M]] In the server VM "iperf3 -s" and in the client "iperf3 -c 
 addr> -t 30". -t 30 is the duration (secs) of the test. OVS-DPDK bridge 
was set
> to use normal action.
> >
> Hi Billy,
> 
> I ran the iperf test on master and I see very different results than you 
got?
> 
> mrg on/indirect off: 7.10 Gbps
> mrg off/indirect off: 5.05 Gbps
> mrg off/indirect on: 7.15 Gbps

[[BO'M]] 
Hi Kevin,

By those figures the performance is still +40% in the right direction for 
using indirect descriptors.

What version of qemu did you use? (if as per the Launchpad bug qemu is a 
root cause here). Also in that case kernel versions may be significant.

I was using qemu 2.5 (tagged release, built locally) and Ubuntu 16.04.01 
with 4.04 kernel in the guest. 

I can retry the tests with head of master when I get a chance but the patch 
is still offering a large improvement.

Cheers,
Billy.

I tried it as well, on one server…
Test#1 (VM-VM iperf3 performance):
DPDK v16.11  QEMU v2.5.0, OVS 2.7.0 branch also before release/similar relevant 
content.
mrg off
Indirect off: 0.164 Gbps
Indirect on: 2.01Gbps

Are there any significant reasons not to merge this patch ?

> 
> Kevin.
> 
> >>
> >>> Test#2  (Phy-VM-Phy RFC2544 Throughput)  DPDK PMDs are polling NIC,
> >>> DPDK loopback app running in guest.
> >>>  OVS bridge is configured with port forwarding to VM (via
> >>> dpdkvhostuser
> >> ports).
> >>>  OVS version 603381a (on 2.7.0 branch but before release),
> >>>  other versions not tested.
> >>>  DPDK v16.11
> >>>  QEMU v2.5.0 (also seen with v2.7.1)
> >>>
> >>>  Results:
> >>>   INDIRECT_DESC enabled2.75 Mpps @64B pkts (0.176 Gbit/s)
> >>>   INDIRECT_DESC disabled   2.75 Mpps @64B pkts (0.176 Gbit/s)
> >>
> >> Is this with 0% packet loss?
> > [[BO'M]] Yes. To an accuracy of .05 Mpps.
> >>
> >> Regards,
> >> Maxime
> > ___
> > 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=N-90MtQTpByf75yO-qoXyVLC7NqPpmWBKW3hZRlofyk=x-LS86EsgYxoUprrL5UFic980t77wrS9wrIVG56nxfY=
 
> >

___
dev mailing list
d...@openvswitch.org