[ovs-dev] [PATCH] ovn-nbctl: check for duplicated ACL adding.

[Han Zhou]

Check for duplicated ACL adding and add option --may-exist for
ovn-nbctl acl-add.

Signed-off-by: Han Zhou 
---
 ovn/utilities/ovn-nbctl.8.xml |  5 -
 ovn/utilities/ovn-nbctl.c | 14 +-
 tests/ovn-nbctl.at|  4 
 3 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/ovn/utilities/ovn-nbctl.8.xml b/ovn/utilities/ovn-nbctl.8.xml
index 4911c6a..03d8be9 100644
--- a/ovn/utilities/ovn-nbctl.8.xml
+++ b/ovn/utilities/ovn-nbctl.8.xml
@@ -76,7 +76,7 @@
 
 Logical Switch ACL Commands
 
-  [--log] acl-add switch 
direction priority match action
+  [--log] [--may-exist] acl-add 
switch direction priority match 
action
   
 Adds the specified ACL to switch.
 direction must be either from-lport or
@@ -84,6 +84,9 @@
 0 and 32767, inclusive.  If
 --log is specified, packet logging is enabled for the
 ACL.  A full description of the fields are in ovn-nb(5).
+If --may-exist is specified, adding a duplicated ACL
+succeeds but the ACL is not really created. Without 
--may-exist,
+adding a duplicated ACL results in error.
   
 
   acl-del switch [direction 
[priority match]]
diff --git a/ovn/utilities/ovn-nbctl.c b/ovn/utilities/ovn-nbctl.c
index 4397daf..bca59fe 100644
--- a/ovn/utilities/ovn-nbctl.c
+++ b/ovn/utilities/ovn-nbctl.c
@@ -1314,6 +1314,18 @@ nbctl_acl_add(struct ctl_context *ctx)
 nbrec_acl_set_log(acl, true);
 }
 
+/* Check if same acl already exists for the ls */
+for (size_t i = 0; i < ls->n_acls; i++) {
+if (!acl_cmp(&ls->acls[i], &acl)) {
+bool may_exist = shash_find(&ctx->options, "--may-exist") != NULL;
+if (!may_exist) {
+ctl_fatal("Same ACL already existed on the ls %s.",
+  ctx->argv[1]);
+}
+return;
+}
+}
+
 /* Insert the acl into the logical switch. */
 nbrec_logical_switch_verify_acls(ls);
 struct nbrec_acl **new_acls = xmalloc(sizeof *new_acls * (ls->n_acls + 1));
@@ -3244,7 +3256,7 @@ static const struct ctl_command_syntax nbctl_commands[] = 
{
 
 /* acl commands. */
 { "acl-add", 5, 5, "SWITCH DIRECTION PRIORITY MATCH ACTION", NULL,
-  nbctl_acl_add, NULL, "--log", RW },
+  nbctl_acl_add, NULL, "--log,--may-exist", RW },
 { "acl-del", 1, 4, "SWITCH [DIRECTION [PRIORITY MATCH]]", NULL,
   nbctl_acl_del, NULL, "", RW },
 { "acl-list", 1, 1, "SWITCH", NULL, nbctl_acl_list, NULL, "", RO },
diff --git a/tests/ovn-nbctl.at b/tests/ovn-nbctl.at
index 164c81a..81530d1 100644
--- a/tests/ovn-nbctl.at
+++ b/tests/ovn-nbctl.at
@@ -200,6 +200,10 @@ AT_CHECK([ovn-nbctl acl-add ls0 from-lport 400 tcp drop])
 AT_CHECK([ovn-nbctl acl-add ls0 to-lport 300 tcp drop])
 AT_CHECK([ovn-nbctl acl-add ls0 from-lport 200 ip drop])
 AT_CHECK([ovn-nbctl acl-add ls0 to-lport 100 ip drop])
+dnl Add duplicated ACL
+AT_CHECK([ovn-nbctl acl-add ls0 to-lport 100 ip drop], [1], [], [stderr])
+AT_CHECK([grep 'already existed' stderr], [0], [ignore])
+AT_CHECK([ovn-nbctl --may-exist acl-add ls0 to-lport 100 ip drop])
 
 AT_CHECK([ovn-nbctl acl-list ls0], [0], [dnl
 from-lport   600 (udp) drop log
-- 
2.1.0

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

[ovs-dev] Titulaciones Oficiales UNADE 2017

[Universidad Americana de Europa]

Estimad@ amig@,

Nos ponemos en contacto con usted para  informarle de todas las  novedades en 
Titulaciones Oficiales en Modalidad No Escolarizada   de la 
prestigiosa Universidad Americana de Europa para este año 2017:


DOCTORADOS
 Doctorado en Proyectos
 Doctorado en Investigación y Docencia   
 Doctorado en Psicología Empresarial 
  
MAESTRÍAS 
 Maestría en Controller Financiero
 Maestría en Dirección y Gestión de Recursos Humanos   
 Maestría en Logística, Compras y Transporte 
 Maestría en Educación
 Maestría Diseño, Gestión y Dirección de Proyectos   
 Maestría en Prevención de Riesgos Laborales
 Maestría en Ingeniería del Software
 Maestría en Dirección y Gestión de Recursos Humanos   
 Maestría en Dirección y Gestión Hotelera 
 Maestría en Gestión Integrada de Prevención, Medio Ambiente y Calidad
 Maestría en Eficiencia Energética y Energías Renovables   
 Maestría en Gestión y Auditoría Ambiental
 Maestría en Relaciones Internacionales y Comercio Exterior

Postulaciones Abiertas Convocatoria 2017 ¡No pierda su plaza!

Si está interesado, puede contactar con nosotros contestando directamente a 
este mail o a través del formulario de nuestra web que encontrará 
en la ficha de cada titulación.

Muchas gracias por su atención.

Reciba un Cordial Saludo.





Francisco Hernández
  Admisiones
  Universidad Americana de Europa
  

  
  

Sus datos han sido incorporados a la lista de 
distribución de UNADE. Si no quiere recibir más publicidad de máster, maestrías 
o cursos de capacitación pulse aquí o envíe un correo electrónico a 
i...@universidad-oficial.com y su correo electrónico se dará de baja de esta 
lista de distribución.   
  
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] configuration.rst: Update the example of DPDK port's configuration

[Daniele Di Proietto]

2017-01-18 15:18 GMT-08:00 Daniele Di Proietto :
> 2017-01-18 11:55 GMT-08:00 Binbin Xu :
>> After the hotplug of DPDK ports, a valid dpdk-devargs must be
>> specified. Otherwise, the DPDK device can't be available.
>>
>> Signed-off-by: Binbin Xu 
>
> Thanks! Applied to master and branch-2.7

I realized that we forgot to update the documentation in other places,
so I sent a patch here:

https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327782.html

>
>> ---
>>  Documentation/faq/configuration.rst | 7 +++
>>  1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/faq/configuration.rst 
>> b/Documentation/faq/configuration.rst
>> index c03d069..8bd0e11 100644
>> --- a/Documentation/faq/configuration.rst
>> +++ b/Documentation/faq/configuration.rst
>> @@ -107,12 +107,11 @@ Q: How do I configure a DPDK port as an access port?
>>  startup when other_config:dpdk-init is set to 'true'.
>>
>>  Secondly, when adding a DPDK port, unlike a system port, the type for 
>> the
>> -interface must be specified. For example::
>> +interface and valid dpdk-devargs must be specified. For example::
>>
>>  $ ovs-vsctl add-br br0
>> -$ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
>> -
>> -Finally, it is required that DPDK port names begin with ``dpdk``.
>> +$ ovs-vsctl add-port br0 myportname -- set Interface myportname \
>> +type=dpdk options:dpdk-devargs=:06:00.0
>>
>>  Refer to :doc:`/intro/install/dpdk` for more information on enabling and
>>  using DPDK with Open vSwitch.
>> --
>> 1.8.3.1
>>
>>
>> ___
>> 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

[ovs-dev] [PATCH] Documentation: Update DPDK doc after port naming change.

[Daniele Di Proietto]

options:dpdk-devargs is always required now.  This commit also changes
some of the names from 'dpdk0' to various others.

netdev-dpdk/detach accepts a PCI id instead of a port name.

CC: Ciara Loftus 
Fixes: 55e075e65ef9("netdev-dpdk: Arbitrary 'dpdk' port naming")
Signed-off-by: Daniele Di Proietto 
---
 Documentation/howto/dpdk.rst| 77 -
 Documentation/howto/userspace-tunneling.rst |  2 +-
 2 files changed, 43 insertions(+), 36 deletions(-)

diff --git a/Documentation/howto/dpdk.rst b/Documentation/howto/dpdk.rst
index fbb4b5361..d1e6e899f 100644
--- a/Documentation/howto/dpdk.rst
+++ b/Documentation/howto/dpdk.rst
@@ -44,8 +44,10 @@ ovs-vsctl can also be used to add DPDK devices. OVS expects 
DPDK device names
 to start with ``dpdk`` and end with a portid. ovs-vswitchd should print the
 number of dpdk devices found in the log file::
 
-$ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
-$ ovs-vsctl add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk
+$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
+options:dpdk-devargs=:01:00.0
+$ ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk \
+options:dpdk-devargs=:01:00.1
 
 After the DPDK ports get added to switch, a polling thread continuously polls
 DPDK devices and consumes 100% of the core, as can be checked from ``top`` and
@@ -55,12 +57,12 @@ DPDK devices and consumes 100% of the core, as can be 
checked from ``top`` and
 $ ps -eLo pid,psr,comm | grep pmd
 
 Creating bonds of DPDK interfaces is slightly different to creating bonds of
-system interfaces. For DPDK, the interface type must be explicitly set. For
-example::
+system interfaces. For DPDK, the interface type and devargs must be explicitly
+set. For example::
 
-$ ovs-vsctl add-bond br0 dpdkbond dpdk0 dpdk1 \
--- set Interface dpdk0 type=dpdk \
--- set Interface dpdk1 type=dpdk
+$ ovs-vsctl add-bond br0 dpdkbond p0 p1 \
+-- set Interface p0 type=dpdk options:dpdk-devargs=:01:00.0 \
+-- set Interface p1 type=dpdk options:dpdk-devargs=:01:00.1
 
 To stop ovs-vswitchd & delete bridge, run::
 
@@ -98,7 +100,7 @@ where:
 
 For example::
 
-$ ovs-vsctl set interface dpdk0 options:n_rxq=4 \
+$ ovs-vsctl set interface dpdk-p0 options:n_rxq=4 \
 other_config:pmd-rxq-affinity="0:3,1:7,3:8"
 
 This will ensure:
@@ -165,27 +167,27 @@ Flow Control
 Flow control can be enabled only on DPDK physical ports. To enable flow control
 support at tx side while adding a port, run::
 
-$ ovs-vsctl add-port br0 dpdk0 -- \
-set Interface dpdk0 type=dpdk options:tx-flow-ctrl=true
+$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
+options:dpdk-devargs=:01:00.0 options:tx-flow-ctrl=true
 
 Similarly, to enable rx flow control, run::
 
-$ ovs-vsctl add-port br0 dpdk0 -- \
-set Interface dpdk0 type=dpdk options:rx-flow-ctrl=true
+$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
+options:dpdk-devargs=:01:00.0 options:rx-flow-ctrl=true
 
 To enable flow control auto-negotiation, run::
 
-$ ovs-vsctl add-port br0 dpdk0 -- \
-set Interface dpdk0 type=dpdk options:flow-ctrl-autoneg=true
+$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
+options:dpdk-devargs=:01:00.0 options:flow-ctrl-autoneg=true
 
 To turn ON the tx flow control at run time for an existing port, run::
 
-$ ovs-vsctl set Interface dpdk0 options:tx-flow-ctrl=true
+$ ovs-vsctl set Interface dpdk-p0 options:tx-flow-ctrl=true
 
 The flow control parameters can be turned off by setting ``false`` to the
 respective parameter. To disable the flow control at tx side, run::
 
-$ ovs-vsctl set Interface dpdk0 options:tx-flow-ctrl=false
+$ ovs-vsctl set Interface dpdk-p0 options:tx-flow-ctrl=false
 
 pdump
 -
@@ -234,13 +236,12 @@ enable Jumbo Frames support for a DPDK port, change the 
Interface's
 ``mtu_request`` attribute to a sufficiently large value. For example, to add a
 DPDK Phy port with MTU of 9000::
 
-$ ovs-vsctl add-port br0 dpdk0 \
-  -- set Interface dpdk0 type=dpdk \
-  -- set Interface dpdk0 mtu_request=9000`
+$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \
+  options:dpdk-devargs=:01:00.0 mtu_request=9000
 
 Similarly, to change the MTU of an existing port to 6200::
 
-$ ovs-vsctl set Interface dpdk0 mtu_request=6200
+$ ovs-vsctl set Interface dpdk-p0 mtu_request=6200
 
 Some additional configuration is needed to take advantage of jumbo frames with
 vHost ports:
@@ -280,14 +281,14 @@ By default, DPDK physical ports are enabled with Rx 
checksum offload. Rx
 checksum offload can be configured on a DPDK physical port either when adding
 or at run time.
 
-To disable Rx checksum offload when adding a DPDK port dpdk0::
+To disable Rx checksum

Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames

[Yang, Yi]

On Wed, Jan 18, 2017 at 01:29:14PM -0800, Joe Stringer wrote:
> On 18 January 2017 at 11:54, Eric Garver  wrote:
> > On Tue, Jan 17, 2017 at 12:37:19AM +, Yang, Yi Y wrote:
> >> What userspace do "802.1ad patches" depend on? Per Pravin's statement, we 
> >> just backport 802.1ad patches to ovs, then the below patch can be applied 
> >> to ovs.
> >
> > Userspace does not yet have support for 802.1ad. I'm still working on
> > it. You can check the list archives for a recent RFC version.
> >
> > I don't know if it's acceptable to backport the datapath (kernel module)
> > support before the userspace support is accepted. If not, you'll have to
> > wait on the userspace.
> > Perhaps Pravin can answer.
> 
> IMO the general method of:
> 1) Add support upstream
> 2) Add userspace support
> 3) Add backport
> 
> ...works nicely because we get feedback for all interested parties for
> the APIs in (1), (2) can add tests and be easily tested against a
> version that works (upstream kernel) and a version that doesn't
> (version in tree) to ensure both cases are handled in a reasonable
> way, then (3) allows people on older kernels to gain access to the
> newer features.
> 
> That said, if other people are blocking on (3) then I think that piece
> should be expedited. Let's say (2) and (3) were swapped, it just means
> we need to be a bit more careful when reviewing/testing to check that
> the newer userspace still handles old kernels (that lack support)
> fine.
> 
> The nice thing about getting the backport earlier is, the closer to
> upstream we are, the sooner we may find issues that affect the latest
> code.

If so, I think the below patch is the best solution to current
situation, it will be automatically overwritten once userspace part and
802.1ad backport are ready to merge.

So I propose we can merge this patch serial first, then merge Eric
Garver's rtnetlink patch serial. By then, ovs can completely support L3
tunnel ports in both compat mode and kernel datapath mode, it will also
work well on Linux 4.7 and later versions.

>From 127b1c7af10220dacc5b0c6a7c8b4e19d9d4ecac Mon Sep 17 00:00:00 2001
From: Yi Yang 
Date: Wed, 28 Dec 2016 10:27:11 +0800
Subject: [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames

Do not always set skb->protocol to be the ethertype of the L3 header.
For a packet with non-accelerated VLAN tags skb->protocol needs to be the 
ethertype of the outermost non-accelerated VLAN ethertype.

Any VLAN offloading is undone on the OVS netlink interface, and any VLAN tags 
added by userspace are non-accelerated, as are double tagged VLAN packets.

Fixes: 018c1dda5f ("openvswitch: 802.1AD Flow handling, actions, vlan parsing, 
netlink attributes")
Fixes: 5108bbaddc ("openvswitch: add processing of L3 packets")
Signed-off-by: Jarno Rajahalme 
Signed-off-by: Yi Yang 
---
 datapath/datapath.c |  1 -
 datapath/flow.c | 42 +-
 2 files changed, 17 insertions(+), 26 deletions(-)

diff --git a/datapath/datapath.c b/datapath/datapath.c
index 1deb62d..dd19a0e 100644
--- a/datapath/datapath.c
+++ b/datapath/datapath.c
@@ -617,7 +617,6 @@ static int ovs_packet_cmd_execute(struct sk_buff *skb, 
struct genl_info *info)
rcu_assign_pointer(flow->sf_acts, acts);
packet->priority = flow->key.phy.priority;
packet->mark = flow->key.phy.skb_mark;
-   packet->protocol = flow->key.eth.type;
 
rcu_read_lock();
dp = get_dp_rcu(net, ovs_header->dp_ifindex);
diff --git a/datapath/flow.c b/datapath/flow.c
index 240bd00..cf35272 100644
--- a/datapath/flow.c
+++ b/datapath/flow.c
@@ -334,6 +334,7 @@ static int parse_vlan(struct sk_buff *skb, struct 
sw_flow_key *key)
 
qp = (struct qtag_prefix *) skb->data;
key->eth.tci = qp->tci | htons(VLAN_TAG_PRESENT);
+   key->eth.type = qp->eth_type;
__skb_pull(skb, sizeof(struct qtag_prefix));
 
return 0;
@@ -493,6 +494,7 @@ static int key_extract(struct sk_buff *skb, struct 
sw_flow_key *key)
return -EINVAL;
 
skb_reset_network_header(skb);
+   key->eth.type = skb->protocol;
} else {
eth = eth_hdr(skb);
ether_addr_copy(key->eth.src, eth->h_source);
@@ -504,11 +506,14 @@ static int key_extract(struct sk_buff *skb, struct 
sw_flow_key *key)
 */
 
key->eth.tci = 0;
-   if (skb_vlan_tag_present(skb))
+   if (skb_vlan_tag_present(skb)) {
key->eth.tci = htons(skb->vlan_tci);
+   key->eth.type = skb->vlan_proto;
+   }
else if (eth->h_proto == htons(ETH_P_8021Q))
if (unlikely(parse_vlan(skb, key)))
return -ENOMEM;
+   skb->protocol = key->eth.type;
 
key->eth.type = parse_ethertype(skb);
if (unlikely(key->eth.type == htons(0)))
@@ -519,7 +524,8 @@ 

Re: [ovs-dev] [PATCH] ovn-nbctl: Ability to bootstrap CA certificate.

[Ben Pfaff]

On Wed, Jan 18, 2017 at 05:09:33AM -0800, Gurucharan Shetty wrote:
> Utilities like ovs-vsctl have the ability to bootstrap
> CA certificate.  It looks useful for ovn-nbctl to have
> the same ability too.  One could connect over to OVN NB
> database over SSL for transactions without having to
> copy over the certificate being used by ovsdb-server
> backing OVN NB.
> 
> Signed-off-by: Gurucharan Shetty 

Seems like a good idea.

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

Re: [ovs-dev] [PATCH] faq: Document OVS packet buffering.

[Ben Pfaff]

Thanks, applied to master.

On Wed, Jan 18, 2017 at 03:12:19PM -0800, Jarno Rajahalme wrote:
> Acked-by: Jarno Rajahalme 
> 
> > On Jan 18, 2017, at 2:43 PM, Ben Pfaff  wrote:
> > 
> > We get questions about this sometimes.
> > 
> > Signed-off-by: Ben Pfaff 
> > ---
> > Documentation/faq/design.rst | 32 
> > 1 file changed, 32 insertions(+)
> > 
> > diff --git a/Documentation/faq/design.rst b/Documentation/faq/design.rst
> > index 733271d..1778125 100644
> > --- a/Documentation/faq/design.rst
> > +++ b/Documentation/faq/design.rst
> > @@ -108,3 +108,35 @@ packets?
> > For more relevant information on the architecture of Open vSwitch, 
> > please
> > read "The Design and Implementation of Open vSwitch", published in 
> > USENIX
> > NSDI 2015.
> > +
> > +Q: How many packets does OVS buffer?  How do I flush them?
> > +
> > +A: Open vSwitch fast path packet processing uses a "run to completion"
> > +model in which every packet is completely handled in a single pass.
> > +Therefore, in the common case where a packet just passes through the 
> > fast
> > +path, Open vSwitch does not buffer packets itself.  The operating 
> > system
> > +and the network drivers involved in receiving and later in 
> > transmitting the
> > +packet do often include buffering.  Open vSwitch is only a middleman
> > +between these and does not have direct access or influence over their
> > +buffers.
> > +
> > +Outside the common case, Open vSwitch does sometimes buffer packets.  
> > When
> > +the OVS fast path processes a packet that does not match any of the 
> > flows
> > +in its megaflow cache, it passes that packet to the Open vSwitch slow 
> > path.
> > +This procedure queues a copy of the packet to the Open vSwitch 
> > userspace
> > +which processes it and, if necessary, passes it back to the kernel 
> > module.
> > +Queuing the packet to userspace as part of this process involves 
> > buffering.
> > +(Going the opposite direction does not, because the kernel actually
> > +processes the request synchronously.)  A few other exceptional cases 
> > also
> > +queue packets to userspace for processing; most of these are due to
> > +OpenFlow actions that the fast path cannot handle and that must 
> > therefore
> > +be handled by the slow path instead.
> > +
> > +OpenFlow also has a concept of packet buffering.  When an OpenFlow 
> > switch
> > +sends a packet to a controller, it may opt to retain a copy of the 
> > packet
> > +in an OpenFlow "packet buffer".  Later, if the controller wants to 
> > tell the
> > +switch to forward a copy of that packet, it can refer to the packet 
> > through
> > +its assigned buffer, instead of sending the whole packet back to the
> > +switch, thereby saving bandwidth in the OpenFlow control channel.  
> > Before
> > +Open vSwitch 2.7, OVS implemented such buffering; Open vSwitch 2.7 and
> > +later do not.
> > -- 
> > 2.10.2
> > 
> > ___
> > 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] ovn-nbctl: Ability to bootstrap CA certificate.

[Lance Richardson]

> From: "Gurucharan Shetty" 
> To: d...@openvswitch.org
> Sent: Wednesday, January 18, 2017 8:09:33 AM
> Subject: [ovs-dev] [PATCH] ovn-nbctl: Ability to bootstrap CA certificate.
> 
> Utilities like ovs-vsctl have the ability to bootstrap
> CA certificate.  It looks useful for ovn-nbctl to have
> the same ability too.  One could connect over to OVN NB
> database over SSL for transactions without having to
> copy over the certificate being used by ovsdb-server
> backing OVN NB.
> 
> Signed-off-by: Gurucharan Shetty 
> ---
LGTM.

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

[ovs-dev] [PATCH] ovn-nbctl: Ability to bootstrap CA certificate.

[Gurucharan Shetty]

Utilities like ovs-vsctl have the ability to bootstrap
CA certificate.  It looks useful for ovn-nbctl to have
the same ability too.  One could connect over to OVN NB
database over SSL for transactions without having to
copy over the certificate being used by ovsdb-server
backing OVN NB.

Signed-off-by: Gurucharan Shetty 
---
 lib/automake.mk   |  1 +
 lib/ssl-bootstrap.xml | 30 ++
 ovn/utilities/ovn-nbctl.8.xml |  1 +
 ovn/utilities/ovn-nbctl.c |  6 ++
 4 files changed, 38 insertions(+)
 create mode 100644 lib/ssl-bootstrap.xml

diff --git a/lib/automake.mk b/lib/automake.mk
index b03dd2d..b1adfce 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -441,6 +441,7 @@ EXTRA_DIST += \
lib/dirs.c.in \
lib/db-ctl-base.xml \
lib/ssl.xml \
+   lib/ssl-bootstrap.xml \
lib/vlog.xml
 
 MAN_FRAGMENTS += \
diff --git a/lib/ssl-bootstrap.xml b/lib/ssl-bootstrap.xml
new file mode 100644
index 000..5fd68e0
--- /dev/null
+++ b/lib/ssl-bootstrap.xml
@@ -0,0 +1,30 @@
+
+
+  --bootstrap-ca-cert=cacert.pem
+  
+
+  When cacert.pem exists, this option has the same effect
+  as -C or --ca-cert. If it does not exist,
+  then the executable will attempt to obtain the CA certificate from the
+  SSL peer on its first SSL connection and save it to the named PEM
+  file.  If it is successful, it will immediately drop the connection
+  and reconnect, and from then on all SSL connections must be
+  authenticated by a certificate signed by the CA certificate thus
+  obtained.
+
+
+  This option exposes the SSL connection to a man-in-the-middle
+  attack obtaining the initial CA certificate, but it may be useful
+  for bootstrapping.  
+
+
+  This option is only useful if the SSL peer sends its CA certificate as
+  part of the SSL certificate chain.  The SSL protocol does not require
+  the server to send the CA certificate.
+
+
+  This option is mutually exclusive with -C and
+  --ca-cert.
+
+  
+
diff --git a/ovn/utilities/ovn-nbctl.8.xml b/ovn/utilities/ovn-nbctl.8.xml
index 4911c6a..f95b88d 100644
--- a/ovn/utilities/ovn-nbctl.8.xml
+++ b/ovn/utilities/ovn-nbctl.8.xml
@@ -829,6 +829,7 @@
   database.
 
 http://www.w3.org/2003/XInclude"/>
+http://www.w3.org/2003/XInclude"/>
 
 Other Options
 
diff --git a/ovn/utilities/ovn-nbctl.c b/ovn/utilities/ovn-nbctl.c
index 4397daf..f0ff27a 100644
--- a/ovn/utilities/ovn-nbctl.c
+++ b/ovn/utilities/ovn-nbctl.c
@@ -165,6 +165,7 @@ parse_options(int argc, char *argv[], struct shash 
*local_options)
 OPT_LOCAL,
 OPT_COMMANDS,
 OPT_OPTIONS,
+OPT_BOOTSTRAP_CA_CERT,
 VLOG_OPTION_ENUMS,
 TABLE_OPTION_ENUMS,
 SSL_OPTION_ENUMS,
@@ -183,6 +184,7 @@ parse_options(int argc, char *argv[], struct shash 
*local_options)
 {"version", no_argument, NULL, 'V'},
 VLOG_LONG_OPTIONS,
 STREAM_SSL_LONG_OPTIONS,
+{"bootstrap-ca-cert", required_argument, NULL, OPT_BOOTSTRAP_CA_CERT},
 TABLE_LONG_OPTIONS,
 {NULL, 0, NULL, 0},
 };
@@ -286,6 +288,10 @@ parse_options(int argc, char *argv[], struct shash 
*local_options)
 TABLE_OPTION_HANDLERS(&table_style)
 STREAM_SSL_OPTION_HANDLERS
 
+case OPT_BOOTSTRAP_CA_CERT:
+stream_ssl_set_ca_cert_file(optarg, true);
+break;
+
 case '?':
 exit(EXIT_FAILURE);
 
-- 
1.9.1

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

Re: [ovs-dev] [PATCH] configuration.rst: Update the example of DPDK port's configuration

[Daniele Di Proietto]

2017-01-18 11:55 GMT-08:00 Binbin Xu :
> After the hotplug of DPDK ports, a valid dpdk-devargs must be
> specified. Otherwise, the DPDK device can't be available.
>
> Signed-off-by: Binbin Xu 

Thanks! Applied to master and branch-2.7

> ---
>  Documentation/faq/configuration.rst | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/faq/configuration.rst 
> b/Documentation/faq/configuration.rst
> index c03d069..8bd0e11 100644
> --- a/Documentation/faq/configuration.rst
> +++ b/Documentation/faq/configuration.rst
> @@ -107,12 +107,11 @@ Q: How do I configure a DPDK port as an access port?
>  startup when other_config:dpdk-init is set to 'true'.
>
>  Secondly, when adding a DPDK port, unlike a system port, the type for the
> -interface must be specified. For example::
> +interface and valid dpdk-devargs must be specified. For example::
>
>  $ ovs-vsctl add-br br0
> -$ ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk
> -
> -Finally, it is required that DPDK port names begin with ``dpdk``.
> +$ ovs-vsctl add-port br0 myportname -- set Interface myportname \
> +type=dpdk options:dpdk-devargs=:06:00.0
>
>  Refer to :doc:`/intro/install/dpdk` for more information on enabling and
>  using DPDK with Open vSwitch.
> --
> 1.8.3.1
>
>
> ___
> 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] faq: Document OVS packet buffering.

[Jarno Rajahalme]

Acked-by: Jarno Rajahalme 

> On Jan 18, 2017, at 2:43 PM, Ben Pfaff  wrote:
> 
> We get questions about this sometimes.
> 
> Signed-off-by: Ben Pfaff 
> ---
> Documentation/faq/design.rst | 32 
> 1 file changed, 32 insertions(+)
> 
> diff --git a/Documentation/faq/design.rst b/Documentation/faq/design.rst
> index 733271d..1778125 100644
> --- a/Documentation/faq/design.rst
> +++ b/Documentation/faq/design.rst
> @@ -108,3 +108,35 @@ packets?
> For more relevant information on the architecture of Open vSwitch, please
> read "The Design and Implementation of Open vSwitch", published in USENIX
> NSDI 2015.
> +
> +Q: How many packets does OVS buffer?  How do I flush them?
> +
> +A: Open vSwitch fast path packet processing uses a "run to completion"
> +model in which every packet is completely handled in a single pass.
> +Therefore, in the common case where a packet just passes through the fast
> +path, Open vSwitch does not buffer packets itself.  The operating system
> +and the network drivers involved in receiving and later in transmitting 
> the
> +packet do often include buffering.  Open vSwitch is only a middleman
> +between these and does not have direct access or influence over their
> +buffers.
> +
> +Outside the common case, Open vSwitch does sometimes buffer packets.  
> When
> +the OVS fast path processes a packet that does not match any of the flows
> +in its megaflow cache, it passes that packet to the Open vSwitch slow 
> path.
> +This procedure queues a copy of the packet to the Open vSwitch userspace
> +which processes it and, if necessary, passes it back to the kernel 
> module.
> +Queuing the packet to userspace as part of this process involves 
> buffering.
> +(Going the opposite direction does not, because the kernel actually
> +processes the request synchronously.)  A few other exceptional cases also
> +queue packets to userspace for processing; most of these are due to
> +OpenFlow actions that the fast path cannot handle and that must therefore
> +be handled by the slow path instead.
> +
> +OpenFlow also has a concept of packet buffering.  When an OpenFlow switch
> +sends a packet to a controller, it may opt to retain a copy of the packet
> +in an OpenFlow "packet buffer".  Later, if the controller wants to tell 
> the
> +switch to forward a copy of that packet, it can refer to the packet 
> through
> +its assigned buffer, instead of sending the whole packet back to the
> +switch, thereby saving bandwidth in the OpenFlow control channel.  Before
> +Open vSwitch 2.7, OVS implemented such buffering; Open vSwitch 2.7 and
> +later do not.
> -- 
> 2.10.2
> 
> ___
> 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

[ovs-dev] [PATCH] faq: Document OVS packet buffering.

[Ben Pfaff]

We get questions about this sometimes.

Signed-off-by: Ben Pfaff 
---
 Documentation/faq/design.rst | 32 
 1 file changed, 32 insertions(+)

diff --git a/Documentation/faq/design.rst b/Documentation/faq/design.rst
index 733271d..1778125 100644
--- a/Documentation/faq/design.rst
+++ b/Documentation/faq/design.rst
@@ -108,3 +108,35 @@ packets?
 For more relevant information on the architecture of Open vSwitch, please
 read "The Design and Implementation of Open vSwitch", published in USENIX
 NSDI 2015.
+
+Q: How many packets does OVS buffer?  How do I flush them?
+
+A: Open vSwitch fast path packet processing uses a "run to completion"
+model in which every packet is completely handled in a single pass.
+Therefore, in the common case where a packet just passes through the fast
+path, Open vSwitch does not buffer packets itself.  The operating system
+and the network drivers involved in receiving and later in transmitting the
+packet do often include buffering.  Open vSwitch is only a middleman
+between these and does not have direct access or influence over their
+buffers.
+
+Outside the common case, Open vSwitch does sometimes buffer packets.  When
+the OVS fast path processes a packet that does not match any of the flows
+in its megaflow cache, it passes that packet to the Open vSwitch slow path.
+This procedure queues a copy of the packet to the Open vSwitch userspace
+which processes it and, if necessary, passes it back to the kernel module.
+Queuing the packet to userspace as part of this process involves buffering.
+(Going the opposite direction does not, because the kernel actually
+processes the request synchronously.)  A few other exceptional cases also
+queue packets to userspace for processing; most of these are due to
+OpenFlow actions that the fast path cannot handle and that must therefore
+be handled by the slow path instead.
+
+OpenFlow also has a concept of packet buffering.  When an OpenFlow switch
+sends a packet to a controller, it may opt to retain a copy of the packet
+in an OpenFlow "packet buffer".  Later, if the controller wants to tell the
+switch to forward a copy of that packet, it can refer to the packet through
+its assigned buffer, instead of sending the whole packet back to the
+switch, thereby saving bandwidth in the OpenFlow control channel.  Before
+Open vSwitch 2.7, OVS implemented such buffering; Open vSwitch 2.7 and
+later do not.
-- 
2.10.2

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

Re: [ovs-dev] [PATCH] ovn-ctl: Add bootstrap ovn-controller CA certificate option.

[Guru Shetty]

On 18 January 2017 at 14:26, Lance Richardson  wrote:

> > From: "Gurucharan Shetty" 
> > To: d...@openvswitch.org
> > Sent: Wednesday, January 18, 2017 6:25:29 AM
> > Subject: [ovs-dev] [PATCH] ovn-ctl: Add bootstrap ovn-controller CA
>  certificate option.
> >
> > ovn-controller accepts the option --bootstrap-ca-cert. With this
> > commit, ovn-ctl will let user pass a value for that via
> > --ovn-controller-ssl-bootstrap-ca-cert option.
> >
> > Bootstrapping is useful for ovn-controller as you don't have to
> > copy the controller's certificate (self-signed or otherwise) to every
> host.
> >
> > Signed-off-by: Gurucharan Shetty 
> > ---
> LGTM (haven't tried it, but I'm planning to). Thanks for the enhancement
> as well as the clean-ups.
>
> It would be nice if this could go into the 2.7 branch as well.
>
> Acked-by: Lance Richardson 
>

Thanks Ben and Lance. I pushed this to master and 2.7.

(The bootstrapping worked fine on my 3 host test bed)
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] [userspace meter 5/5] dpif-netdev: Simple DROP meter implementation.

[Andy Zhou]

From: Jarno Rajahalme 

Meters may be used by any flow, so some kind of locking must be used.
In this version we have an adaptive mutex for each meter, which may
not be optimal for DPDK.  However, this should serve as a basis for
further improvement.

A batch of packets is first tried as a whole, and only if some of the
meter bands are hit, we need to process the packets individually.

Signed-off-by: Jarno Rajahalme 
Signed-off-by: Andy Zhou 
---
 lib/dpif-netdev.c| 363 ---
 tests/dpif-netdev.at | 106 +++
 2 files changed, 451 insertions(+), 18 deletions(-)

diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index e333be7..4fcb01b 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -86,6 +86,8 @@ DEFINE_STATIC_PER_THREAD_DATA(uint32_t, recirc_depth, 0)
 
 /* Configuration parameters. */
 enum { MAX_FLOWS = 65536 }; /* Maximum number of flows in flow table. */
+enum { MAX_METERS = 65536 };/* Maximum number of meters. */
+enum { MAX_BANDS = 8 }; /* Maximum number of bands / meter. */
 
 /* Protects against changes to 'dp_netdevs'. */
 static struct ovs_mutex dp_netdev_mutex = OVS_MUTEX_INITIALIZER;
@@ -193,6 +195,31 @@ static bool dpcls_lookup(struct dpcls *cls,
  struct dpcls_rule **rules, size_t cnt,
  int *num_lookups_p);
 
+/* Set of supported meter flags */
+#define DP_SUPPORTED_METER_FLAGS_MASK \
+(OFPMF13_STATS | OFPMF13_PKTPS | OFPMF13_KBPS | OFPMF13_BURST)
+
+/* Set of supported meter band types */
+#define DP_SUPPORTED_METER_BAND_TYPES   \
+( 1 << OFPMBT13_DROP )
+
+struct dp_meter_band {
+struct ofputil_meter_band up; /* type, prec_level, pad, rate, burst_size */
+uint32_t bucket; /* In 1/1000 packets (for PKTPS), or in bits (for KBPS) */
+uint64_t packet_count;
+uint64_t byte_count;
+};
+
+struct dp_meter {
+uint16_t flags;
+uint16_t n_bands;
+uint32_t max_delta_t;
+uint64_t used;
+uint64_t packet_count;
+uint64_t byte_count;
+struct dp_meter_band bands[];
+};
+
 /* Datapath based on the network device interface from netdev.h.
  *
  *
@@ -223,6 +250,11 @@ struct dp_netdev {
 struct hmap ports;
 struct seq *port_seq;   /* Incremented whenever a port changes. */
 
+/* Meters. */
+struct ovs_mutex meter_locks[MAX_METERS];
+struct dp_meter *meters[MAX_METERS]; /* Meter bands. */
+uint32_t meter_free; /* Next free meter. */
+
 /* Protects access to ofproto-dpif-upcall interface during revalidator
  * thread synchronization. */
 struct fat_rwlock upcall_rwlock;
@@ -1059,6 +1091,10 @@ create_dp_netdev(const char *name, const struct 
dpif_class *class,
 dp->reconfigure_seq = seq_create();
 dp->last_reconfigure_seq = seq_read(dp->reconfigure_seq);
 
+for (int i = 0; i < MAX_METERS; ++i) {
+ovs_mutex_init_adaptive(&dp->meter_locks[i]);
+}
+
 /* Disable upcalls by default. */
 dp_netdev_disable_upcall(dp);
 dp->upcall_aux = NULL;
@@ -1136,6 +1172,16 @@ dp_netdev_destroy_upcall_lock(struct dp_netdev *dp)
 fat_rwlock_destroy(&dp->upcall_rwlock);
 }
 
+static void
+dp_delete_meter(struct dp_netdev *dp, uint32_t meter_id)
+OVS_REQUIRES(dp->meter_locks[meter_id])
+{
+if (dp->meters[meter_id]) {
+free(dp->meters[meter_id]);
+dp->meters[meter_id] = NULL;
+}
+}
+
 /* Requires dp_netdev_mutex so that we can't get a new reference to 'dp'
  * through the 'dp_netdevs' shash while freeing 'dp'. */
 static void
@@ -1151,6 +1197,7 @@ dp_netdev_free(struct dp_netdev *dp)
 do_del_port(dp, port);
 }
 ovs_mutex_unlock(&dp->port_mutex);
+
 dp_netdev_destroy_all_pmds(dp, true);
 cmap_destroy(&dp->poll_threads);
 
@@ -1169,6 +1216,13 @@ dp_netdev_free(struct dp_netdev *dp)
 /* Upcalls must be disabled at this point */
 dp_netdev_destroy_upcall_lock(dp);
 
+for (int i = 0; i < MAX_METERS; ++i) {
+ovs_mutex_lock(&dp->meter_locks[i]);
+dp_delete_meter(dp, i);
+ovs_mutex_unlock(&dp->meter_locks[i]);
+ovs_mutex_destroy(&dp->meter_locks[i]);
+}
+
 free(dp->pmd_cmask);
 free(CONST_CAST(char *, dp->name));
 free(dp);
@@ -3596,37 +3650,305 @@ static void
 dpif_netdev_meter_get_features(const struct dpif * dpif OVS_UNUSED,
struct ofputil_meter_features *features)
 {
-features->max_meters = 0;
-features->band_types = 0;
-features->capabilities = 0;
-features->max_bands = 0;
+features->max_meters = MAX_METERS;
+features->band_types = DP_SUPPORTED_METER_BAND_TYPES;
+features->capabilities = DP_SUPPORTED_METER_FLAGS_MASK;
+features->max_bands = MAX_BANDS;
 features->max_color = 0;
 }
 
+/* Returns false when packet needs to be dropped. */
+static void
+dp_netdev_run_meter(struct dp_netdev *dp, struct dp_packet_batch *packets_,
+uint32_t meter_id, long long int 

[ovs-dev] [userspace meter 4/5] ofproto: Meter translation.

[Andy Zhou]

From: Jarno Rajahalme 

Translate OpenFlow METER instructions to datapath meter actions.

Signed-off-by: Jarno Rajahalme 
Signed-off-by: Andy Zhou 
---
 include/openvswitch/ofp-actions.h |  1 +
 lib/dpif.c| 40 +---
 lib/ofp-actions.c |  1 +
 ofproto/ofproto-dpif-xlate.c  | 11 -
 ofproto/ofproto.c | 49 ++-
 5 files changed, 72 insertions(+), 30 deletions(-)

diff --git a/include/openvswitch/ofp-actions.h 
b/include/openvswitch/ofp-actions.h
index 8ca787a..e269901 100644
--- a/include/openvswitch/ofp-actions.h
+++ b/include/openvswitch/ofp-actions.h
@@ -532,6 +532,7 @@ struct ofpact_metadata {
 struct ofpact_meter {
 struct ofpact ofpact;
 uint32_t meter_id;
+uint32_t provider_meter_id;
 };
 
 /* OFPACT_WRITE_ACTIONS, OFPACT_CLONE.
diff --git a/lib/dpif.c b/lib/dpif.c
index e9e3a05..8c88083 100644
--- a/lib/dpif.c
+++ b/lib/dpif.c
@@ -1104,6 +1104,7 @@ struct dpif_execute_helper_aux {
 struct dpif *dpif;
 const struct flow *flow;
 int error;
+const struct nlattr *meter_action; /* Non-NULL, if have a meter action. */
 };
 
 /* This is called for actions that need the context of the datapath to be
@@ -1119,6 +1120,13 @@ dpif_execute_helper_cb(void *aux_, struct 
dp_packet_batch *packets_,
 ovs_assert(packets_->count == 1);
 
 switch ((enum ovs_action_attr)type) {
+case OVS_ACTION_ATTR_METER:
+/* Maintain a pointer to the first meter action seen. */
+if (!aux->meter_action) {
+aux->meter_action = action;
+}
+   break;
+
 case OVS_ACTION_ATTR_CT:
 case OVS_ACTION_ATTR_OUTPUT:
 case OVS_ACTION_ATTR_TUNNEL_PUSH:
@@ -1129,15 +1137,29 @@ dpif_execute_helper_cb(void *aux_, struct 
dp_packet_batch *packets_,
 struct ofpbuf execute_actions;
 uint64_t stub[256 / 8];
 struct pkt_metadata *md = &packet->md;
-bool dst_set;
 
-dst_set = flow_tnl_dst_is_set(&md->tunnel);
-if (dst_set) {
+if (flow_tnl_dst_is_set(&md->tunnel) || aux->meter_action) {
+ofpbuf_use_stub(&execute_actions, stub, sizeof stub);
+
+if (aux->meter_action) {
+const struct nlattr *a = aux->meter_action;
+
+do {
+ofpbuf_put(&execute_actions, a, NLA_ALIGN(a->nla_len));
+/* Find next meter action before 'action', if any. */
+do {
+a = nl_attr_next(a);
+} while (a != action &&
+ nl_attr_type(a) != OVS_ACTION_ATTR_METER);
+} while (a != action);
+}
+
 /* The Linux kernel datapath throws away the tunnel information
  * that we supply as metadata.  We have to use a "set" action to
  * supply it. */
-ofpbuf_use_stub(&execute_actions, stub, sizeof stub);
-odp_put_tunnel_action(&md->tunnel, &execute_actions);
+if (md->tunnel.ip_dst) {
+odp_put_tunnel_action(&md->tunnel, &execute_actions);
+}
 ofpbuf_put(&execute_actions, action, NLA_ALIGN(action->nla_len));
 
 execute.actions = execute_actions.data;
@@ -1170,14 +1192,16 @@ dpif_execute_helper_cb(void *aux_, struct 
dp_packet_batch *packets_,
 
 dp_packet_delete(clone);
 
-if (dst_set) {
+if (flow_tnl_dst_is_set(&md->tunnel) || aux->meter_action) {
 ofpbuf_uninit(&execute_actions);
+
+/* Do not re-use the same meters for later output actions. */
+aux->meter_action = NULL;
 }
 break;
 }
 
 case OVS_ACTION_ATTR_HASH:
-case OVS_ACTION_ATTR_METER:
 case OVS_ACTION_ATTR_PUSH_VLAN:
 case OVS_ACTION_ATTR_POP_VLAN:
 case OVS_ACTION_ATTR_PUSH_MPLS:
@@ -1200,7 +1224,7 @@ dpif_execute_helper_cb(void *aux_, struct dp_packet_batch 
*packets_,
 static int
 dpif_execute_with_help(struct dpif *dpif, struct dpif_execute *execute)
 {
-struct dpif_execute_helper_aux aux = {dpif, execute->flow, 0};
+struct dpif_execute_helper_aux aux = {dpif, execute->flow, 0, NULL};
 struct dp_packet_batch pb;
 
 COVERAGE_INC(dpif_execute_with_help);
diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
index cf1ad0f..733b2c5 100644
--- a/lib/ofp-actions.c
+++ b/lib/ofp-actions.c
@@ -6868,6 +6868,7 @@ ofpacts_pull_openflow_instructions(struct ofpbuf 
*openflow,
 
 om = ofpact_put_METER(ofpacts);
 om->meter_id = ntohl(oim->meter_id);
+om->provider_meter_id = UINT32_MAX; /* No provider meter ID. */
 }
 if (insts[OVSINST_OFPIT11_APPLY_ACTIONS]) {
 const struct ofp_action_header *actions;
diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index 64fd6c3..6c9ff00 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -4556,6 +4556,15 @@ compose_clone_ac

[ovs-dev] [userspace meter 3/5] dpif: Meter framework.

[Andy Zhou]

From: Jarno Rajahalme 

Add DPIF-level infrastructure for meters.  Allow meter_set to modify
the meter configuration (e.g. set the burst size if unspecified).

Signed-off-by: Jarno Rajahalme 
Signed-off-by: Andy Zhou 
---
 datapath/linux/compat/include/linux/openvswitch.h |  8 ++-
 lib/dpif-netdev.c | 45 
 lib/dpif-netlink.c| 46 +++-
 lib/dpif-provider.h   | 29 
 lib/dpif.c| 88 +++
 lib/dpif.h| 13 +++-
 lib/odp-execute.c |  5 ++
 lib/odp-util.c| 14 
 ofproto/ofproto-dpif-sflow.c  |  1 +
 ofproto/ofproto-dpif.c| 60 ++--
 ofproto/ofproto-provider.h| 13 ++--
 ofproto/ofproto.c |  2 +-
 12 files changed, 308 insertions(+), 16 deletions(-)

diff --git a/datapath/linux/compat/include/linux/openvswitch.h 
b/datapath/linux/compat/include/linux/openvswitch.h
index 12260d8..9f43a97 100644
--- a/datapath/linux/compat/include/linux/openvswitch.h
+++ b/datapath/linux/compat/include/linux/openvswitch.h
@@ -787,13 +787,14 @@ enum ovs_nat_attr {
  * fields within a header are modifiable, e.g. the IPv4 protocol and fragment
  * type may not be changed.
  *
- *
  * @OVS_ACTION_ATTR_SET_TO_MASKED: Kernel internal masked set action translated
  * from the @OVS_ACTION_ATTR_SET.
  * @OVS_ACTION_ATTR_TUNNEL_PUSH: Push tunnel header described by struct
  * ovs_action_push_tnl.
  * @OVS_ACTION_ATTR_TUNNEL_POP: Lookup tunnel port by port-no passed and pop
  * tunnel header.
+ * @OVS_ACTION_ATTR_METER: Run packet through a meter, which may drop the
+ * packet, or modify the packet (e.g., change the DSCP field).
  */
 
 enum ovs_action_attr {
@@ -816,8 +817,9 @@ enum ovs_action_attr {
OVS_ACTION_ATTR_TRUNC,/* u32 struct ovs_action_trunc. */
 
 #ifndef __KERNEL__
-   OVS_ACTION_ATTR_TUNNEL_PUSH,   /* struct ovs_action_push_tnl*/
-   OVS_ACTION_ATTR_TUNNEL_POP,/* u32 port number. */
+   OVS_ACTION_ATTR_TUNNEL_PUSH,  /* struct ovs_action_push_tnl. */
+   OVS_ACTION_ATTR_TUNNEL_POP,   /* u32 port number. */
+   OVS_ACTION_ATTR_METER,/* u32 meter number. */
 #endif
__OVS_ACTION_ATTR_MAX,/* Nothing past this will be accepted
   * from userspace. */
diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
index f4762d5..e333be7 100644
--- a/lib/dpif-netdev.c
+++ b/lib/dpif-netdev.c
@@ -3590,6 +3590,46 @@ dp_netdev_disable_upcall(struct dp_netdev *dp)
 fat_rwlock_wrlock(&dp->upcall_rwlock);
 }
 
+
+/* Meters */
+static void
+dpif_netdev_meter_get_features(const struct dpif * dpif OVS_UNUSED,
+   struct ofputil_meter_features *features)
+{
+features->max_meters = 0;
+features->band_types = 0;
+features->capabilities = 0;
+features->max_bands = 0;
+features->max_color = 0;
+}
+
+static int
+dpif_netdev_meter_set(struct dpif *dpif OVS_UNUSED,
+  ofproto_meter_id *meter_id OVS_UNUSED,
+  struct ofputil_meter_config *config OVS_UNUSED)
+{
+return EFBIG; /* meter_id out of range */
+}
+
+static int
+dpif_netdev_meter_get(const struct dpif *dpif OVS_UNUSED,
+  ofproto_meter_id meter_id OVS_UNUSED,
+  struct ofputil_meter_stats *stats OVS_UNUSED,
+  uint16_t n_bands OVS_UNUSED)
+{
+return EFBIG; /* meter_id out of range */
+}
+
+static int
+dpif_netdev_meter_del(struct dpif *dpif OVS_UNUSED,
+  ofproto_meter_id meter_id OVS_UNUSED,
+  struct ofputil_meter_stats *stats OVS_UNUSED,
+  uint16_t n_bands OVS_UNUSED)
+{
+return EFBIG; /* meter_id out of range */
+}
+
+
 static void
 dpif_netdev_disable_upcall(struct dpif *dpif)
 OVS_NO_THREAD_SAFETY_ANALYSIS
@@ -4716,6 +4756,7 @@ dp_execute_cb(void *aux_, struct dp_packet_batch 
*packets_,
 break;
 }
 
+case OVS_ACTION_ATTR_METER:
 case OVS_ACTION_ATTR_PUSH_VLAN:
 case OVS_ACTION_ATTR_POP_VLAN:
 case OVS_ACTION_ATTR_PUSH_MPLS:
@@ -4852,6 +4893,10 @@ const struct dpif_class dpif_netdev_class = {
 dpif_netdev_ct_dump_next,
 dpif_netdev_ct_dump_done,
 dpif_netdev_ct_flush,
+dpif_netdev_meter_get_features,
+dpif_netdev_meter_set,
+dpif_netdev_meter_get,
+dpif_netdev_meter_del,
 };
 
 static void
diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index c8b0e37..8a48227 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -2356,6 +2356,46 @@ dpif_netlink_ct_flush(struct dpif *dpif OVS_UNUSED, 
const uint16_t *zone)
 }
 }
 
+
+/* Meters */
+static void
+dpif_netlink_meter_get_features(const struct dpif * dpif OVS_UNUSED,
+   

[ovs-dev] [userspace meter 2/5] dp-packet: Enhance packet batch APIs.

[Andy Zhou]

One common use case of 'struct dp_packet_batch' is to process all
packets in the batch in order. Add an iterator for this use case
to simplify the logic of calling sites,

Another common use case is to drop packets in the batch, by read
all packets, but write back pointers of fewer packets, i.e. drop
packets from the patch by not writing the packet pointers back.
Add macros and data structure changes to reduce duplicated logics.

Signed-off-by: Andy Zhou 
---
 lib/dp-packet.h  | 140 ---
 lib/dpif-netdev.c|  56 -
 lib/dpif.c   |   2 +-
 lib/netdev-dummy.c   |  10 ++--
 lib/netdev-linux.c   |   3 +-
 lib/netdev.c |  26 
 lib/odp-execute.c|  49 +++
 ofproto/ofproto-dpif-xlate.c |   2 +-
 tests/test-conntrack.c   |  56 -
 9 files changed, 204 insertions(+), 140 deletions(-)

diff --git a/lib/dp-packet.h b/lib/dp-packet.h
index cf7d247..20ae00c 100644
--- a/lib/dp-packet.h
+++ b/lib/dp-packet.h
@@ -630,81 +630,151 @@ reset_dp_packet_checksum_ol_flags(struct dp_packet *p)
 #endif
 
 enum { NETDEV_MAX_BURST = 32 }; /* Maximum number packets in a batch. */
+enum packet_batch_write_index {
+/* 0 .. NETDEV_MAX_BURST -1, valid write index */
+PACKET_BATCH_READ_ONLY = NETDEV_MAX_BURST };
 
 struct dp_packet_batch {
-int count;
+size_t count;
+size_t windex; /* enum patcket_batch_write_index.  */
 bool trunc; /* true if the batch needs truncate. */
 struct dp_packet *packets[NETDEV_MAX_BURST];
 };
 
-static inline void dp_packet_batch_init(struct dp_packet_batch *b)
+/* Iterator for all packets in 'BATCH' in order. 'IDX' is the 'PACKET' index
+ * in 'BATCH'->packets.
+ *
+ * Note, 'IDX' is Declared within the Iterator, it is only valid within
+ * the scope the iterator. In case 'IDX' is not required,
+ * use 'DP_PACKET_BATCH_FOR_EACH' instead.  */
+#define DP_PACKET_BATCH_FOR_EACH_IDX(IDX, PACKET, BATCH) \
+ovs_assert(!BATCH->windex || BATCH->windex == PACKET_BATCH_READ_ONLY); \
+for (int IDX = 0; IDX < BATCH->count; IDX++)  \
+if ((PACKET = BATCH->packets[IDX]) != NULL) \
+
+#define DP_PACKET_BATCH_FOR_EACH(PACKET, BATCH)\
+ DP_PACKET_BATCH_FOR_EACH_IDX(i, PACKET, BATCH) \
+
+/* 'BATCH' rewrite APIs.
+ *
+ * This macro is useful for cases where some the packets in 'BATCH'
+ * may be dropped. Once the macro is called, 'dp_packet_batch_write()'
+ * should be used to add packets that are dropped back into the 'BATCH',
+ * or the 'BATCH' will become empty after DP_PACKET_BATCH_WRITE_CLOSE().
+ *
+ * A typical code block will look something like the follows:
+ *
+ *  DP_PACKET_BATCH_WRITE_OPEN(batch);
+ *
+ *  DP_PACKET_BATCH_FOR_EACH(packet, batch) {
+ *...
+ *// Write back the packets that are not dropped.
+ *dp_packet_batch_write(batch, packet);
+ *  }
+ *  DP_PACKET_BATCH_WRITE_CLOSE(batch);
+ *
+ * DP_PACKET_BATCH_WRITE_OPEN and DP_PACKET_BATCH_WRITE_CLOSE
+ * must appear in the same code block in pair.
+ *
+ * For packets dropped out of 'batch' the client needs to call
+ * dp_packet_delete() to free the packet.
+ *
+ * It is only safe to rewrite the 'batch' if writes are slower than
+ * read, otherwise, an unread packet can be overwritten. When implementing
+ * packet drop, this is always true.  */
+#define DP_PACKET_BATCH_WRITE_OPEN(BATCH) \
+{ BATCH->windex = 0; \
+
+#define DP_PACKET_BATCH_WRITE_CLOSE(BATCH) \
+  ovs_assert(BATCH->windex != PACKET_BATCH_READ_ONLY);   \
+  BATCH->count = BATCH->windex; \
+  BATCH->windex = PACKET_BATCH_READ_ONLY; };
+
+static inline void dp_packet_batch_init(struct dp_packet_batch *batch)
+{
+batch->count = 0;
+batch->windex = PACKET_BATCH_READ_ONLY;
+batch->trunc = false;
+}
+
+static inline void dp_packet_batch_write(struct dp_packet_batch *batch,
+ struct dp_packet *packet)
 {
-b->count = 0;
-b->trunc = false;
+ovs_assert(batch->windex < NETDEV_MAX_BURST);
+batch->packets[batch->windex++] = packet;
 }
 
 static inline void
 dp_packet_batch_clone(struct dp_packet_batch *dst,
   struct dp_packet_batch *src)
 {
-int i;
+struct dp_packet *packet;
+
+dp_packet_batch_init(dst);
+DP_PACKET_BATCH_WRITE_OPEN(dst);
 
-for (i = 0; i < src->count; i++) {
-dst->packets[i] = dp_packet_clone(src->packets[i]);
+DP_PACKET_BATCH_FOR_EACH (packet, src) {
+dp_packet_batch_write(dst, dp_packet_clone(packet));
 }
-dst->count = src->count;
-dst->trunc = src->trunc;
+
+DP_PACKET_BATCH_WRITE_CLOSE(dst);
 }
 
 static inline void
-packet_batch_init_packet(struct dp_packet_batch *b, struct dp_packet *p)
+dp_packet_batch_init_packet(struct dp_packet_batch *batch, struct dp_packet *p)
+{
+dp_packet_batch_init(batch);
+batch->count = 1;
+

[ovs-dev] [userspace meter 1/5] netdev-dummy: Add --len option for netdev-dummy/receive command

[Andy Zhou]

Currently, there is no way to specify the packet size when injecting
a packet via "netdev-dummy/receive" with a flow specification. Thus
far, packet size is not important for testing OVS features, but it
becomes useful in writing unit tests for the meter implementation
in a later patch.

Signed-off-by: Andy Zhou 
---
 lib/netdev-dummy.c | 38 --
 1 file changed, 28 insertions(+), 10 deletions(-)

diff --git a/lib/netdev-dummy.c b/lib/netdev-dummy.c
index e6e36cd..10df0a7 100644
--- a/lib/netdev-dummy.c
+++ b/lib/netdev-dummy.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2010, 2011, 2012, 2013, 2015, 2016 Nicira, Inc.
+ * Copyright (c) 2010, 2011, 2012, 2013, 2015, 2016, 2017 Nicira, Inc.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -1433,7 +1433,15 @@ pkt_list_delete(struct ovs_list *l)
 }
 
 static struct dp_packet *
-eth_from_packet_or_flow(const char *s)
+eth_from_packet(const char *s)
+{
+struct dp_packet *packet;
+eth_from_hex(s, &packet);
+return packet;
+}
+
+static struct dp_packet *
+eth_from_flow(const char *s)
 {
 enum odp_key_fitness fitness;
 struct dp_packet *packet;
@@ -1441,10 +1449,6 @@ eth_from_packet_or_flow(const char *s)
 struct flow flow;
 int error;
 
-if (!eth_from_hex(s, &packet)) {
-return packet;
-}
-
 /* Convert string to datapath key.
  *
  * It would actually be nicer to parse an OpenFlow-like flow key here, but
@@ -1540,10 +1544,24 @@ netdev_dummy_receive(struct unixctl_conn *conn,
 for (i = k; i < argc; i++) {
 struct dp_packet *packet;
 
-packet = eth_from_packet_or_flow(argv[i]);
+/* Try to parse 'argv[i]' as packet in hex. */
+packet = eth_from_packet(argv[i]);
+
 if (!packet) {
-unixctl_command_reply_error(conn, "bad packet syntax");
-goto exit;
+/* Try parse 'argv[i]' as odp flow. */
+packet = eth_from_flow(argv[i]);
+
+if (!packet) {
+unixctl_command_reply_error(conn, "bad packet or flow syntax");
+goto exit;
+}
+
+/* Parse optional --len argument immediately follow a 'flow'.  */
+if (argc >= i + 2 && !strcmp(argv[i + 1], "--len")) {
+int packet_size = strtol(argv[i + 2], NULL, 10);
+dp_packet_set_size(packet, packet_size);
+i+=2;
+}
 }
 
 netdev_dummy_queue_packet(dummy_dev, packet, rx_qid);
@@ -1757,7 +1775,7 @@ void
 netdev_dummy_register(enum dummy_level level)
 {
 unixctl_command_register("netdev-dummy/receive",
- "name [--qid queue_id] packet|flow...",
+ "name [--qid queue_id] packet|flow [--len packet 
len]..",
  2, INT_MAX, netdev_dummy_receive, NULL);
 unixctl_command_register("netdev-dummy/set-admin-state",
  "[netdev] up|down", 1, 2,
-- 
1.9.1

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

[ovs-dev] [userspace meter 0/5] userspace meter

[Andy Zhou]

Repost user space meter support. This is based Jarno's original work
at: https://mail.openvswitch.org/pipermail/ovs-dev/2015-November/306304.html.
With some enhancements, and rebased to current master.

Andy Zhou (2):
  netdev-dummy: Add --len option for netdev-dummy/receive command
  dp-packet: Enhance packet batch APIs.

Jarno Rajahalme (3):
  dpif: Meter framework.
  ofproto: Meter translation.
  dpif-netdev: Simple DROP meter implementation.

 datapath/linux/compat/include/linux/openvswitch.h |   8 +-
 include/openvswitch/ofp-actions.h |   1 +
 lib/dp-packet.h   | 140 +--
 lib/dpif-netdev.c | 428 --
 lib/dpif-netlink.c|  46 ++-
 lib/dpif-provider.h   |  29 ++
 lib/dpif.c| 128 ++-
 lib/dpif.h|  13 +-
 lib/netdev-dummy.c|  48 ++-
 lib/netdev-linux.c|   3 +-
 lib/netdev.c  |  26 +-
 lib/odp-execute.c |  54 +--
 lib/odp-util.c|  14 +
 lib/ofp-actions.c |   1 +
 ofproto/ofproto-dpif-sflow.c  |   1 +
 ofproto/ofproto-dpif-xlate.c  |  13 +-
 ofproto/ofproto-dpif.c|  60 ++-
 ofproto/ofproto-provider.h|  13 +-
 ofproto/ofproto.c |  51 +--
 tests/dpif-netdev.at  | 106 ++
 tests/test-conntrack.c|  56 ++-
 21 files changed, 1044 insertions(+), 195 deletions(-)

-- 
1.9.1

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

Re: [ovs-dev] [PATCH] ovn-ctl: Add bootstrap ovn-controller CA certificate option.

[Lance Richardson]

> From: "Gurucharan Shetty" 
> To: d...@openvswitch.org
> Sent: Wednesday, January 18, 2017 6:25:29 AM
> Subject: [ovs-dev] [PATCH] ovn-ctl: Add bootstrap ovn-controller CA   
> certificate option.
> 
> ovn-controller accepts the option --bootstrap-ca-cert. With this
> commit, ovn-ctl will let user pass a value for that via
> --ovn-controller-ssl-bootstrap-ca-cert option.
> 
> Bootstrapping is useful for ovn-controller as you don't have to
> copy the controller's certificate (self-signed or otherwise) to every host.
> 
> Signed-off-by: Gurucharan Shetty 
> ---
LGTM (haven't tried it, but I'm planning to). Thanks for the enhancement
as well as the clean-ups.

It would be nice if this could go into the 2.7 branch as well.

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

Re: [ovs-dev] [PATCH 2/2] libX: add new release / version info tags

[Ben Pfaff]

On Mon, Jan 16, 2017 at 02:06:27PM -0500, Aaron Conole wrote:
> This commit uses the $PACKAGE_VERSION automake variable to construct a
> release and version info combination which sets the library name to be:
> 
>libfoo-$(OVS_MAJOR_VERSION).so.$(OVS_MINOR_VERSION).0.$(OVS_MICRO_VERSION)
> 
> where formerly, it was always:
> 
>libfoo.so.1.0.0
> 
> This allows releases of Open vSwitch libraries to reflect which specific
> versions they came with, and sets up a psuedo ABI-versioning scheme.  In
> this fashion, future releases of Open vSwitch could be installed
> alongside older releases, allowing 3rd party utilities linked against
> previous versions to continue to function.
> 
> ex:
> 
> $ ldd /path/to/utility
>   linux-vdso.so.1 (0x7ffe92cf6000)
>   libopenvswitch-2.so.6 => /lib64/libopenvswitch-2.so.6 
> (0x7f733b7a3000)
>   libssl.so.10 => /lib64/libssl.so.10 (0x7f733b53)
> ...
> 
> Note the library name and version information.
> 
> Signed-off-by: Aaron Conole 
> ---
> RFC to patch:
>   Incorporated feedback from Ben Pfaff
>   Introduced new RST Documentation describing ABI versioning

Thanks a lot!  I especially appreciate the documentation.

I applied this to master and branch-2.7.

I fixed a couple of "it's" vs. "its" errors in the documentation.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] ovn-ctl: Add bootstrap ovn-controller CA certificate option.

[Ben Pfaff]

On Wed, Jan 18, 2017 at 03:25:29AM -0800, Gurucharan Shetty wrote:
> ovn-controller accepts the option --bootstrap-ca-cert. With this
> commit, ovn-ctl will let user pass a value for that via
> --ovn-controller-ssl-bootstrap-ca-cert option.
> 
> Bootstrapping is useful for ovn-controller as you don't have to
> copy the controller's certificate (self-signed or otherwise) to every host.
> 
> Signed-off-by: Gurucharan Shetty 

I didn't test this, but the feature makes sense, so as long as it works:

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

Re: [ovs-dev] [PATCH 1/2] libX.pc: use the correct output directory

[Ben Pfaff]

On Mon, Jan 16, 2017 at 02:06:26PM -0500, Aaron Conole wrote:
> When the ovsdb library pkgconfig changes were introduced, they placed
> generated output in the src directory.  This is incorrect, however, as
> the output files should actually be placed in the build directory.  It
> is only seen when running `make distcheck` after enabling shared
> libraries (ex: `./configure --enable-shared`).
> 
> Fixes: commit e72e07a97e95 ("lib: Add support for pkgconfig for libovsdb.")
> Signed-off-by: Aaron Conole 
> ---
> RFC to patch:
>   Introduce this after catching the error while doing some testing.

This seems like an improvement, but is the $(builddir)/ prefix actually
necessary?  It's unusual for this to be required.

Thanks,

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

[ovs-dev] [PATCH] ovn-ctl: Add bootstrap ovn-controller CA certificate option.

[Gurucharan Shetty]

ovn-controller accepts the option --bootstrap-ca-cert. With this
commit, ovn-ctl will let user pass a value for that via
--ovn-controller-ssl-bootstrap-ca-cert option.

Bootstrapping is useful for ovn-controller as you don't have to
copy the controller's certificate (self-signed or otherwise) to every host.

Signed-off-by: Gurucharan Shetty 
---
 ovn/utilities/ovn-ctl   | 20 ++--
 ovn/utilities/ovn-ctl.8.xml |  1 +
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/ovn/utilities/ovn-ctl b/ovn/utilities/ovn-ctl
index 90d0463..a3bdad1 100755
--- a/ovn/utilities/ovn-ctl
+++ b/ovn/utilities/ovn-ctl
@@ -220,22 +220,36 @@ start_northd () {
 start_controller () {
 set ovn-controller "unix:$DB_SOCK"
 set "$@" $OVN_CONTROLLER_LOG
-if test X"$OVN_CONTROLLER_SSL_CERT" != X; then
+if test X"$OVN_CONTROLLER_SSL_KEY" != X; then
 set "$@" --private-key=$OVN_CONTROLLER_SSL_KEY
+fi
+if test X"$OVN_CONTROLLER_SSL_CERT" != X; then
 set "$@" --certificate=$OVN_CONTROLLER_SSL_CERT
+fi
+if test X"$OVN_CONTROLLER_SSL_CA_CERT" != X; then
 set "$@" --ca-cert=$OVN_CONTROLLER_SSL_CA_CERT
 fi
+if test X"$OVN_CONTROLLER_SSL_BOOTSTRAP_CA_CERT" != X; then
+set "$@" --bootstrap-ca-cert=$OVN_CONTROLLER_SSL_BOOTSTRAP_CA_CERT
+fi
 OVS_RUNDIR=${OVN_RUNDIR} start_daemon "$OVN_CONTROLLER_PRIORITY" 
"$OVN_CONTROLLER_WRAPPER" "$@"
 }
 
 start_controller_vtep () {
 set ovn-controller-vtep "unix:$DB_SOCK"
 set "$@" -vconsole:emer -vsyslog:err -vfile:info
-if test X"$OVN_CONTROLLER_SSL_CERT" != X; then
+if test X"$OVN_CONTROLLER_SSL_KEY" != X; then
 set "$@" --private-key=$OVN_CONTROLLER_SSL_KEY
+fi
+if test X"$OVN_CONTROLLER_SSL_CERT" != X; then
 set "$@" --certificate=$OVN_CONTROLLER_SSL_CERT
+fi
+if test X"$OVN_CONTROLLER_SSL_CA_CERT" != X; then
 set "$@" --ca-cert=$OVN_CONTROLLER_SSL_CA_CERT
 fi
+if test X"$OVN_CONTROLLER_SSL_BOOTSTRAP_CA_CERT" != X; then
+set "$@" --bootstrap-ca-cert=$OVN_CONTROLLER_SSL_BOOTSTRAP_CA_CERT
+fi
 OVS_RUNDIR=${OVN_RUNDIR} start_daemon "$OVN_CONTROLLER_PRIORITY" 
"$OVN_CONTROLLER_WRAPPER" "$@"
 }
 
@@ -335,6 +349,7 @@ set_defaults () {
 OVN_CONTROLLER_SSL_KEY=""
 OVN_CONTROLLER_SSL_CERT=""
 OVN_CONTROLLER_SSL_CA_CERT=""
+OVN_CONTROLLER_SSL_BOOTSTRAP_CA_CERT=""
 
 DB_SB_CREATE_INSECURE_REMOTE="no"
 DB_NB_CREATE_INSECURE_REMOTE="no"
@@ -384,6 +399,7 @@ Options:
   --ovn-controller-ssl-key=KEY OVN Southbound SSL private key file
   --ovn-controller-ssl-cert=CERT OVN Southbound SSL certificate file
   --ovn-controller-ssl-ca-cert=CERT OVN Southbound SSL CA certificate file
+  --ovn-controller-ssl-bootstrap-ca-cert=CERT Bootstrapped OVN Southbound SSL 
CA certificate file
   --ovn-manage-ovsdb=yes|noWhether or not the OVN databases should be
automatically started and stopped along
with ovn-northd. The default is "yes". If
diff --git a/ovn/utilities/ovn-ctl.8.xml b/ovn/utilities/ovn-ctl.8.xml
index c4884f8..7b090ae 100644
--- a/ovn/utilities/ovn-ctl.8.xml
+++ b/ovn/utilities/ovn-ctl.8.xml
@@ -48,6 +48,7 @@
 --ovn-controller-ssl-key=KEY
 --ovn-controller-ssl-cert=CERT
 --ovn-controller-ssl-ca-cert=CERT
+--ovn-controller-ssl-bootstrap-ca-cert=CERT
 
 Address and port options
 --db-nb-sync-from-addr=IP ADDRESS
-- 
1.9.1

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

Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames

[Joe Stringer]

On 18 January 2017 at 11:54, Eric Garver  wrote:
> On Tue, Jan 17, 2017 at 12:37:19AM +, Yang, Yi Y wrote:
>> What userspace do "802.1ad patches" depend on? Per Pravin's statement, we 
>> just backport 802.1ad patches to ovs, then the below patch can be applied to 
>> ovs.
>
> Userspace does not yet have support for 802.1ad. I'm still working on
> it. You can check the list archives for a recent RFC version.
>
> I don't know if it's acceptable to backport the datapath (kernel module)
> support before the userspace support is accepted. If not, you'll have to
> wait on the userspace.
> Perhaps Pravin can answer.

IMO the general method of:
1) Add support upstream
2) Add userspace support
3) Add backport

...works nicely because we get feedback for all interested parties for
the APIs in (1), (2) can add tests and be easily tested against a
version that works (upstream kernel) and a version that doesn't
(version in tree) to ensure both cases are handled in a reasonable
way, then (3) allows people on older kernels to gain access to the
newer features.

That said, if other people are blocking on (3) then I think that piece
should be expedited. Let's say (2) and (3) were swapped, it just means
we need to be a bit more careful when reviewing/testing to check that
the newer userspace still handles old kernels (that lack support)
fine.

The nice thing about getting the backport earlier is, the closer to
upstream we are, the sooner we may find issues that affect the latest
code.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [BUG] ovs-ofctl version 2.5.0 will crash with OFPFMFC_BAD_COMMAND

[Ben Pfaff]

If you can come up with simple reproduction instructions that work for
me, I'm happy to track this down.  It's probably something very simple.

On Tue, Jan 17, 2017 at 08:50:20AM -0800, Vidyasagara Guntaka wrote:
> This issue happened on our in-use systems and we were trying to find a way
> to move forward avoiding this issue so that we do not have to upgrade OVS
> on thousands of our hypervisors causing down time. Our debugging did help
> us avoid the issue for now by installing an explicit rule to to drop
> packets when there is no match and this issue is not seen over many hours
> of test runs.
> 
> We will definitely run this test with latest version.  But, will need more
> time since we are busy with our release related activities.
> 
> Regards,
> Sagar.
> 
> On Tue, Jan 17, 2017 at 8:42 AM, Ben Pfaff  wrote:
> 
> > It would be more helpful to have a simple reproduction case.
> >
> > Why haven't you tried a newer version from branch-2.5?
> >
> > On Tue, Jan 17, 2017 at 07:59:05AM -0800, Vidyasagara Guntaka wrote:
> > > Hi Ben,
> > >
> > > Here i is more debug information related to this incident (still using
> > version 2.5.0):
> > >
> > > Summary :
> > >
> > > We think that there is some race condition involved in processing OF
> > Controller connections and Packet miss processing in ovs-vswitchd.
> > >
> > > Reasoning :
> > >
> > > Please consider the following GDB Debug Session:
> > >
> > > Breakpoint 1, ofconn_set_protocol (ofconn=0x16d5810,
> > protocol=OFPUTIL_P_OF10_STD) at ofproto/connmgr.c:999
> > > (gdb) f 2
> > > #2  0x0045f586 in connmgr_wants_packet_in_on_miss
> > (mgr=0x16a6de0) at ofproto/connmgr.c:1613
> > > 1613  enum ofputil_protocol protocol =
> > ofconn_get_protocol(ofconn);
> > > (gdb) p *ofconn
> > > $2 = {node = {prev = 0x16a6e18, next = 0x16a6e18}, hmap_node = {hash =
> > 0, next = 0x0}, connmgr = 0x16a6de0, rconn = 0x16edb50, type =
> > OFCONN_SERVICE, band = OFPROTO_IN_BAND, enable_async_msgs = true,
> > >   role = OFPCR12_ROLE_EQUAL, protocol = OFPUTIL_P_OF10_STD_TID,
> > packet_in_format = NXPIF_OPENFLOW10, packet_in_counter = 0x167a170,
> > schedulers = {0x0, 0x0}, pktbuf = 0x0, miss_send_len = 0,
> > >   controller_id = 0, reply_counter = 0x1673190, master_async_config =
> > {3, 7, 7, 0, 0, 0}, slave_async_config = {0, 7, 0, 0, 0, 0}, n_add = 0,
> > n_delete = 0, n_modify = 0,
> > >   first_op = -9223372036854775808, last_op = -9223372036854775808,
> > next_op_report = 9223372036854775807, op_backoff = -9223372036854775808,
> > monitors = {buckets = 0x16d58f0, one = 0x0, mask = 0,
> > > n = 0}, monitor_paused = 0, monitor_counter = 0x16759f0, updates =
> > {prev = 0x16d5918, next = 0x16d5918}, sent_abbrev_update = false, bundles =
> > {buckets = 0x16d5938, one = 0x0, mask = 0, n = 0}}
> > > (gdb) bt
> > > #0  ofconn_set_protocol (ofconn=0x16d5810, protocol=OFPUTIL_P_OF10_STD)
> > at ofproto/connmgr.c:999
> > > #1  0x0045e194 in ofconn_get_protocol (ofconn=0x16d5810) at
> > ofproto/connmgr.c:982
> > > #2  0x0045f586 in connmgr_wants_packet_in_on_miss
> > (mgr=0x16a6de0) at ofproto/connmgr.c:1613
> > > #3  0x00435261 in rule_dpif_lookup_from_table
> > (ofproto=0x16a6880, version=323, flow=0x7f2ace7f86e8, wc=0x7f2ace7f84b0,
> > stats=0x0, table_id=0x7f2ace7f7eda "", in_port=28, may_packet_in=true,
> > > honor_table_miss=true) at ofproto/ofproto-dpif.c:3973
> > > #4  0x00457ecf in xlate_actions (xin=0x7f2ace7f86e0,
> > xout=0x7f2ace7f8010) at ofproto/ofproto-dpif-xlate.c:5188
> > > #5  0x004481b1 in revalidate_ukey (udpif=0x16a7300,
> > ukey=0x7f2ab80060e0, stats=0x7f2ace7f94e0, odp_actions=0x7f2ace7f8a40,
> > reval_seq=585728, recircs=0x7f2ace7f8a30)
> > > at ofproto/ofproto-dpif-upcall.c:1866
> > > #6  0x00448fb2 in revalidate (revalidator=0x1691990) at
> > ofproto/ofproto-dpif-upcall.c:2186
> > > #7  0x0044593e in udpif_revalidator (arg=0x1691990) at
> > ofproto/ofproto-dpif-upcall.c:862
> > > #8  0x0050b93d in ovsthread_wrapper (aux_=0x16f4560) at
> > lib/ovs-thread.c:340
> > > #9  0x7f2ad75c2184 in start_thread () from /lib/x86_64-linux-gnu/
> > libpthread.so.0
> > > #10 0x7f2ad6de137d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> > > (gdb) f 1
> > > #1  0x0045e194 in ofconn_get_protocol (ofconn=0x16d5810) at
> > ofproto/connmgr.c:982
> > > 982   ofconn_set_protocol(CONST_CAST(struct ofconn *,
> > ofconn),
> > > (gdb) l
> > > 977   {
> > > 978   if (ofconn->protocol == OFPUTIL_P_NONE &&
> > > 979   rconn_is_connected(ofconn->rconn)) {
> > > 980   int version = rconn_get_version(ofconn->rconn);
> > > 981   if (version > 0) {
> > > 982   ofconn_set_protocol(CONST_CAST(struct ofconn *,
> > ofconn),
> > > 983   ofputil_protocol_from_ofp_
> > version(version));
> > > 984   }
> > > 985   }
> > > 986
> > > (gdb) p *ofconn
> > > $3 = {node = {prev = 0x16a6e18, next = 0x16a6

Re: [ovs-dev] [RFC] ofproto/bond: operational vs administratively disabled bond interface

[Ben Pfaff]

On Wed, Jan 18, 2017 at 09:57:00AM +0100, Eelco Chaudron wrote:
> On 17/01/17 20:12, Ben Pfaff wrote:
> >On Tue, Jan 17, 2017 at 12:10:59PM -0200, Flavio Leitner wrote:
> >>On Tue, 17 Jan 2017 09:34:19 +0100
> >>Eelco Chaudron  wrote:
> >>
> >>>Currently OVS does not distinguish between a bond slave being operational
> >>>disabled, i.e. link being down, and administratively disabled.
> >>>
> >>>Take the example where the administrator disabled a link in a bond,
> >>>"ovs-appctl bond/disable-slave bond0 enp129s0f0", it's automatically
> >>>enabled again due to the fact the link is up.
> >>>
> >>>I would like to change this behavior such that when disabled trough appctl
> >>>the slave is no longer used until explicitly enabled again via appctl.
> >>Eelco and I discussed this off list and I agree that this sounds like
> >>a bug.  The slave should not be used if the admin has disabled it
> >>regardless of its link state.
> >The behavior matches the documentation:
> >
> >bond/enable-slave port slave
> >bond/disable-slave port slave
> >   Enables (or disables) slave on the given bond port, skipping 
> > any
> >   updelay (or downdelay).
> >
> >   This  setting  is not permanent: it persists only until the 
> > car‐
> >   rier status of slave changes.
> 
> So to administratively disable a link, you should either force the link to
> be down (and don't forget after system reboot), or remove the slave from the
> bond? If so, no re-work is needed here.

I guess that I would rather say that OVS does not currently have a
concept of a slave being administratively disabled while it is part of a
bond.  If it's useful to have such a concept, then I'm open to the
discussion.  Part of the discussion needs to be a rationale for why this
new concept is valuable, given the other possibilities that you mention.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan frames

[Eric Garver]

On Tue, Jan 17, 2017 at 12:37:19AM +, Yang, Yi Y wrote:
> What userspace do "802.1ad patches" depend on? Per Pravin's statement, we 
> just backport 802.1ad patches to ovs, then the below patch can be applied to 
> ovs.

Userspace does not yet have support for 802.1ad. I'm still working on
it. You can check the list archives for a recent RFC version.

I don't know if it's acceptable to backport the datapath (kernel module)
support before the userspace support is accepted. If not, you'll have to
wait on the userspace.
Perhaps Pravin can answer.

> commit df30f7408b187929dbde72661c7f7c615268f1d0
> Author: pravin shelar 
> Date:   Mon Dec 26 08:31:27 2016 -0800
> 
> openvswitch: upcall: Fix vlan handling.
> 
> -Original Message-
> From: Eric Garver [mailto:e...@erig.me] 
> Sent: Monday, January 16, 2017 11:01 PM
> To: Yang, Yi Y 
> Cc: Pravin Shelar ; Jan Scheurich ; 
> ovs dev 
> Subject: Re: [ovs-dev] [PATCH v2 14/17] datapath: Fix skb->protocol for vlan 
> frames
> 
> On Mon, Jan 16, 2017 at 02:26:55PM +, Yang, Yi Y wrote:
> > Hi, Eric
> > 
> > We hope Jiri's L3 patchset can be applied into current ovs because we and 
> > Ericsson guys are enabling packet_type support and PTAP & non-PTAP based on 
> > L3 patchset, Pravin said you're backporting your 802.1ad patches from 
> > net-next to ovs, we don't know when your patches can be posted in ovs-dev, 
> > I can help with this if you have no time.
> 
> I had replied to Pravin earlier in this thread.
> 
> I do intend to backport the kernel changes to the ovs out-of-tree module. I 
> was waiting until userspace was ready. Unfortunately that's not likely to 
> happen this week or even next.
> 
> If you have the time feel free to give it a go.
> 
> > -Original Message-
> > From: Pravin Shelar [mailto:pshe...@ovn.org]
> > Sent: Monday, January 9, 2017 5:33 PM
> > To: Yang, Yi Y ; Eric Garver 
> > Cc: ovs dev ; Jarno Rajahalme 
> > Subject: Re: [PATCH v2 14/17] datapath: Fix skb->protocol for vlan 
> > frames
> > 
> > On Tue, Jan 3, 2017 at 6:47 AM, Yang, Yi Y  wrote:
> > > Pravin, the issue is current ovs has too many differences from net-next 
> > > tree, the best way is to apply all the patches before your patch, but it 
> > > seems a super huge work, it is out of my capability :-) Anybody of you is 
> > > working on this?
> > >
> > 
> > First we need to get 802.1ad patches merged in OVS out of tree module.
> > Eric is working on 802.1ad support to OVS. I guess he will backport these 
> > patches to out of tree kernel module along with the userspace patches. That 
> > will cover majority of the remaining changes.
> > 
> > Thanks,
> > Pravin.
> > 
> > > -Original Message-
> > > From: Pravin Shelar [mailto:pshe...@ovn.org]
> > > Sent: Sunday, January 1, 2017 3:45 PM
> > > To: Yang, Yi Y 
> > > Cc: ovs dev ; Jarno Rajahalme 
> > > Subject: Re: [PATCH v2 14/17] datapath: Fix skb->protocol for vlan 
> > > frames
> > >
> > > On Wed, Dec 28, 2016 at 5:56 PM, Yi Yang  wrote:
> > >> Do not always set skb->protocol to be the ethertype of the L3 header.
> > >> For a packet with non-accelerated VLAN tags skb->protocol needs to be 
> > >> the ethertype of the outermost non-accelerated VLAN ethertype.
> > >>
> > >> Any VLAN offloading is undone on the OVS netlink interface, and any VLAN 
> > >> tags added by userspace are non-accelerated, as are double tagged VLAN 
> > >> packets.
> > >>
> > >> Fixes: 018c1dda5f ("openvswitch: 802.1AD Flow handling, actions, 
> > >> vlan parsing, netlink attributes")
> > >> Fixes: 5108bbaddc ("openvswitch: add processing of L3 packets")
> > >> Signed-off-by: Jarno Rajahalme 
> > >> Signed-off-by: Yi Yang 
> > > This is not upstream patch. So even though it fixes the issue we can not 
> > > apply it to out of tree kernel module.
> > >
> > > Can you look at the net branch for the correct patch.
> > >
> > > Thanks.
> > ___
> > 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

[ovs-dev] [RFC PATCH v4 1/6] netdev: get device type from vport prefix if it uses one

[Eric Garver]

From: Thadeu Lima de Souza Cascardo 

If the device name uses a vport prefix, then use that vport type.

Since these names are reserved, we can assume this is the right type.

This is important when we are querying the datapath right after vswitch has
started and using the right type will be even more important when we add support
to creating tunnel ports with rtnetlink.

Signed-off-by: Thadeu Lima de Souza Cascardo 
---
 lib/netdev.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/lib/netdev.c b/lib/netdev.c
index 839b1f633edc..d3d19b57cd21 100644
--- a/lib/netdev.c
+++ b/lib/netdev.c
@@ -288,6 +288,21 @@ netdev_enumerate_types(struct sset *types)
 }
 }
 
+static const char *
+netdev_vport_type_from_name(const char *name)
+{
+struct netdev_registered_class *rc;
+const char *type;
+CMAP_FOR_EACH (rc, cmap_node, &netdev_classes) {
+const char *dpif_port = netdev_vport_class_get_dpif_port(rc->class);
+if (dpif_port && !strncmp(name, dpif_port, strlen(dpif_port))) {
+type = rc->class->type;
+return type;
+}
+}
+return NULL;
+}
+
 /* Check that the network device name is not the same as any of the registered
  * vport providers' dpif_port name (dpif_port is NULL if the vport provider
  * does not define it) or the datapath internal port name (e.g. ovs-system).
@@ -1805,9 +1820,14 @@ netdev_get_vports(size_t *size)
 const char *
 netdev_get_type_from_name(const char *name)
 {
-struct netdev *dev = netdev_from_name(name);
-const char *type = dev ? netdev_get_type(dev) : NULL;
-netdev_close(dev);
+struct netdev *dev;
+const char *type;
+type = netdev_vport_type_from_name(name);
+if (type == NULL) {
+dev = netdev_from_name(name);
+type = dev ? netdev_get_type(dev) : NULL;
+netdev_close(dev);
+}
 return type;
 }
 
-- 
2.10.0

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

[ovs-dev] [RFC PATCH v4 6/6] dpif-netlink: add GENEVE creation support

[Eric Garver]

Creates GENEVE devices using rtnetlink and tunnel metadata.

Co-Authored-by: Thadeu Lima de Souza Cascardo 
Co-Authored-by: Eric Garver 
Signed-off-by: Eric Garver 
---
 lib/dpif-netlink.c | 140 +
 1 file changed, 140 insertions(+)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index f4ff6f516e75..95d70a429367 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -987,6 +987,12 @@ netdev_gre_destroy(const char *name)
 return netdev_linux_destroy(name);
 }
 
+static int
+netdev_geneve_destroy(const char *name)
+{
+return netdev_linux_destroy(name);
+}
+
 /*
  * On some older systems, these enums are not defined.
  */
@@ -1005,6 +1011,18 @@ netdev_gre_destroy(const char *name)
 #define IFLA_GRE_COLLECT_METADATA 18
 #endif
 
+#ifndef IFLA_GENEVE_MAX
+#define IFLA_GENEVE_MAX 0
+#define IFLA_GENEVE_PORT 5
+#endif
+
+#if IFLA_GENEVE_MAX < 6
+#define IFLA_GENEVE_COLLECT_METADATA 6
+#endif
+#if IFLA_GENEVE_MAX < 10
+#define IFLA_GENEVE_UDP_ZERO_CSUM6_RX 10
+#endif
+
 static const struct nl_policy rtlink_policy[] = {
 [IFLA_LINKINFO] = { .type = NL_A_NESTED },
 };
@@ -1229,6 +1247,114 @@ netdev_gre_create(struct netdev *netdev)
 return netdev_gre_create_kind(netdev, "gretap");
 }
 
+static int
+netdev_geneve_verify(struct netdev *netdev, const char *name, const char *kind)
+{
+int err;
+struct ofpbuf request, *reply;
+struct ifinfomsg *ifmsg;
+const struct netdev_tunnel_config *tnl_cfg;
+
+static const struct nl_policy geneve_policy[] = {
+[IFLA_GENEVE_COLLECT_METADATA] = { .type = NL_A_FLAG },
+[IFLA_GENEVE_UDP_ZERO_CSUM6_RX] = { .type = NL_A_U8 },
+[IFLA_GENEVE_PORT] = { .type = NL_A_U16 },
+};
+
+tnl_cfg = netdev_get_tunnel_config(netdev);
+if (!tnl_cfg) {
+return EINVAL;
+}
+
+ofpbuf_init(&request, 0);
+nl_msg_put_nlmsghdr(&request, 0, RTM_GETLINK,
+NLM_F_REQUEST);
+ofpbuf_put_zeros(&request, sizeof(struct ifinfomsg));
+nl_msg_put_string(&request, IFLA_IFNAME, name);
+
+err = nl_transact(NETLINK_ROUTE, &request, &reply);
+if (!err) {
+struct nlattr *rtlink[ARRAY_SIZE(rtlink_policy)];
+struct nlattr *linkinfo[ARRAY_SIZE(linkinfo_policy)];
+struct nlattr *geneve[ARRAY_SIZE(geneve_policy)];
+
+ifmsg = ofpbuf_at(reply, NLMSG_HDRLEN, sizeof *ifmsg);
+if (!nl_policy_parse(reply, NLMSG_HDRLEN + sizeof *ifmsg,
+ rtlink_policy, rtlink,
+ ARRAY_SIZE(rtlink_policy)) ||
+!nl_parse_nested(rtlink[IFLA_LINKINFO], linkinfo_policy,
+ linkinfo, ARRAY_SIZE(linkinfo_policy)) ||
+strcmp(nl_attr_get_string(linkinfo[IFLA_INFO_KIND]), kind) ||
+!nl_parse_nested(linkinfo[IFLA_INFO_DATA], geneve_policy, geneve,
+ ARRAY_SIZE(geneve_policy))) {
+err = EINVAL;
+}
+if (!err) {
+if (!nl_attr_get_flag(geneve[IFLA_GENEVE_COLLECT_METADATA]) ||
+1 != nl_attr_get_u8(geneve[IFLA_GENEVE_UDP_ZERO_CSUM6_RX]) ||
+tnl_cfg->dst_port !=
+nl_attr_get_u16(geneve[IFLA_GENEVE_PORT])) {
+err = EINVAL;
+}
+}
+ofpbuf_uninit(reply);
+}
+ofpbuf_uninit(&request);
+return err;
+}
+
+static int
+netdev_geneve_create_kind(struct netdev *netdev, const char *kind)
+{
+int err;
+struct ofpbuf request, *reply;
+size_t linkinfo_off, infodata_off;
+char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
+const char *name = netdev_vport_get_dpif_port(netdev,
+  namebuf, sizeof namebuf);
+struct ifinfomsg *ifinfo;
+const struct netdev_tunnel_config *tnl_cfg;
+tnl_cfg = netdev_get_tunnel_config(netdev);
+if (!tnl_cfg) {
+return EINVAL;
+}
+
+ofpbuf_init(&request, 0);
+nl_msg_put_nlmsghdr(&request, 0, RTM_NEWLINK,
+NLM_F_REQUEST | NLM_F_ACK | NLM_F_CREATE);
+ifinfo = ofpbuf_put_zeros(&request, sizeof(struct ifinfomsg));
+ifinfo->ifi_change = ifinfo->ifi_flags = IFF_UP;
+nl_msg_put_string(&request, IFLA_IFNAME, name);
+nl_msg_put_u32(&request, IFLA_MTU, UINT16_MAX);
+linkinfo_off = nl_msg_start_nested(&request, IFLA_LINKINFO);
+nl_msg_put_string(&request, IFLA_INFO_KIND, kind);
+infodata_off = nl_msg_start_nested(&request, IFLA_INFO_DATA);
+nl_msg_put_flag(&request, IFLA_GENEVE_COLLECT_METADATA);
+nl_msg_put_u8(&request, IFLA_GENEVE_UDP_ZERO_CSUM6_RX, 1);
+nl_msg_put_be16(&request, IFLA_GENEVE_PORT, tnl_cfg->dst_port);
+nl_msg_end_nested(&request, infodata_off);
+nl_msg_end_nested(&request, linkinfo_off);
+
+err = nl_transact(NETLINK_ROUTE, &request, &reply);
+
+if (!err) {
+ofpbuf_uninit(reply);
+}
+
+if (!err && (err = netdev_geneve_ver

[ovs-dev] [RFC PATCH v4 5/6] dpif-netlink: add GRE creation support

[Eric Garver]

Creates GRE devices using rtnetlink and tunnel metadata.

Co-Authored-by: Thadeu Lima de Souza Cascardo 
Co-Authored-by: Eric Garver 
Signed-off-by: Eric Garver 
---
 lib/dpif-netlink.c | 121 +
 1 file changed, 121 insertions(+)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 3aeb8480aa48..f4ff6f516e75 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -980,6 +981,12 @@ netdev_vxlan_destroy(const char *name)
 return netdev_linux_destroy(name);
 }
 
+static int
+netdev_gre_destroy(const char *name)
+{
+return netdev_linux_destroy(name);
+}
+
 /*
  * On some older systems, these enums are not defined.
  */
@@ -994,6 +1001,10 @@ netdev_vxlan_destroy(const char *name)
 #define IFLA_VXLAN_COLLECT_METADATA 25
 #endif
 
+#if IFLA_GRE_MAX < 18
+#define IFLA_GRE_COLLECT_METADATA 18
+#endif
+
 static const struct nl_policy rtlink_policy[] = {
 [IFLA_LINKINFO] = { .type = NL_A_NESTED },
 };
@@ -1122,6 +1133,102 @@ netdev_vxlan_create(struct netdev *netdev)
 return netdev_vxlan_create_kind(netdev, "vxlan");
 }
 
+static int
+netdev_gre_verify(struct netdev *netdev OVS_UNUSED, const char *name,
+  const char *kind)
+{
+int err;
+struct ofpbuf request, *reply;
+struct ifinfomsg *ifmsg;
+
+static const struct nl_policy gre_policy[] = {
+[IFLA_GRE_COLLECT_METADATA] = { .type = NL_A_FLAG },
+};
+
+ofpbuf_init(&request, 0);
+nl_msg_put_nlmsghdr(&request, 0, RTM_GETLINK,
+NLM_F_REQUEST);
+ofpbuf_put_zeros(&request, sizeof(struct ifinfomsg));
+nl_msg_put_string(&request, IFLA_IFNAME, name);
+
+err = nl_transact(NETLINK_ROUTE, &request, &reply);
+if (!err) {
+struct nlattr *rtlink[ARRAY_SIZE(rtlink_policy)];
+struct nlattr *linkinfo[ARRAY_SIZE(linkinfo_policy)];
+struct nlattr *gre[ARRAY_SIZE(gre_policy)];
+
+ifmsg = ofpbuf_at(reply, NLMSG_HDRLEN, sizeof *ifmsg);
+if (!nl_policy_parse(reply, NLMSG_HDRLEN + sizeof *ifmsg,
+ rtlink_policy, rtlink,
+ ARRAY_SIZE(rtlink_policy)) ||
+!nl_parse_nested(rtlink[IFLA_LINKINFO], linkinfo_policy,
+ linkinfo, ARRAY_SIZE(linkinfo_policy)) ||
+strcmp(nl_attr_get_string(linkinfo[IFLA_INFO_KIND]), kind) ||
+!nl_parse_nested(linkinfo[IFLA_INFO_DATA], gre_policy, gre,
+ ARRAY_SIZE(gre_policy))) {
+err = EINVAL;
+}
+if (!err) {
+if (!nl_attr_get_flag(gre[IFLA_GRE_COLLECT_METADATA])) {
+err = EINVAL;
+}
+}
+ofpbuf_uninit(reply);
+}
+ofpbuf_uninit(&request);
+return err;
+}
+
+static int
+netdev_gre_create_kind(struct netdev *netdev, const char *kind)
+{
+int err;
+struct ofpbuf request, *reply;
+size_t linkinfo_off, infodata_off;
+char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
+const char *name = netdev_vport_get_dpif_port(netdev,
+  namebuf, sizeof namebuf);
+struct ifinfomsg *ifinfo;
+const struct netdev_tunnel_config *tnl_cfg;
+tnl_cfg = netdev_get_tunnel_config(netdev);
+if (!tnl_cfg) {
+return EINVAL;
+}
+
+ofpbuf_init(&request, 0);
+nl_msg_put_nlmsghdr(&request, 0, RTM_NEWLINK,
+NLM_F_REQUEST | NLM_F_ACK | NLM_F_CREATE);
+ifinfo = ofpbuf_put_zeros(&request, sizeof(struct ifinfomsg));
+ifinfo->ifi_change = ifinfo->ifi_flags = IFF_UP;
+nl_msg_put_string(&request, IFLA_IFNAME, name);
+nl_msg_put_u32(&request, IFLA_MTU, UINT16_MAX);
+linkinfo_off = nl_msg_start_nested(&request, IFLA_LINKINFO);
+nl_msg_put_string(&request, IFLA_INFO_KIND, kind);
+infodata_off = nl_msg_start_nested(&request, IFLA_INFO_DATA);
+nl_msg_put_flag(&request, IFLA_GRE_COLLECT_METADATA);
+nl_msg_end_nested(&request, infodata_off);
+nl_msg_end_nested(&request, linkinfo_off);
+
+err = nl_transact(NETLINK_ROUTE, &request, &reply);
+
+if (!err) {
+ofpbuf_uninit(reply);
+}
+
+if (!err && (err = netdev_gre_verify(netdev, name, kind))) {
+netdev_gre_destroy(name);
+}
+
+ofpbuf_uninit(&request);
+return err;
+}
+
+static int
+netdev_gre_create(struct netdev *netdev)
+{
+return netdev_gre_create_kind(netdev, "gretap");
+}
+
 #else
 
 static int
@@ -1131,11 +1238,23 @@ netdev_vxlan_create(struct netdev *netdev OVS_UNUSED)
 }
 
 static int
+netdev_gre_create(struct netdev *netdev OVS_UNUSED)
+{
+return EOPNOTSUPP;
+}
+
+static int
 netdev_vxlan_destroy(const char *name OVS_UNUSED)
 {
 return EOPNOTSUPP;
 }
 
+static int
+netdev_gre_destroy(const char *name OVS_UNUSED)
+{
+return EOPNOTSUPP;
+}
+
 #endif
 
 static int
@@ -1149,6 +1268,7 @@ dpif_netl

[ovs-dev] [RFC PATCH v4 4/6] dpif-netlink: add VXLAN creation support

[Eric Garver]

Creates VXLAN devices using rtnetlink and tunnel metadata.

Co-Authored-by: Thadeu Lima de Souza Cascardo 
Co-Authored-by: Eric Garver 
Signed-off-by: Eric Garver 
---
 lib/dpif-netlink.c | 194 -
 1 file changed, 193 insertions(+), 1 deletion(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 769806eadbf1..3aeb8480aa48 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -24,7 +24,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -948,6 +950,194 @@ dpif_netlink_port_add_compat(struct dpif_netlink *dpif, 
struct netdev *netdev,
 
 }
 
+#ifdef __linux__
+
+static int
+netdev_linux_destroy(const char *name)
+{
+int err;
+struct ofpbuf request, *reply;
+
+ofpbuf_init(&request, 0);
+nl_msg_put_nlmsghdr(&request, 0, RTM_DELLINK,
+NLM_F_REQUEST | NLM_F_ACK);
+ofpbuf_put_zeros(&request, sizeof(struct ifinfomsg));
+nl_msg_put_string(&request, IFLA_IFNAME, name);
+
+err = nl_transact(NETLINK_ROUTE, &request, &reply);
+
+if (!err) {
+ofpbuf_uninit(reply);
+}
+
+ofpbuf_uninit(&request);
+return err;
+}
+
+static int
+netdev_vxlan_destroy(const char *name)
+{
+return netdev_linux_destroy(name);
+}
+
+/*
+ * On some older systems, these enums are not defined.
+ */
+
+#ifndef IFLA_VXLAN_MAX
+#define IFLA_VXLAN_MAX 0
+#define IFLA_VXLAN_PORT 15
+#endif
+#if IFLA_VXLAN_MAX < 20
+#define IFLA_VXLAN_UDP_ZERO_CSUM6_RX 20
+#define IFLA_VXLAN_GBP 23
+#define IFLA_VXLAN_COLLECT_METADATA 25
+#endif
+
+static const struct nl_policy rtlink_policy[] = {
+[IFLA_LINKINFO] = { .type = NL_A_NESTED },
+};
+static const struct nl_policy linkinfo_policy[] = {
+[IFLA_INFO_KIND] = { .type = NL_A_STRING },
+[IFLA_INFO_DATA] = { .type = NL_A_NESTED },
+};
+
+static int
+netdev_vxlan_verify(struct netdev *netdev, const char *name, const char *kind)
+{
+int err;
+struct ofpbuf request, *reply;
+struct ifinfomsg *ifmsg;
+const struct netdev_tunnel_config *tnl_cfg;
+
+static const struct nl_policy vxlan_policy[] = {
+[IFLA_VXLAN_COLLECT_METADATA] = { .type = NL_A_U8 },
+[IFLA_VXLAN_LEARNING] = { .type = NL_A_U8 },
+[IFLA_VXLAN_UDP_ZERO_CSUM6_RX] = { .type = NL_A_U8 },
+[IFLA_VXLAN_PORT] = { .type = NL_A_U16 },
+};
+
+tnl_cfg = netdev_get_tunnel_config(netdev);
+if (!tnl_cfg) {
+return EINVAL;
+}
+
+ofpbuf_init(&request, 0);
+nl_msg_put_nlmsghdr(&request, 0, RTM_GETLINK,
+NLM_F_REQUEST);
+ofpbuf_put_zeros(&request, sizeof(struct ifinfomsg));
+nl_msg_put_string(&request, IFLA_IFNAME, name);
+
+err = nl_transact(NETLINK_ROUTE, &request, &reply);
+if (!err) {
+struct nlattr *rtlink[ARRAY_SIZE(rtlink_policy)];
+struct nlattr *linkinfo[ARRAY_SIZE(linkinfo_policy)];
+struct nlattr *vxlan[ARRAY_SIZE(vxlan_policy)];
+
+ifmsg = ofpbuf_at(reply, NLMSG_HDRLEN, sizeof *ifmsg);
+if (!nl_policy_parse(reply, NLMSG_HDRLEN + sizeof *ifmsg,
+ rtlink_policy, rtlink,
+ ARRAY_SIZE(rtlink_policy)) ||
+!nl_parse_nested(rtlink[IFLA_LINKINFO], linkinfo_policy,
+ linkinfo, ARRAY_SIZE(linkinfo_policy)) ||
+strcmp(nl_attr_get_string(linkinfo[IFLA_INFO_KIND]), kind) ||
+!nl_parse_nested(linkinfo[IFLA_INFO_DATA], vxlan_policy, vxlan,
+ ARRAY_SIZE(vxlan_policy))) {
+err = EINVAL;
+}
+if (!err) {
+if (0 != nl_attr_get_u8(vxlan[IFLA_VXLAN_LEARNING]) ||
+1 != nl_attr_get_u8(vxlan[IFLA_VXLAN_COLLECT_METADATA]) ||
+1 != nl_attr_get_u8(vxlan[IFLA_VXLAN_UDP_ZERO_CSUM6_RX]) ||
+tnl_cfg->dst_port != nl_attr_get_u16(vxlan[IFLA_VXLAN_PORT])) {
+err = EINVAL;
+}
+}
+if (!err) {
+if ((tnl_cfg->exts & (1 << OVS_VXLAN_EXT_GBP)) &&
+!(vxlan[IFLA_VXLAN_GBP] &&
+  nl_attr_get_flag(vxlan[IFLA_VXLAN_GBP]))) {
+err = EINVAL;
+}
+}
+ofpbuf_uninit(reply);
+}
+ofpbuf_uninit(&request);
+return err;
+}
+
+static int
+netdev_vxlan_create_kind(struct netdev *netdev, const char *kind)
+{
+int err;
+struct ofpbuf request, *reply;
+size_t linkinfo_off, infodata_off;
+char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
+const char *name = netdev_vport_get_dpif_port(netdev,
+  namebuf, sizeof namebuf);
+struct ifinfomsg *ifinfo;
+const struct netdev_tunnel_config *tnl_cfg;
+tnl_cfg = netdev_get_tunnel_config(netdev);
+if (!tnl_cfg) {
+return EINVAL;
+}
+
+ofpbuf_init(&request, 0);
+nl_msg_put_nlmsghdr(&request, 0, RTM_NEWLINK,
+NLM_F_REQUEST | NLM

[ovs-dev] [RFC PATCH v4 2/6] dpif-netlink: break out code to add compat and non-compat vports

[Eric Garver]

From: Thadeu Lima de Souza Cascardo 

The vport type for adding tunnels is now compatibility code and any new features
from tunnels must configure the tunnel as an interface using the tunnel metadata
support.

In order to be able to add those tunnels, we need to add code to create the
tunnels and add them as NETDEV vports. And when there is no support to create
them, we need to use the compatibility code and add them as tunnel vports.

When removing those tunnels, we need to remove the interfaces as well, and
detecting the right type might be important, at least to distinguish the tunnel
vports that we should remove and the interfaces that we shouldn't.

Signed-off-by: Thadeu Lima de Souza Cascardo 
---
 lib/dpif-netlink.c | 201 +++--
 1 file changed, 148 insertions(+), 53 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index c8b0e37f9365..e6459f358989 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -781,10 +781,8 @@ get_vport_type(const struct dpif_netlink_vport *vport)
 }
 
 static enum ovs_vport_type
-netdev_to_ovs_vport_type(const struct netdev *netdev)
+netdev_to_ovs_vport_type(const char *type)
 {
-const char *type = netdev_get_type(netdev);
-
 if (!strcmp(type, "tap") || !strcmp(type, "system")) {
 return OVS_VPORT_TYPE_NETDEV;
 } else if (!strcmp(type, "internal")) {
@@ -805,19 +803,14 @@ netdev_to_ovs_vport_type(const struct netdev *netdev)
 }
 
 static int
-dpif_netlink_port_add__(struct dpif_netlink *dpif, struct netdev *netdev,
+dpif_netlink_port_add__(struct dpif_netlink *dpif, const char *name,
+enum ovs_vport_type type,
+struct ofpbuf *options,
 odp_port_t *port_nop)
 OVS_REQ_WRLOCK(dpif->upcall_lock)
 {
-const struct netdev_tunnel_config *tnl_cfg;
-char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
-const char *name = netdev_vport_get_dpif_port(netdev,
-  namebuf, sizeof namebuf);
-const char *type = netdev_get_type(netdev);
 struct dpif_netlink_vport request, reply;
 struct ofpbuf *buf;
-uint64_t options_stub[64 / 8];
-struct ofpbuf options;
 struct nl_sock **socksp = NULL;
 uint32_t *upcall_pids;
 int error = 0;
@@ -832,17 +825,80 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif, struct 
netdev *netdev,
 dpif_netlink_vport_init(&request);
 request.cmd = OVS_VPORT_CMD_NEW;
 request.dp_ifindex = dpif->dp_ifindex;
-request.type = netdev_to_ovs_vport_type(netdev);
-if (request.type == OVS_VPORT_TYPE_UNSPEC) {
+request.type = type;
+request.name = name;
+
+request.port_no = *port_nop;
+upcall_pids = vport_socksp_to_pids(socksp, dpif->n_handlers);
+request.n_upcall_pids = socksp ? dpif->n_handlers : 1;
+request.upcall_pids = upcall_pids;
+
+if (options) {
+request.options = options->data;
+request.options_len = options->size;
+}
+
+error = dpif_netlink_vport_transact(&request, &reply, &buf);
+if (!error) {
+*port_nop = reply.port_no;
+} else {
+if (error == EBUSY && *port_nop != ODPP_NONE) {
+VLOG_INFO("%s: requested port %"PRIu32" is in use",
+  dpif_name(&dpif->dpif), *port_nop);
+}
+
+vport_del_socksp(dpif, socksp);
+goto exit;
+}
+
+if (socksp) {
+error = vport_add_channels(dpif, *port_nop, socksp);
+if (error) {
+VLOG_INFO("%s: could not add channel for port %s",
+  dpif_name(&dpif->dpif), name);
+
+/* Delete the port. */
+dpif_netlink_vport_init(&request);
+request.cmd = OVS_VPORT_CMD_DEL;
+request.dp_ifindex = dpif->dp_ifindex;
+request.port_no = *port_nop;
+dpif_netlink_vport_transact(&request, NULL, NULL);
+vport_del_socksp(dpif, socksp);
+goto exit;
+}
+}
+free(socksp);
+
+exit:
+ofpbuf_delete(buf);
+free(upcall_pids);
+
+return error;
+}
+
+static int
+dpif_netlink_port_add_compat(struct dpif_netlink *dpif, struct netdev *netdev,
+ odp_port_t *port_nop)
+OVS_REQ_WRLOCK(dpif->upcall_lock)
+{
+const struct netdev_tunnel_config *tnl_cfg;
+char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
+const char *name = netdev_vport_get_dpif_port(netdev,
+  namebuf, sizeof namebuf);
+const char *type = netdev_get_type(netdev);
+uint64_t options_stub[64 / 8];
+struct ofpbuf options;
+enum ovs_vport_type ovs_type;
+
+ovs_type = netdev_to_ovs_vport_type(netdev_get_type(netdev));
+if (ovs_type == OVS_VPORT_TYPE_UNSPEC) {
 VLOG_WARN_RL(&error_rl, "%s: cannot create port `%s' because it has "
  "unsupported type `%s'",
  dpif_name(&dpif->dpif), name, type);
-vport

[ovs-dev] [RFC PATCH v4 3/6] dpif-netlink: Probe for out-of-tree datapath.

[Eric Garver]

For out-of-tree datapath, only try genetlink/compat.
For in-tree kernel datapath, try rtnetlink then genetlink.

Signed-off-by: Eric Garver 
---
 lib/dpif-netlink.c | 35 ---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index e6459f358989..769806eadbf1 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c
@@ -210,6 +210,11 @@ static int ovs_packet_family;
  * Initialized by dpif_netlink_init(). */
 static unsigned int ovs_vport_mcgroup;
 
+/* rtnetlink information for OVS.
+ *
+ * Initialized by dpif_netlink_init(). */
+static bool ovs_datapath_out_of_tree = false;
+
 static int dpif_netlink_init(void);
 static int open_dpif(const struct dpif_netlink_dp *, struct dpif **);
 static uint32_t dpif_netlink_port_get_pid(const struct dpif *,
@@ -1014,11 +1019,13 @@ dpif_netlink_port_add(struct dpif *dpif_, struct netdev 
*netdev,
   odp_port_t *port_nop)
 {
 struct dpif_netlink *dpif = dpif_netlink_cast(dpif_);
-int error;
+int error = EOPNOTSUPP;
 
 fat_rwlock_wrlock(&dpif->upcall_lock);
-error = dpif_netlink_port_create_and_add(dpif, netdev, port_nop);
-if (error == EOPNOTSUPP) {
+if (!ovs_datapath_out_of_tree) {
+error = dpif_netlink_port_create_and_add(dpif, netdev, port_nop);
+}
+if (error) {
 error = dpif_netlink_port_add_compat(dpif, netdev, port_nop);
 }
 fat_rwlock_unlock(&dpif->upcall_lock);
@@ -2503,6 +2510,7 @@ dpif_netlink_init(void)
 {
 static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
 static int error;
+struct netdev *netdev = NULL;
 
 if (ovsthread_once_start(&once)) {
 error = nl_lookup_genl_family(OVS_DATAPATH_FAMILY,
@@ -2526,6 +2534,27 @@ dpif_netlink_init(void)
 error = nl_lookup_genl_mcgroup(OVS_VPORT_FAMILY, OVS_VPORT_MCGROUP,
&ovs_vport_mcgroup);
 }
+#ifdef __linux__
+if (!error) {
+error = netdev_open("ovs-system-probe", "geneve", &netdev);
+if (!error) {
+error = netdev_geneve_create_kind(netdev, "ovs_geneve");
+if (error != EOPNOTSUPP) {
+if (!error) {
+char namebuf[NETDEV_VPORT_NAME_BUFSIZE];
+const char *dp_port;
+
+dp_port = netdev_vport_get_dpif_port(netdev, namebuf,
+ sizeof namebuf);
+netdev_geneve_destroy(dp_port);
+}
+ovs_datapath_out_of_tree = true;
+}
+netdev_close(netdev);
+error = 0;
+}
+}
+#endif
 
 ovsthread_once_done(&once);
 }
-- 
2.10.0

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

[ovs-dev] [RFC PATCH v4 0/6] create tunnel devices using rtnetlink interface

[Eric Garver]

This series adds support for the creation of tunnels using the rtnetlink
interface. This will open the possibility for new features and flags on those
vports without the need to change vport compatibility code.

Support for STT and LISP have not been added because these are not upstream yet,
so we don't know how the interface will be like upstream. And there are no
features in the current drivers right now we could make use of.

Note: This work originally started by Thadeu Lima de Souza Cascardo.

Testing:
  - kernel 4.9.3, in-tree datapath
- rtnetlink successfully creates devices
  - kernel 4.2.8, in-tree datapath
- rtnetlink is tried, but fails due to no COLLECT_METADATA support
- genetlink successfully creates devices
  - kernel 4.2.8, out-of-tree datapath
- rtnetlink is not tried
- genetlink successfully creates devices

v2:

We are able to set the MTU to UINT16_MAX since it is not restricted by the
driver during newlink.

v3:

Prefer to get type from vport before checking if device is opened. Also, disable
IFLA_VXLAN_LEARNING as it's not enabled on compat vports as well.

v4:
  - Probe for ovs_geneve on init, this indicates out-of-tree datapath
- If exists, only try genetlink/compat
- else, try rtnetlink and fallback to genetlink/compat
  - Read back and verify devices created with rtnetlink
  - checkpatch fixes

Eric Garver (4):
  dpif-netlink: Probe for out-of-tree datapath.
  dpif-netlink: add VXLAN creation support
  dpif-netlink: add GRE creation support
  dpif-netlink: add GENEVE creation support

Thadeu Lima de Souza Cascardo (2):
  netdev: get device type from vport prefix if it uses one
  dpif-netlink: break out code to add compat and non-compat vports

 lib/dpif-netlink.c | 679 +
 lib/netdev.c   |  26 +-
 2 files changed, 651 insertions(+), 54 deletions(-)

-- 
2.10.0

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

[ovs-dev] [PATCH] lacp: add test step for link recovery

[Shu Shen]

An additional step is added to test case "lacp - negotiation" to
ensure the bond port and its slave interfaces properly re-negotiate
after a link previously down comes back.

Signed-off-by: Shu Shen 
---
 tests/lacp.at | 136 ++
 1 file changed, 136 insertions(+)

diff --git a/tests/lacp.at b/tests/lacp.at
index 2394a955e..8f78e79f5 100644
--- a/tests/lacp.at
+++ b/tests/lacp.at
@@ -579,5 +579,141 @@ slave p3: enabled
may_enable: true
 
 ])
+
+# Reconnect the patch link between p0 and p2 to allow traffic between the 
ports.
+AT_CHECK([ovs-vsctl \
+-- del-port null0 -- set int p2 options:peer=p0 \
+-- del-port null1 -- set int p0 options:peer=p2])
+
+# Wait for 30 more seconds (LACP_SLOW_TIME_TX) for the lacp to renegotiate
+ovs-appctl time/warp 30100 100
+
+AT_CHECK(
+  [ovs-appctl lacp/show bond0
+ovs-appctl lacp/show bond1
+ovs-appctl bond/show bond0 | STRIP_RECIRC_ID | STRIP_ACTIVE_SLAVE_MAC
+ovs-appctl bond/show bond1 | STRIP_RECIRC_ID | STRIP_ACTIVE_SLAVE_MAC ], [0], 
[dnl
+ bond0 
+   status: active negotiated
+   sys_id: aa:55:aa:55:00:00
+   sys_priority: 65534
+   aggregation key: 2
+   lacp_time: fast
+
+slave: p0: current attached
+   port_id: 1
+   port_priority: 65535
+   may_enable: true
+
+   actor sys_id: aa:55:aa:55:00:00
+   actor sys_priority: 65534
+   actor port_id: 1
+   actor port_priority: 65535
+   actor key: 2
+   actor state: activity timeout aggregation synchronized collecting 
distributing
+
+   partner sys_id: aa:66:aa:66:00:00
+   partner sys_priority: 65534
+   partner port_id: 3
+   partner port_priority: 65535
+   partner key: 4
+   partner state: activity timeout aggregation synchronized collecting 
distributing
+
+slave: p1: current attached
+   port_id: 2
+   port_priority: 65535
+   may_enable: true
+
+   actor sys_id: aa:55:aa:55:00:00
+   actor sys_priority: 65534
+   actor port_id: 2
+   actor port_priority: 65535
+   actor key: 2
+   actor state: activity timeout aggregation synchronized collecting 
distributing
+
+   partner sys_id: aa:66:aa:66:00:00
+   partner sys_priority: 65534
+   partner port_id: 4
+   partner port_priority: 65535
+   partner key: 4
+   partner state: activity timeout aggregation synchronized collecting 
distributing
+ bond1 
+   status: active negotiated
+   sys_id: aa:66:aa:66:00:00
+   sys_priority: 65534
+   aggregation key: 4
+   lacp_time: fast
+
+slave: p2: current attached
+   port_id: 3
+   port_priority: 65535
+   may_enable: true
+
+   actor sys_id: aa:66:aa:66:00:00
+   actor sys_priority: 65534
+   actor port_id: 3
+   actor port_priority: 65535
+   actor key: 4
+   actor state: activity timeout aggregation synchronized collecting 
distributing
+
+   partner sys_id: aa:55:aa:55:00:00
+   partner sys_priority: 65534
+   partner port_id: 1
+   partner port_priority: 65535
+   partner key: 2
+   partner state: activity timeout aggregation synchronized collecting 
distributing
+
+slave: p3: current attached
+   port_id: 4
+   port_priority: 65535
+   may_enable: true
+
+   actor sys_id: aa:66:aa:66:00:00
+   actor sys_priority: 65534
+   actor port_id: 4
+   actor port_priority: 65535
+   actor key: 4
+   actor state: activity timeout aggregation synchronized collecting 
distributing
+
+   partner sys_id: aa:55:aa:55:00:00
+   partner sys_priority: 65534
+   partner port_id: 2
+   partner port_priority: 65535
+   partner key: 2
+   partner state: activity timeout aggregation synchronized collecting 
distributing
+ bond0 
+bond_mode: balance-tcp
+bond may use recirculation: yes, 
+bond-hash-basis: 0
+updelay: 0 ms
+downdelay: 0 ms
+lacp_status: negotiated
+
+
+slave p0: enabled
+   may_enable: true
+
+slave p1: enabled
+   active slave
+   may_enable: true
+
+ bond1 
+bond_mode: balance-tcp
+bond may use recirculation: yes, 
+bond-hash-basis: 0
+updelay: 0 ms
+downdelay: 0 ms
+lacp_status: negotiated
+
+
+slave p2: enabled
+   may_enable: true
+
+slave p3: enabled
+   active slave
+   may_enable: true
+
+])
+
 OVS_VSWITCHD_STOP
 AT_CLEANUP
-- 
2.11.0

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

Re: [ovs-dev] [PATCH v2 1/5] datapath-windows: Added a new file to support Ipv4 fragments.

[Guru Shetty]

On 12 January 2017 at 13:13, Anand Kumar  wrote:

> This patch adds functionalities to handle IPv4 fragments, which will be
> used by Conntrack module.
>
> Added a new structure to hold the Ipv4 fragments and a hash table to
> hold Ipv4 datagram entries. Also added a clean up thread that runs
> every minute to delete the expired IPv4 datagram entries.
>
> The individual fragments are ignored by the conntrack. Once all the
> fragments are recieved, a new NBL is created out of the reassembled
> fragments and conntrack executes actions on the new NBL.
>
> Created new APIs OvsProcessIpv4Fragment() to process individual fragments,
> OvsIpv4Reassemble() to reassemble Ipv4 fragments.
>

You should include your Signed-off-by for all your commits.


> ---
>  datapath-windows/automake.mk   |   2 +
>  datapath-windows/ovsext/Debug.h|   3 +-
>  datapath-windows/ovsext/IpFragment.c   | 506
> +
>  datapath-windows/ovsext/IpFragment.h   |  74 +
>  datapath-windows/ovsext/Switch.c   |   9 +
>  datapath-windows/ovsext/ovsext.vcxproj |   2 +
>  6 files changed, 595 insertions(+), 1 deletion(-)
>  create mode 100644 datapath-windows/ovsext/IpFragment.c
>  create mode 100644 datapath-windows/ovsext/IpFragment.h
>
> diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
> index 53983ae..4f7b55a 100644
> --- a/datapath-windows/automake.mk
> +++ b/datapath-windows/automake.mk
> @@ -32,6 +32,8 @@ EXTRA_DIST += \
> datapath-windows/ovsext/Flow.h \
> datapath-windows/ovsext/Gre.h \
> datapath-windows/ovsext/Gre.c \
> +   datapath-windows/ovsext/IpFragment.c \
> +   datapath-windows/ovsext/IpFragment.h \
> datapath-windows/ovsext/IpHelper.c \
> datapath-windows/ovsext/IpHelper.h \
> datapath-windows/ovsext/Jhash.c \
> diff --git a/datapath-windows/ovsext/Debug.h b/datapath-windows/ovsext/
> Debug.h
> index cae6ac9..6de1812 100644
> --- a/datapath-windows/ovsext/Debug.h
> +++ b/datapath-windows/ovsext/Debug.h
> @@ -42,8 +42,9 @@
>  #define OVS_DBG_STT  BIT32(22)
>  #define OVS_DBG_CONTRK   BIT32(23)
>  #define OVS_DBG_GENEVE   BIT32(24)
> +#define OVS_DBG_IPFRAG   BIT32(25)
>
> -#define OVS_DBG_LAST 24  /* Set this to the last defined module
> number. */
> +#define OVS_DBG_LAST 25  /* Set this to the last defined module
> number. */
>  /* Please add above OVS_DBG_LAST. */
>
>  #define OVS_DBG_ERRORDPFLTR_ERROR_LEVEL
> diff --git a/datapath-windows/ovsext/IpFragment.c
> b/datapath-windows/ovsext/IpFragment.c
> new file mode 100644
> index 000..2ce3932
> --- /dev/null
> +++ b/datapath-windows/ovsext/IpFragment.c
> @@ -0,0 +1,506 @@
> +/*
> + * Copyright (c) 2017 VMware, Inc.
> + *
> + * Licensed under the Apache License, Version 2.0 (the "License");
> + * you may not use this file except in compliance with the License.
> + * You may obtain a copy of the License at:
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +#include "Conntrack.h"
> +#include "Debug.h"
> +#include "IpFragment.h"
> +#include "Jhash.h"
> +#include "Offload.h"
> +#include "PacketParser.h"
> +
> +#ifdef OVS_DBG_MOD
> +#undef OVS_DBG_MOD
> +#endif
> +#define OVS_DBG_MOD OVS_DBG_IPFRAG
> +
> +/* Function declarations */
> +static VOID OvsIpFragmentEntryCleaner(PVOID data);
> +static VOID OvsIpFragmentEntryDelete(POVS_IPFRAG_ENTRY entry);
> +
> +/* Global and static variables */
> +static OVS_IPFRAG_THREAD_CTX ipFragThreadCtx;
> +static PNDIS_RW_LOCK_EX ovsIpFragmentHashLockObj;
> +static UINT64 ipTotalEntries;
> +static PLIST_ENTRY OvsIpFragTable;
> +
> +NDIS_STATUS
> +OvsInitIpFragment(POVS_SWITCH_CONTEXT context)
> +{
> +
> +NDIS_STATUS status;
> +HANDLE threadHandle = NULL;
> +
> +/* Init the sync-lock */
> +ovsIpFragmentHashLockObj = NdisAllocateRWLock(context->
> NdisFilterHandle);
> +if (ovsIpFragmentHashLockObj == NULL) {
> +return STATUS_INSUFFICIENT_RESOURCES;
> +}
> +
> +/* Init the Hash Buffer */
> +OvsIpFragTable = OvsAllocateMemoryWithTag(sizeof(LIST_ENTRY)
> +  * IP_FRAG_HASH_TABLE_SIZE,
> +  OVS_MEMORY_TAG);
> +if (OvsIpFragTable == NULL) {
> +NdisFreeRWLock(ovsIpFragmentHashLockObj);
> +ovsIpFragmentHashLockObj = NULL;
> +return STATUS_INSUFFICIENT_RESOURCES;
> +}
> +
> +for (int i = 0; i < IP_FRAG_HASH_TABLE_SIZE; i++) {
> +InitializeListHead(&OvsIpFragTable[i]);
> +}
> +
> +/* Init Cleaner Thread */
> +KeInitializeEvent(&ipFragThreadCtx.event, NotificationEvent, F

Re: [ovs-dev] OVS - ODL Sync on OF Bundle in 1.3

[Ben Pfaff]

On Wed, Jan 18, 2017 at 04:10:05PM +, Jan Scheurich wrote:
> OpenDaylight folks are finally starting to implement support of OpenFlow 
> bundles as a basis for the bundle-based hitless recync procedure we discussed 
> earlier. As ODL does not yet have protocol support for OpenFlow versions 1.4 
> or 1.5, they intend to implement the bundle extension to OF 1.3 as specified 
> in EXT-230 in
> https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-extensions-1.3.x-pack2.zip
> 
> Would you have time for a short meeting on early Monday to discuss and 
> confirm whether the OVS implementation of bundles in OF 1.3 is compliant with 
> EXT-230 and has everything they need?

It looks like OVS supports bundles in OF1.3.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v2 1/5] datapath-windows: Added a new file to support Ipv4 fragments.

[Shashank Ram]

Hi Anand, following are my comments:

1. Since you are just using a RW lock without specifically differentiating 
between and read and write protection, you could use a spin lock instead. Spin 
locks in general are recommended if all you want is a lock.

2. Instead of running the fragment cleaner thread every minute, you should also 
make use of an event to signal the thread when a fragment is removed from your 
fragment list. This way, you avoid holding unnecessary memory when it could be 
cleared. Please make use of an event to signal the thread along with a default 
timeout, in case the signal never arrives.


Thanks,

Shashank


From: ovs-dev-boun...@openvswitch.org  on 
behalf of Anand Kumar 
Sent: Thursday, January 12, 2017 1:13:42 PM
To: d...@openvswitch.org
Subject: [ovs-dev] [PATCH v2 1/5] datapath-windows: Added a new file to support 
Ipv4 fragments.

This patch adds functionalities to handle IPv4 fragments, which will be
used by Conntrack module.

Added a new structure to hold the Ipv4 fragments and a hash table to
hold Ipv4 datagram entries. Also added a clean up thread that runs
every minute to delete the expired IPv4 datagram entries.

The individual fragments are ignored by the conntrack. Once all the
fragments are recieved, a new NBL is created out of the reassembled
fragments and conntrack executes actions on the new NBL.

Created new APIs OvsProcessIpv4Fragment() to process individual fragments,
OvsIpv4Reassemble() to reassemble Ipv4 fragments.
---
 datapath-windows/automake.mk   |   2 +
 datapath-windows/ovsext/Debug.h|   3 +-
 datapath-windows/ovsext/IpFragment.c   | 506 +
 datapath-windows/ovsext/IpFragment.h   |  74 +
 datapath-windows/ovsext/Switch.c   |   9 +
 datapath-windows/ovsext/ovsext.vcxproj |   2 +
 6 files changed, 595 insertions(+), 1 deletion(-)
 create mode 100644 datapath-windows/ovsext/IpFragment.c
 create mode 100644 datapath-windows/ovsext/IpFragment.h

diff --git a/datapath-windows/automake.mk b/datapath-windows/automake.mk
index 53983ae..4f7b55a 100644
--- a/datapath-windows/automake.mk
+++ b/datapath-windows/automake.mk
@@ -32,6 +32,8 @@ EXTRA_DIST += \
 datapath-windows/ovsext/Flow.h \
 datapath-windows/ovsext/Gre.h \
 datapath-windows/ovsext/Gre.c \
+   datapath-windows/ovsext/IpFragment.c \
+   datapath-windows/ovsext/IpFragment.h \
 datapath-windows/ovsext/IpHelper.c \
 datapath-windows/ovsext/IpHelper.h \
 datapath-windows/ovsext/Jhash.c \
diff --git a/datapath-windows/ovsext/Debug.h b/datapath-windows/ovsext/Debug.h
index cae6ac9..6de1812 100644
--- a/datapath-windows/ovsext/Debug.h
+++ b/datapath-windows/ovsext/Debug.h
@@ -42,8 +42,9 @@
 #define OVS_DBG_STT  BIT32(22)
 #define OVS_DBG_CONTRK   BIT32(23)
 #define OVS_DBG_GENEVE   BIT32(24)
+#define OVS_DBG_IPFRAG   BIT32(25)

-#define OVS_DBG_LAST 24  /* Set this to the last defined module number. */
+#define OVS_DBG_LAST 25  /* Set this to the last defined module number. */
 /* Please add above OVS_DBG_LAST. */

 #define OVS_DBG_ERRORDPFLTR_ERROR_LEVEL
diff --git a/datapath-windows/ovsext/IpFragment.c 
b/datapath-windows/ovsext/IpFragment.c
new file mode 100644
index 000..2ce3932
--- /dev/null
+++ b/datapath-windows/ovsext/IpFragment.c
@@ -0,0 +1,506 @@
+/*
+ * Copyright (c) 2017 VMware, Inc.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at:
+ *
+ * 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.apache.org_licenses_LICENSE-2D2.0&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=6OuVHk-mnufSWzkKa74UkQ&m=I5c08LjVSUqyr1NmvoFFEPPDfrSIQhDwNr4ybCJddFg&s=MqMW4vcIn0dMvg5iQsDXTsvkSW5hnJ95l3b9ZmAGdwk&e=
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include "Conntrack.h"
+#include "Debug.h"
+#include "IpFragment.h"
+#include "Jhash.h"
+#include "Offload.h"
+#include "PacketParser.h"
+
+#ifdef OVS_DBG_MOD
+#undef OVS_DBG_MOD
+#endif
+#define OVS_DBG_MOD OVS_DBG_IPFRAG
+
+/* Function declarations */
+static VOID OvsIpFragmentEntryCleaner(PVOID data);
+static VOID OvsIpFragmentEntryDelete(POVS_IPFRAG_ENTRY entry);
+
+/* Global and static variables */
+static OVS_IPFRAG_THREAD_CTX ipFragThreadCtx;
+static PNDIS_RW_LOCK_EX ovsIpFragmentHashLockObj;
+static UINT64 ipTotalEntries;
+static PLIST_ENTRY OvsIpFragTable;
+
+NDIS_STATUS
+OvsInitIpFragment(POVS_SWITCH_CONTEXT context)
+{
+
+NDIS_STATUS status;
+HANDLE threadHandle = NULL;
+
+/* Init the sync-lock */
+ovsIpFragmentHashLockObj = NdisAllocateRWLock(context->NdisFilterHan

Re: [ovs-dev] [PATCH 0/1] dpif-netdev: Conditional EMC insert

[Kevin Traynor]

On 01/12/2017 04:49 PM, Ciara Loftus wrote:
> This patch is part of the OVS-DPDK performance optimizations presented
> on the OVS fall conference
> (http://openvswitch.org/support/ovscon2016/8/1400-gray.pdf)
> 
> The Exact Match Cache does not perform well in use cases with a high
> numbers of parallel packet flows. When the flow count exceeds 8k, which 
> is the size of the EMC, 'thrashing' occurs. Subsequent packets incur
> EMC misses and lead to the insertion of new entries, which are likely 
> already overwritten by the time the next packet of a flow arrives.
> 
> The extra cost of useless EMC insertions and failed EMC lookups degrades
> the performance of the netdev-dpdk datapath up to 30% compared to the
> pure performance of the dpcls classifier with EMC disabled. Profiling 
> has shown that the bulk of the degradation is caused by the EMC 
> insertions.
> 
> To avoid this degradation we apply 'probabilistic' EMC insertions, whereby
> an EMC miss only results in an EMC insertion with a random probability
> of P=1/N (N integer). With this model, the insertion overhead of the EMC
> can be reduced by a factor N, while the EMC speedup is maintained for a
> small to medium number of flows. Probabilistic insertion can be
> implemented with minimal run-time cost and naturally favors long-lived
> flows. 
> 
> Different values for P from 1/100 to 1/4000 were validated and benchmarked
> when creating this patch. Not much variance between different probabilities 
> was observed. 
> 
> We chose P=1/100 because it gives almost the same improvement as lower
> probabilities while reaching the EMC capacity and thus optimal performance
> quicker than the lower probabilities.
> 
> For P=1/100, the EMC reached full capacity after 843ms when subjecting the 
> datapath with 10 long-lived flows at 14.8 Mpps. This is much quicker 
> compared to P=1/500 and P=1/1000, which took 3792ms and 7370ms 
> respectively.

The performance results are very impressive - it looks like ~50%
performance improvement after about 10K flows.

Did you measure any negative effects when the the emc is not full?

What about about only using this type of scheme once the emc is full or
above a certain threshold?

Kevin.

> 
>  lib/dpif-netdev.c | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 

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

Re: [ovs-dev] [PATCH v2] dpif-netdev: Change definitions of 'idle' & 'processing' cycles

[Kevin Traynor]

On 01/18/2017 01:34 AM, Daniele Di Proietto wrote:
> 2017-01-17 11:43 GMT-08:00 Kevin Traynor :
>> On 01/17/2017 05:43 PM, Ciara Loftus wrote:
>>> Instead of counting all polling cycles as processing cycles, only count
>>> the cycles where packets were received from the polling.
>>
>> This makes these stats much clearer. One minor comment below, other than
>> that
>>
>> Acked-by: Kevin Traynor 
>>
>>>
>>> Signed-off-by: Georg Schmuecking 
>>> Signed-off-by: Ciara Loftus 
>>> Co-authored-by: Ciara Loftus 
> 
> Minor: the co-authored-by tag should be different from the main author.
> 
> This makes it easier to understand how busy a pmd thread is, a valid question
> that a sysadmin might have.
> 
> The counters were originally introduced to help developers understand how 
> cycles
> are spent between drivers(netdev rx) and datapath processing(dpif).
> Do you think
> it's ok to lose this type of information?  Perhaps it is, since a
> developer can also
> use a profiler, I'm not sure.
> 
> Maybe we could 'last_cycles' as it is and introduce a separate counter to get
> the idle/busy ratio.  I'm not 100% sure this is the best way.
> 
> What do you guys think?
> 

I've only ever used the current stats for trying to estimate if polling
was getting packets or not, so the addition of an idle stat helps that.
I like your suggestion of having all three stats, so then it would be
something like:

polling unsuccessful (idle)
polling successful (got pkts)
processing pkts

That would keep the info for a developer and it could help initial debug
if pkt rates drop on a pmd.

Kevin.

> Thanks,
> 
> Daniele
> 
>>> ---
>>> v2:
>>> - Rebase
>>> ---
>>>  lib/dpif-netdev.c | 57 
>>> ++-
>>>  1 file changed, 44 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
>>> index 3901129..3854c79 100644
>>> --- a/lib/dpif-netdev.c
>>> +++ b/lib/dpif-netdev.c
>>> @@ -272,7 +272,10 @@ enum dp_stat_type {
>>>
>>>  enum pmd_cycles_counter_type {
>>>  PMD_CYCLES_POLLING, /* Cycles spent polling NICs. */
>>
>> this is not used anymore and can be removed
>>
>>> -PMD_CYCLES_PROCESSING,  /* Cycles spent processing packets */
>>> +PMD_CYCLES_IDLE,/* Cycles spent idle or unsuccessful 
>>> polling */
>>> +PMD_CYCLES_PROCESSING,  /* Cycles spent successfully polling and
>>> + * processing polled packets */
>>> +
>>>  PMD_N_CYCLES
>>>  };
>>>
>>> @@ -747,10 +750,10 @@ pmd_info_show_stats(struct ds *reply,
>>>  }
>>>
>>>  ds_put_format(reply,
>>> -  "\tpolling cycles:%"PRIu64" (%.02f%%)\n"
>>> +  "\tidle cycles:%"PRIu64" (%.02f%%)\n"
>>>"\tprocessing cycles:%"PRIu64" (%.02f%%)\n",
>>> -  cycles[PMD_CYCLES_POLLING],
>>> -  cycles[PMD_CYCLES_POLLING] / (double)total_cycles * 100,
>>> +  cycles[PMD_CYCLES_IDLE],
>>> +  cycles[PMD_CYCLES_IDLE] / (double)total_cycles * 100,
>>>cycles[PMD_CYCLES_PROCESSING],
>>>cycles[PMD_CYCLES_PROCESSING] / (double)total_cycles * 
>>> 100);
>>>
>>> @@ -2892,30 +2895,43 @@ cycles_count_end(struct dp_netdev_pmd_thread *pmd,
>>>  non_atomic_ullong_add(&pmd->cycles.n[type], interval);
>>>  }
>>>
>>> -static void
>>> +/* Calculate the intermediate cycle result and add to the counter 'type' */
>>> +static inline void
>>> +cycles_count_intermediate(struct dp_netdev_pmd_thread *pmd,
>>> +  enum pmd_cycles_counter_type type)
> 
> I'd add an OVS_REQUIRES(&cycles_counter_fake_mutex)
> 
>>> +OVS_NO_THREAD_SAFETY_ANALYSIS
>>> +{
>>> +unsigned long long new_cycles = cycles_counter();
>>> +unsigned long long interval = new_cycles - pmd->last_cycles;
>>> +pmd->last_cycles = new_cycles;
>>> +
>>> +non_atomic_ullong_add(&pmd->cycles.n[type], interval);
>>> +}
>>> +
>>> +static int
>>>  dp_netdev_process_rxq_port(struct dp_netdev_pmd_thread *pmd,
>>> struct netdev_rxq *rx,
>>> odp_port_t port_no)
>>>  {
>>>  struct dp_packet_batch batch;
>>>  int error;
>>> +int batch_cnt = 0;
>>>
>>>  dp_packet_batch_init(&batch);
>>> -cycles_count_start(pmd);
>>>  error = netdev_rxq_recv(rx, &batch);
>>> -cycles_count_end(pmd, PMD_CYCLES_POLLING);
>>>  if (!error) {
>>>  *recirc_depth_get() = 0;
>>>
>>> -cycles_count_start(pmd);
>>> +batch_cnt = batch.count;
>>>  dp_netdev_input(pmd, &batch, port_no);
>>> -cycles_count_end(pmd, PMD_CYCLES_PROCESSING);
>>>  } else if (error != EAGAIN && error != EOPNOTSUPP) {
>>>  static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
>>>
>>>  VLOG_ERR_RL(&rl, "error receiving data from %s: %s",
>>>  netdev_rxq_get_name(rx), ovs_strerror(error));
>>>  }
>>> +
>>> +return

[ovs-dev] OVS - ODL Sync on OF Bundle in 1.3

[Jan Scheurich]

Hi Jarno,

OpenDaylight folks are finally starting to implement support of OpenFlow 
bundles as a basis for the bundle-based hitless recync procedure we discussed 
earlier. As ODL does not yet have protocol support for OpenFlow versions 1.4 or 
1.5, they intend to implement the bundle extension to OF 1.3 as specified in 
EXT-230 in
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-extensions-1.3.x-pack2.zip

Would you have time for a short meeting on early Monday to discuss and confirm 
whether the OVS implementation of bundles in OF 1.3 is compliant with EXT-230 
and has everything they need?

Thanks, Jan


.
--> Join Skype Meeting
  This is an online meeting for Skype for Business, the professional meetings 
and communications app formerly known as Lync.
Join by phone

+492115343925 (Germany)  English (United 
States)
89925 (Germany) English (United States)

Find a local number

Conference ID: 64134840
 Forgot your dial-in PIN? 
|Help


To join a Lync / Skype for Business meeting from an Ericsson standard video 
room, add 77 before the Conference ID (e.g. 771234567 where 1234567 is the 
conference ID).To join from a video room outside of Ericsson add one of the 
domains after 77 and Conference ID (e.g. 771234567@ .ericsson.net, where 
=emea/apac/amcs).  For assistance contact the IT Service Desk.
[!OC([1033])!]
.


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

Re: [ovs-dev] [PATCH v2 1/2] netdev-dpdk: Use intermediate queue during packet transmission.

[Fischetti, Antonio]

Thanks Ilya for your review, please see my comments inline.

Regards,
Antonio

> -Original Message-
> From: Ilya Maximets [mailto:i.maxim...@samsung.com]
> Sent: Wednesday, January 18, 2017 7:37 AM
> To: Fischetti, Antonio ; d...@openvswitch.org
> Cc: acon...@redhat.com; diproiet...@vmware.com; Bodireddy, Bhanuprakash
> ; markus.magnus...@ericsson.com
> Subject: Re: [PATCH v2 1/2] netdev-dpdk: Use intermediate queue during
> packet transmission.
> 
> Not a complete review. This code is full of races.
> See details inline.
> 
> Best regards, Ilya Maximets.
> 
> On 17.01.2017 18:37, antonio.fische...@intel.com wrote:
> > This patch implements the intermediate Tx queues on 'dpdk' type ports.
> >
> > Test results:
> >  * In worst case scenario with fewer packets per batch, a significant
> >bottleneck is observed for netdev_dpdk_eth_send() function due to
> >expensive MMIO writes.
> >
> >  * Also its observed that CPI(cycles per instruction) Rate for the
> function
> >stood between 3.15 and 4.1 which is significantly higher than
> acceptable
> >limit of 1.0 for HPC applications and theoretical limit of 0.25 (As
> Backend
> >pipeline can retire 4 micro-operations in a cycle).
> >
> >  * With this patch, CPI for netdev_dpdk_eth_send() is at 0.55 and the
> overall
> >throughput improved significantly.
> >
> >
> > Signed-off-by: Antonio Fischetti 
> > Signed-off-by: Bhanuprakash Bodireddy 
> > Co-authored-by: Bhanuprakash Bodireddy
> 
> > Signed-off-by: Markus Magnusson 
> > Co-authored-by: Markus Magnusson 
> > ---
> >  lib/dpif-netdev.c | 53 +++--
> >  lib/netdev-bsd.c  |  1 +
> >  lib/netdev-dpdk.c | 82
> ++-
> >  lib/netdev-dummy.c|  1 +
> >  lib/netdev-linux.c|  1 +
> >  lib/netdev-provider.h |  8 +
> >  lib/netdev-vport.c|  3 +-
> >  lib/netdev.c  |  9 ++
> >  lib/netdev.h  |  1 +
> >  9 files changed, 149 insertions(+), 10 deletions(-)
> >
> > diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> > index 3901129..58ac429 100644
> > --- a/lib/dpif-netdev.c
> > +++ b/lib/dpif-netdev.c
> > @@ -289,6 +289,8 @@ struct dp_netdev_rxq {
> >  struct dp_netdev_pmd_thread *pmd;  /* pmd thread that will poll
> this queue. */
> >  };
> >
> > +#define LAST_USED_QID_NONE -1
> > +
> >  /* A port in a netdev-based datapath. */
> >  struct dp_netdev_port {
> >  odp_port_t port_no;
> > @@ -303,6 +305,8 @@ struct dp_netdev_port {
> >  char *type; /* Port type as requested by user. */
> >  char *rxq_affinity_list;/* Requested affinity of rx queues. */
> >  bool need_reconfigure;  /* True if we should reconfigure
> netdev. */
> > +int last_used_qid;  /* Last queue id where packets could be
> > +   enqueued. */
> >  };
> >
> >  /* Contained by struct dp_netdev_flow's 'stats' member.  */
> > @@ -619,6 +623,9 @@ static int dpif_netdev_xps_get_tx_qid(const struct
> dp_netdev_pmd_thread *pmd,
> >  static inline bool emc_entry_alive(struct emc_entry *ce);
> >  static void emc_clear_entry(struct emc_entry *ce);
> >
> > +static struct tx_port *pmd_send_port_cache_lookup
> > +(const struct dp_netdev_pmd_thread *pmd, odp_port_t port_no);
> > +
> >  static void
> >  emc_cache_init(struct emc_cache *flow_cache)
> >  {
> > @@ -3507,15 +3514,19 @@ pmd_load_queues_and_ports(struct
> dp_netdev_pmd_thread *pmd,
> >  return i;
> >  }
> >
> > +enum { DRAIN_TSC = 2ULL };
> > +
> >  static void *
> >  pmd_thread_main(void *f_)
> >  {
> >  struct dp_netdev_pmd_thread *pmd = f_;
> > -unsigned int lc = 0;
> > +unsigned int lc = 0, lc_drain = 0;
> >  struct polled_queue *poll_list;
> >  bool exiting;
> >  int poll_cnt;
> >  int i;
> > +uint64_t prev = 0, now = 0;
> > +struct tx_port *tx_port;
> >
> >  poll_list = NULL;
> >
> > @@ -3548,6 +3559,26 @@ reload:
> > poll_list[i].port_no);
> >  }
> >
> > +#define MAX_LOOP_TO_DRAIN 128
> > +if (lc_drain++ > MAX_LOOP_TO_DRAIN) {
> > +lc_drain = 0;
> > +prev = now;
> > +now = pmd->last_cycles;
> > +if ((now - prev) > DRAIN_TSC) {
> > +HMAP_FOR_EACH (tx_port, node, &pmd->tx_ports) {
> 
> 'pmd->tx_ports' must be protected by 'pmd->port_mutex'. Also it can be
> changed
> while pmd still working. I think you wanted something like 'pmd-
> >send_port_cache'.

Ok, I will replace it with
HMAP_FOR_EACH (tx_port, node, &pmd->send_port_cache)


> 
> > +if (tx_port->port->last_used_qid !=
> LAST_USED_QID_NONE) {
> > +/* This queue may contain some buffered packets
> waiting
> > + * to be sent out. */
> > +netdev_txq_drain(tx_port->port->netdev,
> > +tx_port->port->last_used_qid,
> > +

[ovs-dev] Sync on PTAP, EXT-382 and NSH

[Jan Scheurich]

Hi,

Please be invited to the next sync meeting.

Minutes of the previous meeting:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327738.html

Actions Points:
AP-1 (Jarno): Coordinate review of Yi's backported net-next patches
AP-2 (Jiri) Check the ability of the kernel datapath to match on the presence 
of Ethernet header w/o matching on Ethernet addresses. Formating of such DP 
flows?
AP-3 (Jiri) Provide an update on the status and ETA of the RTNETLINK API patches

Link to the Google design doc:
https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit

Regards, Jan

.
--> Join Skype Meeting
  This is an online meeting for Skype for Business, the professional meetings 
and communications app formerly known as Lync.
Join by phone

+492115343925 (Germany)  English (United 
States)
89925 (Germany) English (United States)

Find a local number

Conference ID: 70849799
 Forgot your dial-in PIN? 
|Help


To join a Lync / Skype for Business meeting from an Ericsson standard video 
room, add 77 before the Conference ID (e.g. 771234567 where 1234567 is the 
conference ID).To join from a video room outside of Ericsson add one of the 
domains after 77 and Conference ID (e.g. 771234567@ .ericsson.net, where 
=emea/apac/amcs).  For assistance contact the IT Service Desk.
[!OC([1033])!]
.


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

[ovs-dev] PTAP, EXT-382 and NSH: Minutes of meeting 2016-01-17

[Jan Scheurich]

Date: 2016-12-21, 17-18:30 CET
Participants: Jarno R, Ben P, Ben M-C, Jiri B, Simon H, Zoltan B, Jan S

Summary:

*   Status/progress/coordination of work packages:
   1 - L3 packet handling in kernel datapath (net-next)
  Upstreaming to net-next done, depending on Eric G's VLAN fixes.
  Yi Yang has backported the net-next patches and submitted to ovs-dev on 
2016-12-28
  AP (Jarno): coordinate review of Yi's backported patches

  Firsts tests backported patches on 4.9 kernel showed instabilities
Jiri: Better to start testing with net or net-next kernel.
AP (Jiri): help Zoltan set up test environment.

  Q: How to match on presence/absence of Ethernet header in kernel datapath?
  AP (Jiri): Check that the presence/absence of the Ethernet attribute in 
the netlink flow mask is enough for the datapath to match on "packet_type" 
(Ethernet vs L3). Can the kernel datapath handle an "all-zero" Ethernet mask 
attribute as indicator to match on presence of Ethernet header without  
matching on MAC addresses?
  Jarno: How to properly reflect this in flow printouts?

   2 - Layer 3 tunnel configuration (RedHat)
  RTNETLINK patches on OVS are prerequisite to start testing L3 tunnels on 
kernel datapath.
  This patch is on the critical line.
  Redhat (Eric G) working on this. Common understanding with Pravin 
achieved.
  AP (Jiri): Send update on status and ETA (probably after RedHat 
conference next week)

   3 - L3 ports in non-PTAP bridge (Ericssson)
  Packet_type field introduced in structs dp_packet and flow.
  Porting of earlier user-space patches to packet_type representation 
completed.
  L3 tunnel handling simplified compared to earlier patch sets. Impact now 
solely on generic tunnel handler in ofproto. No longer impact on native 
tnl-ports.
  Functional tests done on netdev datapath. Make check successful.
  Waiting for WPs 1 and 2 and internal clearance before submission.

   4 - PTAP bridge (Ericsson)
  Implementation ongoing: OXM field PACKET_TYPE added, bridge property 
"packet-type-aware" added, alternative prerequisite "packet_type=(1,Ethertype)" 
for existing L3 OXM match fields done, Interfacing PTAP bridge with versatile 
tunnel ports done
  Functional testing ongoing.
  Error handling to be done.
  Packet In/Out and Table Features not started.

   5 - Basic EXT-382 (Ericsson)
  Not started yet. Zoltan can start soon while test of L3 tunneling on 
kernel datapath is waiting for WP 1 and 2.

   6 - VXLAN-GPE tunnel (Intel)
  Yi Yang has started to adapt the earlier patches to the new packet_type 
concept (WP3)

   7 - NSH MD1 Match Fields (Intel)
  Yi Yang will adapt earlier patches to new OXM point codes and make sure 
the fields have the right pre-requisites so that they are only used as packet 
match fields, not as metadata fields. This can run in parallel to WPs 4&5.

   8 - Encap/Decap NSH MD1 (Intel)
Depends on WP 5.

   9 - GEN_TLV registers (VMware)
  Jarno will have time to start with this in 2-3 weeks.

   10 - NSH MD2 Support (Intel)
  Depend on WP 9.

*   ONF specification drafts for NSH and Generic TLV Mapping
   Ongoing merger of ONF with ON.Lab stresses the importance of open-source 
implementations for evolving the ONF specifications. The implementation of NSH 
in OVS is welcome in this context.
   Jan will draft a short ONF specification for NSH using the official ONF spec 
template, based on the content of the Google doc for presentation and 
discussion in the Oped datapath WG in ONF.
   AP (Ben M-C): Check if there is any example spec to look at.
   The draft spec for handling generic TLV fields will be started when the 
design in OVS is clearer.

*   Any other issue
-

Next meeting: Tue 2016-01-24, 17:00 CET

Link to the Google design doc:
https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit

Regards, Jan


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

Re: [ovs-dev] [RFC] ofproto/bond: operational vs administratively disabled bond interface

[Eelco Chaudron]

On 17/01/17 20:12, Ben Pfaff wrote:

On Tue, Jan 17, 2017 at 12:10:59PM -0200, Flavio Leitner wrote:

On Tue, 17 Jan 2017 09:34:19 +0100
Eelco Chaudron  wrote:


Currently OVS does not distinguish between a bond slave being operational
disabled, i.e. link being down, and administratively disabled.

Take the example where the administrator disabled a link in a bond,
"ovs-appctl bond/disable-slave bond0 enp129s0f0", it's automatically
enabled again due to the fact the link is up.

I would like to change this behavior such that when disabled trough appctl
the slave is no longer used until explicitly enabled again via appctl.

Eelco and I discussed this off list and I agree that this sounds like
a bug.  The slave should not be used if the admin has disabled it
regardless of its link state.

The behavior matches the documentation:

bond/enable-slave port slave
bond/disable-slave port slave
   Enables (or disables) slave on the given bond port, skipping any
   updelay (or downdelay).

   This  setting  is not permanent: it persists only until the car‐
   rier status of slave changes.


So to administratively disable a link, you should either force the link 
to be down (and don't forget after system reboot), or remove the slave 
from the bond? If so, no re-work is needed here.



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