Re: [ovs-dev] [PATCH 4/4] ovn-controller: Use separate thread for packet-in processing.

[Han Zhou]

On Tue, Jun 6, 2017 at 3:56 PM, Ben Pfaff  wrote:
>
> On Thu, May 25, 2017 at 05:26:47PM -0700, Han Zhou wrote:
> > This patch introduces multi-threading for ovn-controller and use
> > dedicated thread for packet-in processing as a start. It decouples
> > packet-in processing and ovs flow computing, so that packet-in inputs
> > won't trigger flow recomputing, and flow computing won't block
> > packet-in processing. In large scale environment this largely reduces
> > CPU cost and improves performance.
>
> Won't this double the load on the southbound database server, as well as
> the bandwidth to and from it?  We already have a bottleneck there.

Ben, yes this is the trade-off. Here are the considerations:

1. The bottle-neck in ovn-controller is easier to hit (you don't even need
many number of HVs to hit it)
2. The bottle-neck of southbound DB do exist when number of HV increases
but since you are already working on the ovsdb clustering I suppose it will
be resolved.

However I agree that this is not ideal. Alternatively we can spin-up a
dedicated thread for SB IDL processing and other "worker" thread just read
the data with proper locking. This will be more complicated but should be
doable, what do you think?

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

Re: [ovs-dev] [PATCH 3/3] netdev-linux: maintain original device's state

[Ben Pfaff]

On Mon, May 29, 2017 at 04:40:23PM -0300, Flavio Leitner wrote:
> It is important to maintain the original state when
> the device already exists in the system.
> 
> Signed-off-by: Flavio Leitner 

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

Re: [ovs-dev] [PATCH 2/3] netdev-linux: make tap devices persistent.

[Ben Pfaff]

On Mon, May 29, 2017 at 04:40:22PM -0300, Flavio Leitner wrote:
> When using data path type "netdev", bridge port is a tun device
> and when OVS restarts, that device and its network configuration
> is lost.
> 
> This patch enables the tap device to persist instead.
> 
> Signed-off-by: Flavio Leitner 

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

Re: [ovs-dev] [PATCH 1/3] ovs-router: fix refcnt leak when program terminates.

[Ben Pfaff]

On Mon, May 29, 2017 at 04:40:21PM -0300, Flavio Leitner wrote:
> Install a handler to flush routes and release devices when
> the program is terminating.
> 
> Signed-off-by: Flavio Leitner 

Thank you!  I applied this to master.

If you think that this is a bug fix that I should backport to earlier
versions, let me know.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 2/2] xlate: Use datapath clone action for patch port translation

[Ben Pfaff]

On Fri, May 26, 2017 at 08:47:45PM -0700, Andy Zhou wrote:
> When available, use datapath 'clone' for patch port translation.
> Clone provides a stronger guarantee that packet will be restored
> after going through a patch port, Even in case the packet is
> NAT'd by the bridge behind the patch port.
> 
> Signed-off-by: Andy Zhou 

Thanks for working on this.  It is good to improve the correctness of
the datapath implementation of OpenFlow actions, and this is the weakest
point in correctness that I currently know about.

This approach seems correct, but expensive in the common case where the
packet does not need to be restored, since "clone" and "sample" are
expensive datapath actions: I expect that they are more expensive than a
few "set field" actions, and certainly more expensive than doing
nothing.  I think that there are only a few datapath actions that make
changes that later datapath actions can't restore.  Can the code here
check whether any of those actions are actually used, and avoid using
"clone" or "sample" in the common case?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/4] ovn-controller: decouple localnet_port update from patch_run

[Han Zhou]

On Tue, Jun 6, 2017 at 12:31 PM, Ben Pfaff  wrote:
>
> On Thu, May 25, 2017 at 05:26:44PM -0700, Han Zhou wrote:
> > We figure out local datapaths in binding_run() but update the field
> > localnet_port for each local datapath that has localnet port in
> > patch_run(). This patch updates the localnet_port field in binding_run
> > directly and removes the logic in patch_run(), since the logic is
> > more about port-binding processing, and patch_run() is focusing on
> > patch port creation only.
> >
> > In a future patch binding_run() will be used in a new thread for
> > pinctrl, but patch_run() will not.
> >
> > Signed-off-by: Han Zhou 
>
> Thanks for working on this!  I'm looking forward to the improvements to
> ovn-controller from this series.
>
> I like this change even on its own.  I think that it will make the code
> clearer.
>
> I don't think that localnet_ports is being used as a hash table here.
> It is really being used as a list or an array, because the only
> operations on it are insertion and iteration.  Perhaps a dynamic array
> of "struct ovsrec_binding *" would be a better way?  Another way, which
> is even simpler, would be to simply add a second iteration over the
> sbrec_port_binding that looks only at localnet ports.  This would be
> slower, but it would not increase the big-O for binding_run() because it
> already has a similar loop.

Agree.

>
> I think that there is a memory leak here because I don't see anything
> that frees the "struct localnet_port"s (only the hash table that holds
> them).

Sorry, I will come up with next patch just iterate port-bindings again.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] xlate: Add datapath clone generation API

[Ben Pfaff]

On Tue, Jun 06, 2017 at 04:55:19PM -0700, Ben Pfaff wrote:
> I think that this implementation fails when it chooses
> COMPOSE_CLONE_USING_ACTIONS, because in that case it does not save and
> restore the base flow.

I see now that I misunderstood.  Never mind, on this point.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 1/2] xlate: Add datapath clone generation API

[Ben Pfaff]

On Fri, May 26, 2017 at 08:47:44PM -0700, Andy Zhou wrote:
> There are three methods of translating openflow layer clone action.
> Using datapath clone action, datapath sample action or using actions
> to negating the any changes within a clone.  Xlate logic selects
> a specific method depends on datapath features detected at the boot time.
> 
> Currently only xlate_clone() implements the selection logic since it
> is the solo user, but patches will add more users. Introduce
>  new APIs that hide the details of generating datapath clone action.
> 
> Signed-off-by: Andy Zhou 

This adds a nice layer of abstraction.  Thanks!

I don't think it's necessary to use malloc and free to allocate these
structures, if the caller provides an instance of struct
compose_clone_info.  That seems like a better choice, in my opinion.

I think that this implementation fails when it chooses
COMPOSE_CLONE_USING_ACTIONS, because in that case it does not save and
restore the base flow.

A possible improvement to the implementation would be to keep track of
the nesting level and fall back from COMPOSE_CLONE_USING_SAMPLE to
COMPOSE_CLONE_USING_ACTIONS when it exceeds the datapath's capability.

The code might be a little more straightforward without breaking
compose_clone_method() into a separate function, because then there is
no need to have a separate switch statement to again discover what
method to use.  But if you prefer this implementation, I understand that
too.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC PATCH 0/2] Generic encap/decap actions implementation

[Yang, Yi Y]

Ben, we'll send out new patch series based on the recently merged patches and 
new PTAP series, sending this in the very early phase was just to get some 
general comments about implementation, Jan has reviewed them and changed many 
things per his full ovs experience, so next post will have high quality.

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org] 
Sent: Wednesday, June 7, 2017 2:17 AM
To: Yang, Yi Y 
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [RFC PATCH 0/2] Generic encap/decap actions 
implementation

On Thu, Apr 20, 2017 at 11:26:39AM +0800, Yi Yang wrote:
> This patchset implements "Generic encap/decap actions" (EXT-382), it 
> is based on top of the below patchsets:
> 
> [PATCH v1 0/5] NSH userspace support
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/331158.html
> 
> [PATCH 0/10] userspace: Packet type-aware pipeline 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/331023.html
> 
> [PATCH v3 0/8] userspace: Support for L3 tunnelin 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330488.html

Hi, thanks for posting this.

It's difficult to deal with multiple dependent patch series.  In practice, I 
don't usually even read patch series that depend on others, because it means 
that there are multiple steps to get to them.  To get a better chance for 
review, I suggest putting all of the patches together into a single series.  In 
case it is part of your concern, it's no problem to have RFC or experimental 
patches at the end of a series that is otherwise ready for review.

Thanks,

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

Re: [ovs-dev] [PATCH] test-hash: Fix unaligned pointer value error.

[Ben Pfaff]

On Fri, May 26, 2017 at 02:11:31PM -0700, Joe Stringer wrote:
> Clang 4.0 complains:
> 
> ../tests/test-hash.c:160:16: error: taking address of packed member 'b' of
> class or structure 'offset_ovs_u128' may result in an unaligned pointer value
>   [-Werror,-Waddress-of-packed-member]
> in0 = _data.b;
> 
> Set the bit in the aligned u128 first then copy the contents into the
> offset u128 so that we don't have to take the address of the non-aligned
> u128 and pass it to set_bit128.
> 
> For the 256byte_hash, fix it up so that it's actually testing the 256B
> hash inside a 32-bit offset u128 as well.
> 
> Suggested-by: Ben Pfaff 
> Signed-off-by: Joe Stringer 

Thanks!

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

Re: [ovs-dev] [PATCH 2/2] docs: Document dpdkr ports

[Ben Pfaff]

On Fri, May 26, 2017 at 03:12:38PM +0100, Stephen Finucane wrote:
> I has an idea what these were but that idea was somewhat incorrect and
> out-of-date. Add a minimal guide to fill in these gaps, along with a
> warning about how useless these things generally are now (yay,
> vhost-user).
> 
> Signed-off-by: Stephen Finucane 
> Cc: Ciara Loftus 
> Cc: Kevin Traynor 

Thanks for adding to the documentation!  I applied this to master,
folding in your later corrections and Kevin's suggestion.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Top 50 June 2017

[Bonesca Mailing]

Deze email nieuwsbrief werd in grafisch HTML formaat verzonden.
Als u deze tekstversie ziet, verkiest uw email programma "gewone tekst" emails.
U kan de originele nieuwsbrief online bekijken:
http://ymlp297.com/zMcOMA



Good afternoon, Gutentag, Goedemiddag, Bonjour,

GB:  In the attachment you can find our top 50 June offer!
DE: Im Anlage finden sie unsere Top 50 Juni Angebot!
NL: In de bijlage vind u onze juni top 50 aanbieding!
FR: Dans lattachement vous pouvez trouver notre top 50 Juin
offre!

Kind regards, Mit freundlichen grüssen, Met vriendelijke groet,
Cordialement,

Bonesca Import en Export BV

Bertus Brouwer
Director/Purchase - Dutch / English / German
Tel.: +31 (0) 527 68 07 81
Mail: ber...@bonesca.nl

Ramesh Raja
Sales தமிழ் / Tamil / Dutch / English
Tel: +31 (0) 6 24 42 62 49
Mail: st...@bonesca.nl

Nedal Muhtaseb
Sales - Dutch / Arab / English / German
Tel: +31 (0) 527 68 07 83
Mail: ne...@bonesca.nl

Thu Hanh
Sales Vietnamese / Thai / Laothian / German / English
Tel: +49 (0) 32221097676
Mail: t...@bonesca.nl

Marianne Kramer
Sales - Dutch / French / English / German
Tel: +31 (0) 527 68 07 82
Mail: maria...@bonesca.nl
Henry Bakker
Administration/Planning
Tel: +31 (0) 527 68 07 85
Mail: he...@bonesca.nl; i...@bonesca.nl;invo...@bonesca.nl

_
Sign out / Change E-mailadress: http://ymlp297.com/ughbywyjgsgubbebbgjshmgghewbs
Powered door YourMailingListProvider

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

Re: [ovs-dev] [PATCH 1/2] docs: Clarify the superiority of dpdkvhostuserclient

[Ben Pfaff]

On Fri, May 26, 2017 at 03:12:37PM +0100, Stephen Finucane wrote:
> Apparently dpdkvhostuser interfaces are inferior to dpdkvhostuserclient.
> Explain why.
> 
> Signed-off-by: Stephen Finucane 
> Cc: Ciara Loftus 
> Cc: Kevin Traynor 
> ---
> I'd like to note what happens to traffic when OVS or a VM is restarted
> for both port types. If someone knows the answer to this, please feel
> free to take ownership of that patch/ask me for a v2.

I applied this to master on the strength of Kevin's ack, even though it
sounds like there is still room for improvement based on Aaron and
Darrell's comment.

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

Re: [ovs-dev] [PATCH 4/4] ovn-controller: Use separate thread for packet-in processing.

[Ben Pfaff]

On Thu, May 25, 2017 at 05:26:47PM -0700, Han Zhou wrote:
> This patch introduces multi-threading for ovn-controller and use
> dedicated thread for packet-in processing as a start. It decouples
> packet-in processing and ovs flow computing, so that packet-in inputs
> won't trigger flow recomputing, and flow computing won't block
> packet-in processing. In large scale environment this largely reduces
> CPU cost and improves performance.

Won't this double the load on the southbound database server, as well as
the bandwidth to and from it?  We already have a bottleneck there.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH 3/4] ovn-controller: refactor and abstract ovs_idl registering

[Ben Pfaff]

On Thu, May 25, 2017 at 05:26:46PM -0700, Han Zhou wrote:
> Abstract as a function so that it can be used by other modules.
> 
> Signed-off-by: Han Zhou 

This is reasonable on its own, so I applied it.  Thank you!
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

[ovs-dev] Las 4 perspectivas de calidad

[Balanced Scorecard - En Línea]

Lograr que la estrategía sea el objetivo de todos y de todos los días

Balanced Scorecard: Aplicación e Implementación 
30 de junio - Online en Vivo - 10:00 a 13:00 y de 15:00 a 18:00Hrs 

El BSC es un poderoso instrumento para medir el desempeño corporativo y se ha 
demostrado que es la herramienta más efectiva para enlazar la visión, misión y 
la estrategia a cinco medidas de desempeño. Además permite ofrecer una visión 
completa de la organización, siendo el elemento esencial del sistema de 
información que sirve de apoyo al sistema de control de gestión en su misión de 
mejorar su nivel de competitividad en el largo plazo.

Provee una estructura para centrarse en los indicadores de cada proceso crítico 
tales como: plan de negocio, distribución de recursos, estrategias y 
retroalimentación, aprendizaje, comportamiento ante los clientes internos y 
externos y hacia acciones comunitarias.


¿Requiere la información a la Brevedad?.
responda este email con la palabra: balanced,junto con los siguientes datos:
Nombre:
Empresa:
Teléfono:

y se lo enviaremos a la brevedad.
centro telefónico: 018002129393


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

[ovs-dev] [PATCH] ovn-sb.xml: Update and improve documentation.

[Ben Pfaff]

Some of the abbreviations at the head of this document, like LN and PN,
turn out to not be very useful, so expand them for clarity.

Some of the statements in this document are more about planning the design
than the current design.  Remove these for clarity.

Port_Binding rows used to all be about physical locations, except for
patch ports, but there are more kinds of rows now.  Elaborate for clarity.

Expand on the purpose of the Datapath_Binding table.

Signed-off-by: Ben Pfaff 
---
 ovn/ovn-sb.xml | 89 +-
 1 file changed, 50 insertions(+), 39 deletions(-)

diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml
index f3c321222c0d..34b6b448c1e3 100644
--- a/ovn/ovn-sb.xml
+++ b/ovn/ovn-sb.xml
@@ -21,60 +21,61 @@
 different properties, as described in the sections below.
   
 
-  Physical Network (PN) data
+  Physical network
 
   
-PN tables contain information about the chassis nodes in the system.  This
-contains all the information necessary to wire the overlay, such as IP
-addresses, supported tunnel types, and security keys.
+Physical network tables contain information about the chassis nodes in the
+system.  This contains all the information necessary to wire the overlay,
+such as IP addresses, supported tunnel types, and security keys.
   
 
   
-The amount of PN data is small (O(n) in the number of chassis) and it
-changes infrequently, so it can be replicated to every chassis.
+The amount of physical network data is small (O(n) in the number of
+chassis) and it changes infrequently, so it can be replicated to every
+chassis.
   
 
   
-The  table comprises the PN tables.
+The  and  tables are the physical
+network tables.
   
 
-  Logical Network (LN) data
+  Logical Network
 
   
-LN tables contain the topology of logical switches and routers, ACLs,
-firewall rules, and everything needed to describe how packets traverse a
-logical network, represented as logical datapath flows (see Logical
-Datapath Flows, below).
+Logical network tables contain the topology of logical switches and
+routers, ACLs, firewall rules, and everything needed to describe how
+packets traverse a logical network, represented as logical datapath flows
+(see Logical Datapath Flows, below).
   
 
   
-LN data may be large (O(n) in the number of logical ports, ACL rules,
-etc.).  Thus, to improve scaling, each chassis should receive only data
-related to logical networks in which that chassis participates.  Past
-experience shows that in the presence of large logical networks, even
-finer-grained partitioning of data, e.g. designing logical flows so that
-only the chassis hosting a logical port needs related flows, pays off
-scale-wise.  (This is not necessary initially but it is worth bearing in
-mind in the design.)
+Logical network data may be large (O(n) in the number of logical ports, ACL
+rules, etc.).  Thus, to improve scaling, each chassis should receive only
+data related to logical networks in which that chassis participates.
   
 
   
-The LN is a slave of the cloud management system running northbound of OVN.
-That CMS determines the entire OVN logical configuration and therefore the
-LN's content at any given time is a deterministic function of the CMS's
-configuration, although that happens indirectly via the
- database and ovn-northd.
+The logical network data is ultimately controlled by the cloud management
+system (CMS) running northbound of OVN.  That CMS determines the entire OVN
+logical configuration and therefore the logical network data at any given
+time is a deterministic function of the CMS's configuration, although that
+happens indirectly via the  database and
+ovn-northd.
   
 
   
-LN data is likely to change more quickly than PN data.  This is especially
-true in a container environment where VMs are created and destroyed (and
-therefore added to and deleted from logical switches) quickly.
+Logical network data is likely to change more quickly than physical network
+data.  This is especially true in a container environment where VMs are
+created and destroyed (and therefore added to and deleted from logical
+switches) quickly.
   
 
   
- and  contain LN
-data.
+The , , , , , and  tables contain logical
+network data.
   
 
   Logical-physical bindings
@@ -178,7 +179,7 @@
   
 
   Each row in this table represents a hypervisor or gateway (a chassis) in
-  the physical network (PN).  Each chassis, via
+  the physical network.  Each chassis, via
   ovn-controller/ovn-controller-vtep, adds
   and updates its own row, and keeps a copy of the remaining rows to
   determine how to reach other hypervisors.
@@ -1655,11 +1656,18 @@ tcp.flags = RST;
 
   
 
-  Each row in this table 

Re: [ovs-dev] [PATCH 2/2] ipfix: Update Timestamp when flow updated

[Greg Rose]

On 06/06/2017 08:22 AM, Ben Pfaff wrote:

On Mon, Jun 05, 2017 at 08:34:32PM -0700, Greg Rose wrote:
> On 06/05/2017 06:04 PM, Ben Pfaff wrote:
>> From: Greg Rose 
>>
>> Reported-by: Felix Konstantin Maurer 
>> Signed-off-by: Greg Rose 
>> [b...@ovn.org changed this to use ipfix_now()]
>> Signed-off-by: Ben Pfaff 
>> ---
>>   ofproto/ofproto-dpif-ipfix.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/ofproto/ofproto-dpif-ipfix.c b/ofproto/ofproto-dpif-ipfix.c
>> index 5589b0ea05e1..bc63b7b0294b 100644
>> --- a/ofproto/ofproto-dpif-ipfix.c
>> +++ b/ofproto/ofproto-dpif-ipfix.c
>> @@ -1643,6 +1643,7 @@ ipfix_cache_update(struct dpif_ipfix_exporter 
*exporter,
>>   ipfix_cache_aggregate_entries(entry, old_entry);
>>   free(entry);
>>   ipfix_update_stats(exporter, false, current_flows, 
sampled_pkt_type);
>> +old_entry->flow_end_timestamp_usec = ipfix_now();
>>   }
>>   }
>>
>>
> Looks good, thanks Ben!

Thanks for the review!

If I recall correctly, Felix reported that your original patch didn't
help, though, so probably this one doesn't either.  We should track that
down before we go farther, I guess.


Yes, I'm am following up.  Having all sorts of problems getting a working ipfix 
flow collector to work though.  The ManageEngine netflow collector claims to 
work with ipfix but SFAICT it does not so I'm not going to waste more time on 
it.  Once I can start
collecting and analyzing the work should proceed quickly.

Thanks,

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

Re: [ovs-dev] [PATCH 1/4] ovn-controller: decouple localnet_port update from patch_run

[Ben Pfaff]

On Thu, May 25, 2017 at 05:26:44PM -0700, Han Zhou wrote:
> We figure out local datapaths in binding_run() but update the field
> localnet_port for each local datapath that has localnet port in
> patch_run(). This patch updates the localnet_port field in binding_run
> directly and removes the logic in patch_run(), since the logic is
> more about port-binding processing, and patch_run() is focusing on
> patch port creation only.
> 
> In a future patch binding_run() will be used in a new thread for
> pinctrl, but patch_run() will not.
> 
> Signed-off-by: Han Zhou 

Thanks for working on this!  I'm looking forward to the improvements to
ovn-controller from this series.

I like this change even on its own.  I think that it will make the code
clearer.

I don't think that localnet_ports is being used as a hash table here.
It is really being used as a list or an array, because the only
operations on it are insertion and iteration.  Perhaps a dynamic array
of "struct ovsrec_binding *" would be a better way?  Another way, which
is even simpler, would be to simply add a second iteration over the
sbrec_port_binding that looks only at localnet ports.  This would be
slower, but it would not increase the big-O for binding_run() because it
already has a similar loop.

I think that there is a memory leak here because I don't see anything
that frees the "struct localnet_port"s (only the hash table that holds
them).
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [RFC PATCH 0/2] Generic encap/decap actions implementation

[Ben Pfaff]

On Thu, Apr 20, 2017 at 11:26:39AM +0800, Yi Yang wrote:
> This patchset implements "Generic encap/decap actions" (EXT-382),
> it is based on top of the below patchsets:
> 
> [PATCH v1 0/5] NSH userspace support
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/331158.html
> 
> [PATCH 0/10] userspace: Packet type-aware pipeline
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/331023.html
> 
> [PATCH v3 0/8] userspace: Support for L3 tunnelin
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330488.html

Hi, thanks for posting this.

It's difficult to deal with multiple dependent patch series.  In
practice, I don't usually even read patch series that depend on others,
because it means that there are multiple steps to get to them.  To get a
better chance for review, I suggest putting all of the patches together
into a single series.  In case it is part of your concern, it's no
problem to have RFC or experimental patches at the end of a series that
is otherwise ready for review.

Thanks,

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

Re: [ovs-dev] [PATCH v1 0/5] NSH userspace support

[Ben Pfaff]

On Thu, Apr 20, 2017 at 10:42:06AM +0800, Yi Yang wrote:
> This patchset adds NSH userspace support, it just covers
> parse, match and set_field NSH fields, actions encap_nsh
> and decap_nsh will be included in the following patchset.
> 
> This patchset is based on top of Zoltan's 

Now that the base patches have been committed, would you mind rebasing
and reposting?

Thanks,

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

Re: [ovs-dev] [PATCH] bfd: Detect Multiplier configuration

[Ben Pfaff]

On Tue, Jun 06, 2017 at 05:11:54PM +0200, Szucs Gabor wrote:
> Mult value (bfd.DetectMult in RFC5880) is hard-coded and equal to 3 in
> current openvswitch. As a consequence remote and local mult is the same.
> 
> In this commit the mult (Detect Multiplier/bfd.DetectMult/Detect Mult)
> can be set on each interface setting the mult= in bfd Column
> in Interface table of ovsdb database.
> Example:
> ovs-vsctl set Interface p1 bfd:mult=4
> sets mult=4 on p1 interface

Thanks for working on this!

I applied this to master.  I folded in the following changes.  In
bfd_configure(), I removed some log messages that seem to be more
aggressive than otherwise used in the bfd module.  I also fixed an
indentation error.  In vswitch.xml, I changed documentation that just
quoted a standard without explaining it, and I updated a place that had
been missed, that said 3 was the multiplier, to say that this way only
the default.  I also added a NEWS item.

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

diff --git a/NEWS b/NEWS
index 000573367f1e..82004c845ce4 100644
--- a/NEWS
+++ b/NEWS
@@ -57,6 +57,7 @@ Post-v2.7.0
  * New vxlan tunnel extension "gpe" to support VXLAN-GPE tunnels.
  * Transparently pop and push Ethernet headers at transmit/reception
of packets to/from L3 tunnels.
+   - The BFD detection multiplier is now user-configurable.
 
 v2.7.0 - 21 Feb 2017
 -
diff --git a/lib/bfd.c b/lib/bfd.c
index eaf1821c1d0f..4174e8b8e535 100644
--- a/lib/bfd.c
+++ b/lib/bfd.c
@@ -356,8 +356,6 @@ bfd_configure(struct bfd *bfd, const char *name, const 
struct smap *cfg,
 bool need_poll = false;
 bool cfg_min_rx_changed = false;
 bool cpath_down, forwarding_if_rx;
-int new_mult;
-int old_mult;
 
 if (!cfg || !smap_get_bool(cfg, "enable", false)) {
 bfd_unref(bfd);
@@ -394,20 +392,12 @@ bfd_configure(struct bfd *bfd, const char *name, const 
struct smap *cfg,
 bfd_status_changed(bfd);
 }
 
-old_mult = bfd->mult;
-
-new_mult = smap_get_int(cfg, "mult", DEFAULT_MULT);
+int old_mult = bfd->mult;
+int new_mult = smap_get_int(cfg, "mult", DEFAULT_MULT);
 if (new_mult < 1 || new_mult > 255) {
-VLOG_INFO("Interface %s mult value %d out of range 1-255 changedto %d",
-   name, new_mult, DEFAULT_MULT);
 new_mult = DEFAULT_MULT;
 }
-
-bfd->mult = (uint8_t) new_mult;
-if (new_mult != old_mult) {
-VLOG_INFO("Interface %s mult value %d changed to %d",
-  name, old_mult, new_mult);
-}
+bfd->mult = new_mult;
 
 bfd->oam = smap_get_bool(cfg, "oam", false);
 
@@ -1006,7 +996,7 @@ bfd_set_next_tx(struct bfd *bfd) OVS_REQUIRES(mutex)
 {
 long long int interval = bfd_tx_interval(bfd);
 if (bfd->mult == 1) {
-   interval -= interval * (10 + random_range(16)) / 100;
+interval -= interval * (10 + random_range(16)) / 100;
 } else {
 interval -= interval * random_range(26) / 100;
 }
diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
index 613673ff7465..892f83923617 100644
--- a/vswitchd/vswitch.xml
+++ b/vswitchd/vswitch.xml
@@ -2838,12 +2838,12 @@
 BFD operates by regularly transmitting BFD control messages at a rate
 negotiated independently in each direction.  Each endpoint specifies
 the rate at which it expects to receive control messages, and the rate
-at which it is willing to transmit them.  Open vSwitch uses a detection
-multiplier of three, meaning that an endpoint signals a connectivity
-fault if three consecutive BFD control messages fail to arrive.  In the
-case of a unidirectional connectivity issue, the system not receiving
-BFD control messages signals the problem to its peer in the messages it
-transmits.
+at which it is willing to transmit them.  By default, Open vSwitch uses
+a detection multiplier of three, meaning that an endpoint signals a
+connectivity fault if three consecutive BFD control messages fail to
+arrive.  In the case of a unidirectional connectivity issue, the system
+not receiving BFD control messages signals the problem to its peer in
+the messages it transmits.
   
 
   
@@ -2957,12 +2957,9 @@
 
 
-  From RFC5880 Jun 20 2010 page 28 (bfd.DetectMult)
-  "The desired Detection Time multiplier for BFD Control packetson
-  the local system.  The negotiated Control packet transmission
-  interval, multiplied by this variable, will be the Detection Time
-  for this session (as seen by the remote system).  This variable
-  MUST be a nonzero integer..." Defaults to 3.
+  The BFD detection multiplier, which defaults to 3.  An endpoint
+  signals a connectivity fault if the given number of consecutive BFD
+  control messages fail to arrive.
 
   
 

Re: [ovs-dev] [PATCH V9 04/31] tc: Add tc flower functions

[Joe Stringer]

On 5 June 2017 at 23:01, Roi Dayan  wrote:
>
>
> On 05/06/2017 20:36, Joe Stringer wrote:
>>
>> On 3 June 2017 at 22:22, Roi Dayan  wrote:
>>>
>>>
>>>
>>> On 01/06/2017 20:53, Joe Stringer wrote:


 On 1 June 2017 at 07:39, Roi Dayan  wrote:
>
>
>
>
> On 31/05/2017 03:50, Joe Stringer wrote:
>>
>>
>>
>> On 28 May 2017 at 04:59, Roi Dayan  wrote:
>>>
>>>
>>>
>>> Add tc helper functions to query and manipulate the flower
>>> classifier.
>>>
>>> Signed-off-by: Paul Blakey 
>>> Signed-off-by: Roi Dayan 
>>> ---
>>
>>
>>
>>
>> Again is this co-authored? utilities/checkpatch.py checks for stuff
>> like
>> this.
>>
>> I didn't go through all of the enums and make sure they're all
>> covered, correct types, etc.
>>
>> 
>>
>>> +[TCA_FLOWER_KEY_ENC_IPV4_SRC_MASK] = { .type = NL_A_U32,
>>> .optional
>>> =
>>> true, },
>>> +[TCA_FLOWER_KEY_ENC_IPV4_DST_MASK] = { .type = NL_A_U32,
>>> .optional
>>> =
>>> true, },
>>
>>
>>
>>
>> Line lengths.
>>
>
> ok
>
>> 
>>
>>> +static void
>>> +nl_parse_tcf(const struct tcf_t *tm, struct tc_flower *flower)
>>> +{
>>> +unsigned long long int lastuse = tm->lastuse * 10;
>>
>>
>>
>>
>> Where does the 10 come from? What does it mean? Should we have a
>> #define
>> for it?
>>
>
> we want to convert here jiffies to ms and used some default value.
> as Flavio suggested maybe do it in a macro?
> later I saw in netdev-linux.c the functions read_psched() and
> tc_ticks_to_bytes(). can do a followup commit to refactor those
> somewhere else and use them in tc.c as well.



 Please do.
>>>
>>>
>>>
>>> just to be clear here, is it ok to use a macro for this series
>>> and do the followup commit after this series?
>>
>>
>> That sounds reasonable.
>>
>>> +int
>>> +tc_replace_flower(int ifindex, uint16_t prio, uint32_t handle,
>>> +  struct tc_flower *flower)
>>> +{
>>> +struct ofpbuf request;
>>> +struct tcmsg *tcmsg;
>>> +struct ofpbuf *reply;
>>> +int error = 0;
>>> +size_t basic_offset;
>>> +uint16_t eth_type = (OVS_FORCE uint16_t) flower->key.eth_type;
>>
>>
>>
>>
>> Why does this need forcing?
>>
>
> as eth_type is ove_be16 but tc_make_handle wants unsigned int.
> we get a compilation warning from sparse about incorrect type.
> this is to avoid sparse from failing.



 I see. Should it be unsigned int, then? Rather than casting a
 big-endian value to store a host-endian variable of the same size?

>>>
>>> it's not unsigned int to follow up with the rest of the user space code
>>> that use ovs_be16 for eth_type.
>>> also we are using match_set_dl_type() that expect ovs_be16.
>>
>>
>> The rest of the code stores a big-endian eth_type in an ovs_be16, or
>> host byte-order version in uint16_t. The thing I found surprising in
>> this code was that the big endian version of the ethertype was being
>> placed into a uint16_t without converting to host byte order. In the
>> end, I think what we're trying to achieve is that the second parameter
>> to tc_make_handle() should be a big-endian ethertype but sparse would
>> complain if we passed it directly (because tc_make_handle()'s second
>> argument type isn't ovs_be16). So OVS_FORCE is necessary, though I
>> would have expected it to be used inside the arguments of
>> tc_make_handle().
>>
>
> maybe. that should also apply to tc_get_minor() to return
> ovs_be16 instead of uint.
> in parsing back from netlink to tc_flower we do:
> flower->key.eth_type = (OVS_FORCE ovs_be16) tc_get_minor(tc->tcm_info);

That sounds reasonable to me, although I think that the function may
be used for not just the tcm_info but also tcm_parent.

> but a lot of callers use it for vlog and use %u format.
> so changing it will probably also cause the compiler to complain.

I'm guessing that not all callers assume it's supposed to denote an ethertype.

> I'll skip this for V10 as I don't think this is critical
> and we can do a commit later to update to what will be agreed on
> and update all callers if necessary.

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

Re: [ovs-dev] [PATCH] conntrack : Use Rx checksum offload feature on DPDK ports for conntrack.

[Darrell Ball]

I did a first pass, but I will look thru. it more carefully and test it.
The benefit is smaller than I had hoped, even in a simple case, but the code 
delta is also simple.

Thanks Darrell

On 6/6/17, 3:45 AM, "ovs-dev-boun...@openvswitch.org on behalf of Chandran, 
Sugesh"  wrote:

Ping!. 
Any other comments on this patch??


Regards
_Sugesh


> -Original Message-
> From: Fischetti, Antonio
> Sent: Friday, May 26, 2017 11:05 AM
> To: Chandran, Sugesh ; ovs-
> d...@openvswitch.org
> Subject: RE: [ovs-dev] [PATCH] conntrack : Use Rx checksum offload feature
> on DPDK ports for conntrack.
> 
> Hi Sugesh,
> it looks good to me, it makes sense to leverage the csum info when 
present.
> 
> I've tested it with the firewall rules - see below for details - I saw a 
~+3%
> improvement in my testbench with 10 UDP connections.
> 
> Traffic Gen: IXIA IxExplorer
> 10 UDP different flows, 64B pkts
> 
> Original OvS:   3.0 Mpps
> With this Patch: 3.1 Mpps
> 
> 
> Below some details of my testbench.
> 
> ===
> 
> BUILD
> -
> make -j 28 CFLAGS="-O2 -march=native -g"
> 
> #I didn't use intrinsics, I expect in that case the benefit will be 
smaller.
> 
> FLOW DUMP
> -
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=0.064s, table=0, n_packets=0, n_bytes=0, idle_age=0,
> priority=100,ct_state=-trk,ip actions=ct(table=1)  cookie=0x0,
> duration=0.075s, table=0, n_packets=0, n_bytes=0, idle_age=0,
> priority=10,arp actions=NORMAL  cookie=0x0, duration=0.085s, table=0,
> n_packets=0, n_bytes=0, idle_age=0, priority=1 actions=drop  cookie=0x0,
> duration=0.054s, table=1, n_packets=0, n_bytes=0, idle_age=0,
> ct_state=+new+trk,ip,in_port=1 actions=ct(commit),output:2  cookie=0x0,
> duration=0.033s, table=1, n_packets=0, n_bytes=0, idle_age=0,
> ct_state=+new+trk,ip,in_port=2 actions=drop  cookie=0x0, duration=0.043s,
> table=1, n_packets=0, n_bytes=0, idle_age=0,
> ct_state=+est+trk,ip,in_port=1 actions=output:2  cookie=0x0,
> duration=0.023s, table=1, n_packets=0, n_bytes=0, idle_age=0,
> ct_state=+est+trk,ip,in_port=2 actions=output:1
> 
> HugePages_Total:   20480
> HugePages_Free:20480
> HugePages_Rsvd:0
> HugePages_Surp:0
> ___
> DPDK: HEAD detached at v16.11
> OvS:  On my local branch ConnTrack_01
> ___
> 
>PID PSR COMMAND %CPU
>  20509   0 ovsdb-server 0.0
>  20522   2 ovs-vswitchd78.1
>  20522   4 pmd62   80.8
>  20522   5 pmd61   71.6
> 
> PDM threads:  2
> 
> configured_tx_queues=3,
> configured_tx_queues=3,
> 
> 
> Regards,
> Antonio
> 
> 
> Acked-by: Antonio Fischetti 
> 
> 
> > -Original Message-
> > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > boun...@openvswitch.org] On Behalf Of Sugesh Chandran
> > Sent: Thursday, May 25, 2017 10:11 PM
> > To: ovs-dev@openvswitch.org
> > Subject: [ovs-dev] [PATCH] conntrack : Use Rx checksum offload feature
> > on DPDK ports for conntrack.
> >
> > Avoiding checksum validation in conntrack module if it is already
> > verified in DPDK physical NIC ports.
> >
> > Signed-off-by: Sugesh Chandran 
> > ---
> >  lib/conntrack.c | 58
> > 
> > -
> >  1 file changed, 37 insertions(+), 21 deletions(-)
> >
> > diff --git a/lib/conntrack.c b/lib/conntrack.c index cb30ac7..af6a372
> > 100644
> > --- a/lib/conntrack.c
> > +++ b/lib/conntrack.c
> > @@ -642,10 +642,13 @@ extract_l3_ipv6(struct conn_key *key, const void
> > *data, size_t size,
> >
> >  static inline bool
> >  checksum_valid(const struct conn_key *key, const void *data, size_t 
size,
> > -   const void *l3)
> > +   const void *l3, bool validate_checksum)
> >  {
> >  uint32_t csum = 0;
> >
> > +if (!validate_checksum) {
> > +   return true;
> > +}
> >  if (key->dl_type == htons(ETH_TYPE_IP)) {
> >  csum = packet_csum_pseudoheader(l3);
> >  } else if (key->dl_type == htons(ETH_TYPE_IPV6)) { @@ -661,7
> > +664,7 @@ checksum_valid(const struct conn_key *key, const void *data,
> > size_t size,
> >
> >  static inline bool
> >  check_l4_tcp(const struct conn_key *key, const void *data, size_t size,
> > - const void *l3)

[ovs-dev] [PATCH] bfd: Detect Multiplier configuration

[Szucs Gabor]

Mult value (bfd.DetectMult in RFC5880) is hard-coded and equal to 3 in
current openvswitch. As a consequence remote and local mult is the same.

In this commit the mult (Detect Multiplier/bfd.DetectMult/Detect Mult)
can be set on each interface setting the mult= in bfd Column
in Interface table of ovsdb database.
Example:
ovs-vsctl set Interface p1 bfd:mult=4
sets mult=4 on p1 interface

The modification based on RFC5880 June 2010.
The relevant paragraphs are:
4.1. Generic BFD Control Packet Format
6.8.4. Calculating the Detection Time
6.8.7. Transmitting BFD Control Packets
6.8.12. Detect Multiplier Change

The mult value is set to default 3 if it is not set in ovsdb. This
provides backward compatibility to previous openvswitch behaviour.
The RFC5880 says in 6.8.1 that DetectMult shall be a non-zero integer.
In RFC5880 4.1. "Detect Mult" has 8 bit length and is declared
as a 8 bit unsigned integer in bfd.c.
Consequently mult value shall be greater than 0 and less then 256.
In case of incorrect mult value is given in ovsdb the default value (3)
will be set and a message is logged into ovs-vswitchd.log on that.
Local or remote mult value change is also logged into ovs-vswitchd.log.

Since remote and local mult is not the same calculation of detect time
has been changed. Due to RFC5880 6.8.4 Detection Time is calculated using
mult value of the remote system.
Detection time is recalculated due to remote mult change.

The BFD packet transmission jitter is different in case of mult=1
due to RFC5880 6.8.7. The maximum interval of the transmitted bfd packet
is 90% of the transmission interval.

The value of remote mult is printed in the last line of the output of
ovs-appctl bfd/show command with label: Remote Detect Mult.

There is a feature in openvswitch connected with forwarding_if_rx that
is not the part of RFC5880. This feature also uses mult value but it is
not specified if local or remote since it was the
same in original code. The relevant description in code:
   /* When 'bfd->forwarding_if_rx' is set, at least one bfd control packet
 * is required to be received every 100 * bfd->cfg_min_rx.  If bfd
 * control packet is not received within this interval, even if data
 * packets are received, the bfd->forwarding will still be false. */

Due to lack of specification local mult value is used for calculation of
forwarding_if_rx_detect_time. This detect time is recalculated at mult
change if forwarding_if_rx is true and bfd is in UP state.

A new unit test has been added: "bfd - Edit the Detect Mult values"
The following cases are tested:
- Without setting mult the mult will be the default value (3).
- The setting of the lowest (1) and highest (255) valid mult value
  and the detection of remote mult value.
- The setting of out of range mult value (0, 256) in ovsdb results
  sets default value in ovs-vswitchd
- Clearing non default mult value from ovsdb results sets default
  value in ovs-vswitchd.

Signed-off-by: Gábor Szűcs 
---
diff --git a/lib/bfd.c b/lib/bfd.c
index 383be20..eaf1821 100644
--- a/lib/bfd.c
+++ b/lib/bfd.c
@@ -146,6 +146,7 @@ BUILD_ASSERT_DECL(BFD_PACKET_LEN == sizeof(struct msg));
 #define VERS_SHIFT 5
 #define STATE_MASK 0xC0
 #define FLAGS_MASK 0x3f
+#define DEFAULT_MULT 3
 
 struct bfd {
 struct hmap_node node;/* In 'all_bfds'. */
@@ -155,6 +156,7 @@ struct bfd {
 
 bool cpath_down;  /* Concatenated Path Down. */
 uint8_t mult; /* bfd.DetectMult. */
+uint8_t rmt_mult; /* Remote bfd.DetectMult. */
 
 struct netdev *netdev;
 uint64_t rx_packets;  /* Packets received by 'netdev'. */
@@ -354,6 +356,8 @@ bfd_configure(struct bfd *bfd, const char *name, const 
struct smap *cfg,
 bool need_poll = false;
 bool cfg_min_rx_changed = false;
 bool cpath_down, forwarding_if_rx;
+int new_mult;
+int old_mult;
 
 if (!cfg || !smap_get_bool(cfg, "enable", false)) {
 bfd_unref(bfd);
@@ -370,7 +374,8 @@ bfd_configure(struct bfd *bfd, const char *name, const 
struct smap *cfg,
 
 bfd->diag = DIAG_NONE;
 bfd->min_tx = 1000;
-bfd->mult = 3;
+bfd->rmt_mult = 0;
+bfd->mult = DEFAULT_MULT;
 ovs_refcount_init(>ref_cnt);
 bfd->netdev = netdev_ref(netdev);
 bfd->rx_packets = bfd_rx_packets(bfd);
@@ -389,6 +394,21 @@ bfd_configure(struct bfd *bfd, const char *name, const 
struct smap *cfg,
 bfd_status_changed(bfd);
 }
 
+old_mult = bfd->mult;
+
+new_mult = smap_get_int(cfg, "mult", DEFAULT_MULT);
+if (new_mult < 1 || new_mult > 255) {
+VLOG_INFO("Interface %s mult value %d out of range 1-255 changedto %d",
+   name, new_mult, DEFAULT_MULT);
+new_mult = DEFAULT_MULT;
+}
+
+bfd->mult = (uint8_t) new_mult;
+if (new_mult != old_mult) {
+VLOG_INFO("Interface %s mult value %d changed to %d",
+  name, old_mult, new_mult);
+  

Re: [ovs-dev] Try to insert new function

[Ben Pfaff]

On Tue, Jun 06, 2017 at 04:28:08PM +0200, Joaquin Alvarez Horcajo wrote:
> we try to insert a new function to generate autonomus path, any have a flow
> char about the process packet into the demond?

Maybe you should be using an OpenFlow controller instead of modifying
OVS.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v3] Update relevant artifacts to add support for DPDK 17.05.

[Kavanagh, Mark B]

>From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] 
>On Behalf Of
>mweglicx
>Sent: Monday, June 5, 2017 1:31 PM
>To: d...@openvswitch.org
>Subject: [ovs-dev] [PATCH v3] Update relevant artifacts to add support for 
>DPDK 17.05.
>
>Following changes are applied:
>- netdev-dpdk: Changes required by DPDK API modifications.
>- doc: Because of DPDK API changes, backward compatibility
>  with previous DPDK releases will be broken, thus all
>  relevant documentation entries are updated.
>- .travis: DPDK version change from 16.11.1 to 17.05.
>- rhel/openvswitch-fedora.spec.in: DPDK version change
>  from 16.11 to 17.05.
>
>v1->v2: Patch rework based on minor review comments.
>v2->v3: VHOST user client reconfiguration corrected.

Hi Michal,

This patch doesn't apply cleanly to the HEAD of master (currently, 956ffcb) - I 
had to use the '-3' flag to initiate three-way merge in order to get it to 
apply; could probably do with a rebase.
Other than that, a few minor comments inline.

Thanks,
Mark


>
>Signed-off-by: Michal Weglicki 
>---
> .travis/linux-build.sh   |   2 +-
> Documentation/intro/install/dpdk.rst |   8 +-
> Documentation/topics/dpdk/vhost-user.rst |   8 +-
> lib/netdev-dpdk.c| 133 +++
> rhel/openvswitch-fedora.spec.in  |   2 +-
> tests/dpdk/ring_client.c |   6 +-
> 6 files changed, 93 insertions(+), 66 deletions(-)
>
>diff --git a/.travis/linux-build.sh b/.travis/linux-build.sh
>index 8750d68..ec15fd8 100755
>--- a/.travis/linux-build.sh
>+++ b/.travis/linux-build.sh
>@@ -80,7 +80,7 @@ fi
>
> if [ "$DPDK" ]; then
> if [ -z "$DPDK_VER" ]; then
>-DPDK_VER="16.11.1"
>+DPDK_VER="17.05"
> fi
> install_dpdk $DPDK_VER
> if [ "$CC" = "clang" ]; then
>diff --git a/Documentation/intro/install/dpdk.rst 
>b/Documentation/intro/install/dpdk.rst
>index e83f852..536450b 100644
>--- a/Documentation/intro/install/dpdk.rst
>+++ b/Documentation/intro/install/dpdk.rst
>@@ -40,7 +40,7 @@ Build requirements
> In addition to the requirements described in :doc:`general`, building Open
> vSwitch with DPDK will require the following:
>
>-- DPDK 16.11
>+- DPDK 17.05
>
> - A `DPDK supported NIC`_
>
>@@ -69,9 +69,9 @@ Install DPDK
> #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``::
>
>$ cd /usr/src/
>-   $ wget http://fast.dpdk.org/rel/dpdk-16.11.1.tar.xz
>-   $ tar xf dpdk-16.11.1.tar.xz
>-   $ export DPDK_DIR=/usr/src/dpdk-stable-16.11.1
>+   $ wget http://fast.dpdk.org/rel/dpdk-17.05.tar.xz
>+   $ tar xf dpdk-17.05.tar.xz
>+   $ export DPDK_DIR=/usr/src/dpdk-17.05
>$ cd $DPDK_DIR
>
> #. (Optional) Configure DPDK as a shared library
>diff --git a/Documentation/topics/dpdk/vhost-user.rst 
>b/Documentation/topics/dpdk/vhost-
>user.rst
>index ba22684..71098fd 100644
>--- a/Documentation/topics/dpdk/vhost-user.rst
>+++ b/Documentation/topics/dpdk/vhost-user.rst
>@@ -278,9 +278,9 @@ To begin, instantiate a guest as described in 
>:ref:`dpdk-vhost-user` or
> DPDK sources to VM and build DPDK::
>
> $ cd /root/dpdk/
>-$ wget http://fast.dpdk.org/rel/dpdk-16.11.1.tar.xz
>-$ tar xf dpdk-16.11.1.tar.xz
>-$ export DPDK_DIR=/root/dpdk/dpdk-stable-16.11.1
>+$ wget http://fast.dpdk.org/rel/dpdk-17.05.tar.xz
>+$ tar xf dpdk-17.05.tar.xz
>+$ export DPDK_DIR=/root/dpdk/dpdk-17.05
> $ export DPDK_TARGET=x86_64-native-linuxapp-gcc
> $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET
> $ cd $DPDK_DIR
>@@ -364,7 +364,7 @@ Sample XML
> 
> 
>   
>-  
>+  
>   
>   
> 
>diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
>index 609b8da..212a404 100644
>--- a/lib/netdev-dpdk.c
>+++ b/lib/netdev-dpdk.c
>@@ -22,6 +22,9 @@
> #include 
> #include 
> #include 
>+#include 
>+#include 
>+#include 
>
> #include 
> #include 
>@@ -31,7 +34,7 @@
> #include 
> #include 
> #include 
>-#include 
>+#include 
>
> #include "dirs.h"
> #include "dp-packet.h"
>@@ -56,6 +59,8 @@
> #include "timeval.h"
> #include "unixctl.h"
>
>+enum {VIRTIO_RXQ, VIRTIO_TXQ, VIRTIO_QNUM};
>+
> VLOG_DEFINE_THIS_MODULE(netdev_dpdk);
> static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 20);
>
>@@ -164,6 +169,21 @@ static const struct rte_eth_conf port_conf = {
> },
> };
>
>+/*
>+ * These callbacks allow virtio-net devices to be added to vhost ports when
>+ * configuration has been fully completed.
>+ */
>+static int new_device(int vid);
>+static void destroy_device(int vid);
>+static int vring_state_changed(int vid, uint16_t queue_id, int enable);
>+static const struct vhost_device_ops virtio_net_device_ops =
>+{
>+.new_device =  new_device,
>+.destroy_device = destroy_device,
>+.vring_state_changed = vring_state_changed,
>+.features_changed = NULL
>+};
>+
> enum { DPDK_RING_SIZE = 256 };
> 

[ovs-dev] Try to insert new function

[Joaquin Alvarez Horcajo]

Hi

we try to insert a new function to generate autonomus path, any have a 
flow char about the process packet into the demond?



thanks

JAH


---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus

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

Re: [ovs-dev] [ovs-discuss] Enabling "Datapath does not support ct_zone" for LEDE tplink archer 2600 target board

[Aaron Conole]

Jimmy Carter  writes:

> Hi
>
> I am using ovs 2.7.0 in openwrt with kernel version 4.9.x for LEDE tplink 
> archer 2600 target board
> But I see ovs logs like "Datapath does not support ct_zone"
>
> What packages are required to support ct zone ?

I think you need a kernel that has ovs+conntrack support built in.  I
believe the initial patches were added as part of 4.4 or 4.5.  Do you
have these patches enabled in your kernel?

> Please advise
>
> Thanks
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH V9 14/31] dpif-netlink: Use netdev flow put api to insert a flow

[Roi Dayan]

On 02/06/2017 23:08, Flavio Leitner wrote:

On Sun, May 28, 2017 at 02:59:56PM +0300, Roi Dayan wrote:

From: Paul Blakey 

Using the new netdev flow api operate will now try and
offload flows to the relevant netdev of the input port.
Other operate methods flows will come in later patches.


[...]


diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
index 6f36b5e..8438e71 100644
--- a/lib/dpif-netlink.c
+++ b/lib/dpif-netlink.c

[...]


 static void
-dpif_netlink_operate(struct dpif *dpif_, struct dpif_op **ops, size_t n_ops)
+dbg_print_flow(const struct nlattr *key, size_t key_len,
+   const struct nlattr *mask, size_t mask_len,
+   const struct nlattr *actions, size_t actions_len,
+   const ovs_u128 *ufid,
+   const char *op)
+{



perhaps:
  if (VLOG_IS_DBG_ENABLED()) {


+struct ds s;
+
+ds_init();
+ds_put_cstr(, op);
+ds_put_cstr(, " (");
+odp_format_ufid(ufid, );
+ds_put_cstr(, ")");
+if (key_len) {
+ds_put_cstr(, "\nflow (verbose): ");
+odp_flow_format(key, key_len, mask, mask_len, NULL, , true);
+ds_put_cstr(, "\nflow: ");
+odp_flow_format(key, key_len, mask, mask_len, NULL, , false);
+}
+ds_put_cstr(, "\nactions: ");
+format_odp_actions(, actions, actions_len);
+VLOG_DBG("\n%s", ds_cstr());
+ds_destroy();

 }

to avoid those operations on every flow put?
or maybe on the caller to avoid the function call.



right. maybe not an important change? in a later commit we remove
this function and refactor log_flow_put_message() from dpif.c and
use that. "dpif-netlink: Use dpif logging functions"





+}
+
+static int
+try_send_to_netdev(struct dpif_netlink *dpif, struct dpif_op *op)
 {
-struct dpif_netlink *dpif = dpif_netlink_cast(dpif_);
+int err = EOPNOTSUPP;

+switch (op->type) {
+case DPIF_OP_FLOW_PUT: {
+struct dpif_flow_put *put = >u.flow_put;
+
+if (!put->ufid) {
+break;
+}
+dbg_print_flow(put->key, put->key_len, put->mask, put->mask_len,
+   put->actions, put->actions_len, put->ufid,
+   (put->flags & DPIF_FP_MODIFY ? "PUT(MODIFY)" : "PUT"));
+err = parse_flow_put(dpif, put);
+break;
+}
+case DPIF_OP_FLOW_DEL:
+case DPIF_OP_FLOW_GET:
+case DPIF_OP_EXECUTE:
+default:
+break;
+}
+
+return err;
+}
+
+static void
+dpif_netlink_operate_chunks(struct dpif_netlink *dpif, struct dpif_op **ops,
+size_t n_ops)
+{
 while (n_ops > 0) {
 size_t chunk = dpif_netlink_operate__(dpif, ops, n_ops);
+
 ops += chunk;
 n_ops -= chunk;
 }
 }

+static void
+dpif_netlink_operate(struct dpif *dpif_, struct dpif_op **ops, size_t n_ops)
+{
+struct dpif_netlink *dpif = dpif_netlink_cast(dpif_);
+struct dpif_op *new_ops[OPERATE_MAX_OPS];
+int count = 0;
+int i = 0;
+int err = 0;
+
+if (netdev_is_flow_api_enabled()) {
+while (n_ops > 0) {
+count = 0;
+
+while (n_ops > 0 && count < OPERATE_MAX_OPS) {
+struct dpif_op *op = ops[i++];
+
+err = try_send_to_netdev(dpif, op);
+if (err && err != EEXIST) {
+new_ops[count++] = op;
+} else {
+op->error = err;
+}
+
+n_ops--;
+}
+
+dpif_netlink_operate_chunks(dpif, new_ops, count);
+}
+
+return;
+}
+
+dpif_netlink_operate_chunks(dpif, ops, n_ops);
+}
+


The above could be:

if (netdev_is_flow_api_enabled()) {
...
} else {
   dpif_netlink_operate_chunks(dpif, ops, n_ops);
}

   return;
}


Otherwise the patch looks good to me.



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

Re: [ovs-dev] [PATCH v1 1/4] ovn: l3ha, handling of multiple gateways

[Liran Schour]

Hi Miguel,

I was thinking of using the add group table OVS action with type=select.
Put each gateway into a dedicated bucket and then OVS will be able to load 
balance the traffic natively regardless if we will choose to do that 
matching L2 or L3.

We should think about the cons and pros of L2 vs. L3 balancing.

Am I clearer now?
- Liran



From:   Miguel Angel Ajo Pelayo 
To: Liran Schour 
Cc: ovs dev 
Date:   06/06/2017 12:34 PM
Subject:Re: [ovs-dev] [PATCH v1 1/4] ovn: l3ha, handling of 
multiple gateways



Hi Liran,

For now we're focusing on Active/Backup implementation, 

A very brief introduction to the active/active problem can be found
here [1]. 

I'm not an expert on this area and I haven't investigated yet. 
I'd guess we could have several options, like:

* handling it at L3 level (ECMP),

Or

* handling it at L2 level (I guess that's what you propose), a naive
understanding takes me to some complexities:
   - balancing traffic across the gateways, we can do that in openflow
 (bundle/multipath actions?)
   - announcing (ARP) in a way that any Active gateway could
 handle incoming traffic (similar to link aggregation), but that's
 also complex because we may need to keep connection tracking in
 sync across gateways.

Again, I'm not an expert on this area, but if we gave good ideas
it'd be great to document them around [1]

Best regards,
Miguel Ángel Ajo


[1] 
https://github.com/openvswitch/ovs/blob/master/Documentation/topics/high-availability.rst#fully-active-active-ha

On Mon, Jun 5, 2017 at 1:20 PM, Liran Schour  wrote:
ovs-dev-boun...@openvswitch.org wrote on 02/06/2017 03:31:41 PM:

> From: Miguel Angel Ajo 
> 
> This patch handles multiple gateways with priorities in chassisredirect
> ports, any gateway with a chassis redirect port will implement the
> rules to de-encapsulate incomming packets for such port.
> 
> And hosts targetting a remote chassisredirect port will setup a
> bundle(active_backup, ..) action to each tunnel port, in the given
> priority order.
> 

Hi Miguel,

I was looking on your recent pathces on OVN L3HA (not a deep review ;-) 
 and a question came to my mind, maybe you will be able to answer :-)

In case of a full active-active solution. Why not to use the load 
balancing built in feature of OVS to distribute traffic between gateways?
Maybe I miss something here...

Thanks,
- Liran




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

Re: [ovs-dev] [patch_v1] dpdk: Fix device cleanup.

[Ilya Maximets]

On 06.06.2017 11:30, Darrell Ball wrote:
> On port deletion, device resources cannot be cleaned
> up if the device was attached when vswitchd was started.
> The issue is mainly due to introduction of the 'attached'
> field for the netdev_dpdk device context.  The logic
> setting the 'attached' field did not include startup
> handling.  The use of an extra 'attached' field was
> introduced to guard against detaching a device that could
> not be detached, but should not be necessary as the rte and
> eal keep the attached state, as they must, and also filter
> trying to detach a device that is not detachable.  If
> there were any bugs in this regard, which I did not find
> with basic testing, then they should be fixed in rte/eal.

Why you want to free resources of these devices?
It's, actually, was a default behaviour of OVS for years.
If you want to detach hotplugable devices than you may just not
attach them using cmdline. Not hotplugable devices will not
be detached anyway. 

>From the other side this patch will allow following scenario
for not detachable devices:

- add_port(05.00.0)
- configure()
- stop()
- close()
- detach(05.00.0) -> Failure
- add_port(05.00.0)
- configure()
- start()

At this point OvS will get closed device by name and will
try to configure it and start again.

My concern is that we can't be sure that it will continue
work properly after close.

According to DPDK API, *device can not be started back after
close*. Unfortunately, there is no documentation about
trying to reinitialize closed device. So, we can't
rely on your assumption that device will work properly
after that.

> Fixes: 5dcde09c80a8 ("netdev-dpdk: Fix device leak on port deletion.")
> CC: Ilya Maximets 
> Signed-off-by: Darrell Ball 
> ---
>  lib/netdev-dpdk.c | 14 +++---
>  1 file changed, 3 insertions(+), 11 deletions(-)
> 
> diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c
> index b770b70..753345d 100644
> --- a/lib/netdev-dpdk.c
> +++ b/lib/netdev-dpdk.c
> @@ -365,9 +365,6 @@ struct netdev_dpdk {
>  /* Device arguments for dpdk ports */
>  char *devargs;
>  
> -/* If true, device was attached by rte_eth_dev_attach(). */
> -bool attached;
> -
>  /* In dpdk_list. */
>  struct ovs_list list_node OVS_GUARDED_BY(dpdk_mutex);
>  
> @@ -862,7 +859,6 @@ common_construct(struct netdev *netdev, dpdk_port_t 
> port_no,
>  dev->max_packet_len = MTU_TO_FRAME_LEN(dev->mtu);
>  ovsrcu_index_init(>vid, -1);
>  dev->vhost_reconfigured = false;
> -dev->attached = false;
>  
>  ovsrcu_init(>qos_conf, NULL);
>  
> @@ -1016,7 +1012,7 @@ netdev_dpdk_destruct(struct netdev *netdev)
>  
>  rte_eth_dev_stop(dev->port_id);
>  
> -if (dev->attached) {
> +if (rte_eth_dev_is_valid_port(dev->port_id)) {
>  rte_eth_dev_close(dev->port_id);
>  if (rte_eth_dev_detach(dev->port_id, devname) < 0) {
>  VLOG_ERR("Device '%s' can not be detached", dev->devargs);
> @@ -1136,8 +1132,7 @@ netdev_dpdk_lookup_by_port_id(dpdk_port_t port_id)
>  }
>  
>  static dpdk_port_t
> -netdev_dpdk_process_devargs(struct netdev_dpdk *dev,
> -const char *devargs, char **errp)
> +netdev_dpdk_process_devargs(const char *devargs, char **errp)
>  {
>  /* Get the name up to the first comma. */
>  char *name = xmemdup0(devargs, strcspn(devargs, ","));
> @@ -1148,8 +1143,6 @@ netdev_dpdk_process_devargs(struct netdev_dpdk *dev,
>  || !rte_eth_dev_is_valid_port(new_port_id)) {
>  /* Device not found in DPDK, attempt to attach it */
>  if (!rte_eth_dev_attach(devargs, _port_id)) {
> -/* Attach successful */
> -dev->attached = true;
>  VLOG_INFO("Device '%s' attached to DPDK", devargs);
>  } else {
>  /* Attach unsuccessful */
> @@ -1236,8 +1229,7 @@ netdev_dpdk_set_config(struct netdev *netdev, const 
> struct smap *args,
>   * is valid */
>  if (!(dev->devargs && !strcmp(dev->devargs, new_devargs)
> && rte_eth_dev_is_valid_port(dev->port_id))) {
> -dpdk_port_t new_port_id = netdev_dpdk_process_devargs(dev,
> -  
> new_devargs,
> +dpdk_port_t new_port_id = 
> netdev_dpdk_process_devargs(new_devargs,
>errp);
>  if (!rte_eth_dev_is_valid_port(new_port_id)) {
>  err = EINVAL;
> 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH] conntrack : Use Rx checksum offload feature on DPDK ports for conntrack.

[Chandran, Sugesh]

Ping!. 
Any other comments on this patch??


Regards
_Sugesh


> -Original Message-
> From: Fischetti, Antonio
> Sent: Friday, May 26, 2017 11:05 AM
> To: Chandran, Sugesh ; ovs-
> d...@openvswitch.org
> Subject: RE: [ovs-dev] [PATCH] conntrack : Use Rx checksum offload feature
> on DPDK ports for conntrack.
> 
> Hi Sugesh,
> it looks good to me, it makes sense to leverage the csum info when present.
> 
> I've tested it with the firewall rules - see below for details - I saw a ~+3%
> improvement in my testbench with 10 UDP connections.
> 
> Traffic Gen: IXIA IxExplorer
> 10 UDP different flows, 64B pkts
> 
> Original OvS:   3.0 Mpps
> With this Patch: 3.1 Mpps
> 
> 
> Below some details of my testbench.
> 
> ===
> 
> BUILD
> -
> make -j 28 CFLAGS="-O2 -march=native -g"
> 
> #I didn't use intrinsics, I expect in that case the benefit will be smaller.
> 
> FLOW DUMP
> -
> NXST_FLOW reply (xid=0x4):
>  cookie=0x0, duration=0.064s, table=0, n_packets=0, n_bytes=0, idle_age=0,
> priority=100,ct_state=-trk,ip actions=ct(table=1)  cookie=0x0,
> duration=0.075s, table=0, n_packets=0, n_bytes=0, idle_age=0,
> priority=10,arp actions=NORMAL  cookie=0x0, duration=0.085s, table=0,
> n_packets=0, n_bytes=0, idle_age=0, priority=1 actions=drop  cookie=0x0,
> duration=0.054s, table=1, n_packets=0, n_bytes=0, idle_age=0,
> ct_state=+new+trk,ip,in_port=1 actions=ct(commit),output:2  cookie=0x0,
> duration=0.033s, table=1, n_packets=0, n_bytes=0, idle_age=0,
> ct_state=+new+trk,ip,in_port=2 actions=drop  cookie=0x0, duration=0.043s,
> table=1, n_packets=0, n_bytes=0, idle_age=0,
> ct_state=+est+trk,ip,in_port=1 actions=output:2  cookie=0x0,
> duration=0.023s, table=1, n_packets=0, n_bytes=0, idle_age=0,
> ct_state=+est+trk,ip,in_port=2 actions=output:1
> 
> HugePages_Total:   20480
> HugePages_Free:20480
> HugePages_Rsvd:0
> HugePages_Surp:0
> ___
> DPDK: HEAD detached at v16.11
> OvS:  On my local branch ConnTrack_01
> ___
> 
>PID PSR COMMAND %CPU
>  20509   0 ovsdb-server 0.0
>  20522   2 ovs-vswitchd78.1
>  20522   4 pmd62   80.8
>  20522   5 pmd61   71.6
> 
> PDM threads:  2
> 
> configured_tx_queues=3,
> configured_tx_queues=3,
> 
> 
> Regards,
> Antonio
> 
> 
> Acked-by: Antonio Fischetti 
> 
> 
> > -Original Message-
> > From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> > boun...@openvswitch.org] On Behalf Of Sugesh Chandran
> > Sent: Thursday, May 25, 2017 10:11 PM
> > To: ovs-dev@openvswitch.org
> > Subject: [ovs-dev] [PATCH] conntrack : Use Rx checksum offload feature
> > on DPDK ports for conntrack.
> >
> > Avoiding checksum validation in conntrack module if it is already
> > verified in DPDK physical NIC ports.
> >
> > Signed-off-by: Sugesh Chandran 
> > ---
> >  lib/conntrack.c | 58
> > 
> > -
> >  1 file changed, 37 insertions(+), 21 deletions(-)
> >
> > diff --git a/lib/conntrack.c b/lib/conntrack.c index cb30ac7..af6a372
> > 100644
> > --- a/lib/conntrack.c
> > +++ b/lib/conntrack.c
> > @@ -642,10 +642,13 @@ extract_l3_ipv6(struct conn_key *key, const void
> > *data, size_t size,
> >
> >  static inline bool
> >  checksum_valid(const struct conn_key *key, const void *data, size_t size,
> > -   const void *l3)
> > +   const void *l3, bool validate_checksum)
> >  {
> >  uint32_t csum = 0;
> >
> > +if (!validate_checksum) {
> > +   return true;
> > +}
> >  if (key->dl_type == htons(ETH_TYPE_IP)) {
> >  csum = packet_csum_pseudoheader(l3);
> >  } else if (key->dl_type == htons(ETH_TYPE_IPV6)) { @@ -661,7
> > +664,7 @@ checksum_valid(const struct conn_key *key, const void *data,
> > size_t size,
> >
> >  static inline bool
> >  check_l4_tcp(const struct conn_key *key, const void *data, size_t size,
> > - const void *l3)
> > + const void *l3, bool validate_checksum)
> >  {
> >  const struct tcp_header *tcp = data;
> >  if (size < sizeof *tcp) {
> > @@ -673,12 +676,12 @@ check_l4_tcp(const struct conn_key *key, const
> > void *data, size_t size,
> >  return false;
> >  }
> >
> > -return checksum_valid(key, data, size, l3);
> > +return checksum_valid(key, data, size, l3, validate_checksum);
> >  }
> >
> >  static inline bool
> >  check_l4_udp(const struct conn_key *key, const void *data, size_t size,
> > - const void *l3)
> > + const void *l3, bool validate_checksum)
> >  {
> >  const struct udp_header *udp = data;
> >  if (size < sizeof *udp) {
> > @@ -692,20 +695,23 @@ check_l4_udp(const struct conn_key *key, const
> > void *data, size_t size,
> >
> >  /* Validation must be skipped if checksum is 0 on IPv4 

[ovs-dev] [PATCH v3] Copy external_ids from Logical_Switch_Port to SB database

[Daniel Alvarez]

This patch makes ovn-northd copy all string-string pairs in
external_ids column of the Logical_Switch_Port table in Northbound
database to the equivalent column of the Port_Binding table in
Southbound database.

OpenStack Neutron will add some useful data to NB database that can be
later read by networking-ovn-metadata-agent without the need of
maintaining a connection to NB database. This data would include
the CIDR's of a port or the project and device ID's which are needed
when talking to Nova to request metadata.

Signed-off-by: Daniel Alvarez 
---
 ovn/northd/ovn-northd.c | 11 +++
 ovn/ovn-nb.xml  | 11 ++-
 ovn/ovn-sb.xml  | 11 ++-
 3 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 5914988..a063a05 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -1814,10 +1814,13 @@ ovn_port_update_sbrec(const struct ovn_port *op,
op->nbsp->n_addresses);
 
 struct smap ids = SMAP_INITIALIZER();
-const char *name = smap_get(>nbsp->external_ids,
-"neutron:port_name");
-if (name && name[0]) {
-smap_add(, "name", name);
+smap_clone(, >nbsp->external_ids);
+const char *name = smap_get(, "neutron:port_name");
+if (name) {
+smap_remove(, "neutron:port_name");
+if (name[0]) {
+smap_add(, "name", name);
+}
 }
 sbrec_port_binding_set_external_ids(op->sb, );
 }
diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
index eb348fe..7bb322f 100644
--- a/ovn/ovn-nb.xml
+++ b/ovn/ovn-nb.xml
@@ -848,7 +848,16 @@
 
 
   
-See External IDs at the beginning of this document.
+
+  See External IDs at the beginning of this document.
+
+
+
+  The ovn-northd program copies all these pairs into the
+   column of the
+   table in 
+  database.
+
   
 
   
diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml
index f3c3212..0e0fe12 100644
--- a/ovn/ovn-sb.xml
+++ b/ovn/ovn-sb.xml
@@ -2179,7 +2179,16 @@ tcp.flags = RST;
 
 
   
-See External IDs at the beginning of this document.
+
+  See External IDs at the beginning of this document.
+
+
+
+  The ovn-northd program populates this column with
+  all entries into the  column of the
+   table of the
+   database.
+
   
 
   
-- 
1.8.3.1

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

Re: [ovs-dev] [PATCH v1 1/4] ovn: l3ha, handling of multiple gateways

[Miguel Angel Ajo Pelayo]

Hi Liran,

For now we're focusing on Active/Backup implementation,

A very brief introduction to the active/active problem can be found
here [1].

I'm not an expert on this area and I haven't investigated yet.
I'd guess we could have several options, like:

* handling it at L3 level (ECMP),

Or

* handling it at L2 level (I guess that's what you propose), a naive
understanding takes me to some complexities:
   - balancing traffic across the gateways, we can do that in openflow
 (bundle/multipath actions?)
   - announcing (ARP) in a way that any Active gateway could
 handle incoming traffic (similar to link aggregation), but that's
 also complex because we may need to keep connection tracking in
 sync across gateways.

Again, I'm not an expert on this area, but if we gave good ideas
it'd be great to document them around [1]

Best regards,
Miguel Ángel Ajo


[1]
https://github.com/openvswitch/ovs/blob/master/Documentation/topics/high-availability.rst#fully-active-active-ha

On Mon, Jun 5, 2017 at 1:20 PM, Liran Schour  wrote:

> ovs-dev-boun...@openvswitch.org wrote on 02/06/2017 03:31:41 PM:
>
> > From: Miguel Angel Ajo 
> >
> > This patch handles multiple gateways with priorities in chassisredirect
> > ports, any gateway with a chassis redirect port will implement the
> > rules to de-encapsulate incomming packets for such port.
> >
> > And hosts targetting a remote chassisredirect port will setup a
> > bundle(active_backup, ..) action to each tunnel port, in the given
> > priority order.
> >
>
> Hi Miguel,
>
> I was looking on your recent pathces on OVN L3HA (not a deep review ;-)
>  and a question came to my mind, maybe you will be able to answer :-)
>
> In case of a full active-active solution. Why not to use the load
> balancing built in feature of OVS to distribute traffic between gateways?
> Maybe I miss something here...
>
> Thanks,
> - Liran
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev