Re: [ovs-dev] [PATCH v2 ovn 3/3] binding: fix localnet QoS configuration after I-P

[Numan Siddique]

On Mon, Sep 21, 2020 at 9:56 PM Lorenzo Bianconi <
lorenzo.bianc...@redhat.com> wrote:

> After the I-P has been introduced in commit 354bdba51a ("ovn-controller:
> I-P for SB port binding and OVS interface in runtime_data"), the QoS on
> localnet ports is not properly configured if the ovs interface is marked
> with "ovn-egress-iface" flag after the related record in the
> logical_switch_port table is set. The issue can be triggered with the
> following reproducer:
>
> $ovn-nbctl set Logical_Switch_Port ln-public options:qos_burst=1000
> $ovs-vsctl set interface eth0 external-ids:ovn-egress-iface=true
>
> Fix the issue triggering a recomputation after qos is configured for ovs
> interface
>
> Fixes: 354bdba51abf ("ovn-controller: I-P for SB port binding and OVS
> interface in runtime_data")
>
> Signed-off-by: Lorenzo Bianconi 
> ---
>

Hi Lorenzo,

This approach of having the same shash for representing both the local
interfaces (interfaces connected
to the integration bridge - br-int) and the egress interfaces (interfaces
connected to provider bridges)
doesn't seem right to me. They are not related at all.

We already maintain an sset - egress_ifaces [1] and we add an interface to
this set if 'ovn-egress-iface' is set to true
in external_ids here [2]. I think a simple approach to fix this issue would
be to do the following in the function
binding_handle_ovs_interface_changes()
   - If an ovs interface is deleted, check if this interface name is
present in the sset 'egress_ifaces', if so, return false so
 to trigger a full recompute.

  - If an ovs interface is added/updated check if 'ovn-egress-iface' key is
present in the external_ids.
1. If it is present, then return false to trigger a full recompute.
2. If it is not present, then check if the interface is in the
'egress_ifaces' sset. If so, return false to trigger a full recompute.


Thanks
Numan




>  controller/binding.c | 26 +
>  controller/binding.h |  1 +
>  tests/ovn-performance.at | 13 +
>  tests/system-ovn.at  | 60 
>  4 files changed, 100 insertions(+)
>
> diff --git a/controller/binding.c b/controller/binding.c
> index 107bc28a6..26542ae66 100644
> --- a/controller/binding.c
> +++ b/controller/binding.c
> @@ -1353,6 +1353,13 @@ build_local_bindings(struct binding_ctx_in
> *b_ctx_in,
>  struct local_iface_node *iface_node =
>  xmalloc(sizeof *iface_node);
>  iface_node->iface_id = xstrdup(iface_id);
> +struct local_iface_node *old_iface_node = shash_find_data(
> +b_ctx_out->local_ifaces,
> +iface_rec->name);
> +if (old_iface_node) {
> +iface_node->qos_egress_iface =
> +old_iface_node->qos_egress_iface;
> +}
>  iface_node = shash_replace(b_ctx_out->local_ifaces,
> iface_rec->name, iface_node);
>  if (iface_node) {
> @@ -1700,6 +1707,12 @@ consider_iface_claim(const struct ovsrec_interface
> *iface_rec,
>
>  struct local_iface_node *iface_node = xmalloc(sizeof *iface_node);
>  iface_node->iface_id = xstrdup(iface_id);
> +struct local_iface_node *old_iface_node = shash_find_data(
> +b_ctx_out->local_ifaces,
> +iface_rec->name);
> +if (old_iface_node) {
> +iface_node->qos_egress_iface = old_iface_node->qos_egress_iface;
> +}
>  iface_node = shash_replace(b_ctx_out->local_ifaces,
> iface_rec->name, iface_node);
>  if (iface_node) {
> @@ -1928,6 +1941,19 @@ binding_handle_ovs_interface_changes(struct
> binding_ctx_in *b_ctx_in,
>  continue;
>  }
>
> +struct local_iface_node *node = shash_find_data(
> +b_ctx_out->local_ifaces, iface_rec->name);
> +bool old_qos_egress = node ? node->qos_egress_iface : false;
> +bool qos_egress = smap_get_bool(&iface_rec->external_ids,
> +"ovn-egress-iface", false);
> +if (qos_egress != old_qos_egress) {
> +if (node) {
> +node->qos_egress_iface = qos_egress;
> +}
> +handled = false;
> +break;
> +}
> +
>  const char *iface_id = smap_get(&iface_rec->external_ids,
> "iface-id");
>  int64_t ofport = iface_rec->n_ofport ? *iface_rec->ofport : 0;
>  if (iface_id && ofport > 0) {
> diff --git a/controller/binding.h b/controller/binding.h
> index a1e0f1ccf..9e3e1f512 100644
> --- a/controller/binding.h
> +++ b/controller/binding.h
> @@ -56,6 +56,7 @@ struct binding_ctx_in {
>
>  struct local_iface_node {
>  char *iface_id;
> +bool qos_egress_iface;
>  };
>
>  struct binding_ctx_out {
> diff --git a/tests/ovn-performance.at b/tests/ovn-performance.at
> index 3010860d5..6

[ovs-dev] IMSS - Pensiones y jubilaciones

[Como hacerlo, requisitos y monto]

Webinar en Vivo: 
Taller práctico sobre las pensiones y jubilaciones del IMSS.
Curso en línea - Webinar Interactivo – Sábado 10 de Octubre - Horario de 10:00 
am a 12:00 y 12:15 a 02:00 pm.

Taller de estudio de las pensiones y jubilaciones ante el IMSS, y análisis del 
momento adecuado para jubilarse, cómo hacerlo, requisitos y monto a que se 
tiene derecho.

Objetivos Específicos:

- Estudio del marco legal actual de las pensiones y jubilaciones ante el IMSS. 
- Proporcionar una guía básica para la gestión de pensiones y jubilaciones ante 
el IMSS.
- Dar a conocer el momento adecuado para jubilarse, como hacerlo, requisitos y 
monto a que se tiene derecho. 

Desarrollaremos de una forma dinámica y fácil los aspectos a considerar para la 
gestión y estudio de las pensiones y jubilaciones ante el IMSS. 

Para mayor información, responder sobre este correo con la palabra Pensiones + 
los siguientes datos:

NOMBRE:
TELÉFONO:
EMPRSA:
CORREO ALTERNO: 

Para información inmediata llamar al:
(+52) 55 15 54 66 30 - (+52) 55 30 16 70 85
O puede enviarnos un Whatsapp 

Innova Learn México - innovalearn. mx - Mérida, Yucatán, México



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

[ovs-dev] Darlehensangebot

[Mr. Jeff Michael]

-- 
Hallo,

Konsolidierungsdarlehen heute gelten jetzt ..

Wir bieten eine breite Palette von Finanzdienstleistungen an,
darunter: Unternehmensplanung, Handels- und Entwicklungsfinanzierung,
Immobilien und Hypotheken, Schuldenkonsolidierungsdarlehen,
Geschäftsdarlehen, private Darlehen, Refinanzierung von Eigenheimen,
Studentendarlehen für Hotelkredite mit einem niedrigen Zinssatz von
2%.
Bitte kontaktieren Sie uns für Ihr sicheres und ungesichertes
Darlehen. Interessierte Antragsteller sollten uns per E-Mail
kontaktieren: jsemkffloaninvestm...@gmail.com

Kontaktieren Sie auch über WhatsApp: +12149748303
Dein,
Herr Jeff Michael
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Re: [ovs-dev] [PATCH v4 2/2 ovn] NAT: Northd and parser changes to support port

[Numan Siddique]

On Mon, Sep 21, 2020 at 7:49 PM Mark Gray  wrote:

> On 17/09/2020 03:16, Ankur Sharma wrote:
> > From: Ankur Sharma 
> >
> > This patch has following changes:
> >
> > a. Northd changes to put port range hash in the
> >logical flow based on configuration.
> >
> > b. Changes to parse the logical flow, which specifies
> >port_range_hash along with port_range for ct_nat action.
> >
> > Example logical flow:
> > ct_snat(10.15.24.135,1-3, hash)
>
> Thanks for the patch.
>

Hi Ankur,

Thanks for the patch. Please see below for a few comments.



>
> >
> > Signed-off-by: Ankur Sharma 
> > ---
> >  include/ovn/actions.h |  1 +
> >  lib/actions.c | 51 +--
> >  northd/ovn-northd.c   | 16 +
> >  tests/ovn-northd.at   | 31 
> >  tests/ovn.at  | 66
> ---
> >  5 files changed, 155 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/ovn/actions.h b/include/ovn/actions.h
> > index 636cb4b..101cd7a 100644
> > --- a/include/ovn/actions.h
> > +++ b/include/ovn/actions.h
> > @@ -235,6 +235,7 @@ struct ovnact_ct_nat {
> > bool exists;
> > uint16_t port_lo;
> > uint16_t port_hi;
> > +   char *port_hash;
>
> I wonder could the name be changed to something like 'port_hash_type' or
> 'port_hash_algorthm'. 'port_hash' reads more like the result of the hash
> rather than the type of hash. This would need to be changed across all
> your changes (e.g. 'external_port_hash' -> 'external_port_hash_type', etc)
>


I think instead of 'port_hash' you can have an integer with the name
'nat_flags' ?

And during parsing, you can set the value to 'NX_NAT_F_PROTO_HASH',
'NX_NAT_F_PROTO_RANDOM' or 0.

Right now you are allocating memory for this during parsing, but you're not
freeing it. With integer type, there is no
need to allocate any memory.




> >  } port_range;
> >
> >  uint8_t ltable; /* Logical table ID of next table. */
> > diff --git a/lib/actions.c b/lib/actions.c
> > index 5fe0a38..c8e0767 100644
> > --- a/lib/actions.c
> > +++ b/lib/actions.c
> > @@ -707,6 +707,8 @@ parse_ct_nat(struct action_context *ctx, const char
> *name,
> >
> >  if (lexer_match(ctx->lexer, LEX_T_COMMA)) {
> >
> > +cn->port_range.port_hash = NULL;
> > +
> > if (ctx->lexer->token.type != LEX_T_INTEGER ||
> > ctx->lexer->token.format != LEX_F_DECIMAL) {
> >lexer_syntax_error(ctx->lexer, "expecting Integer for
> port "
> > @@ -733,8 +735,40 @@ parse_ct_nat(struct action_context *ctx, const char
> *name,
> >"greater than range low");
> > }
> > lexer_get(ctx->lexer);
> > +
> > +   if (lexer_match(ctx->lexer, LEX_T_COMMA)) {
> > +   if (ctx->lexer->token.type != LEX_T_ID) {
> > +   lexer_syntax_error(ctx->lexer, "expecting string
> for "
> > +  "port hash");
> > +   }
> > +
> > +   if (strcmp(ctx->lexer->token.s, "hash") &&
> > +   strcmp(ctx->lexer->token.s, "random")) {
> > +   lexer_syntax_error(ctx->lexer, "Invalid value
> for "
> > +  "port hash");
> > +   }
> > +
> > +   cn->port_range.port_hash =
> xstrdup(ctx->lexer->token.s);
> > +   lexer_get(ctx->lexer);
> > +   }
> > } else {
> > cn->port_range.port_hi = 0;
> > +
> > +   if (lexer_match(ctx->lexer, LEX_T_COMMA)) {
> > +   if (ctx->lexer->token.type != LEX_T_ID) {
> > +   lexer_syntax_error(ctx->lexer, "expecting string
> for "
> > +  "port hash");
> > +   }
> > +
> > +   if (strcmp(ctx->lexer->token.s, "hash") &&
> > +   strcmp(ctx->lexer->token.s, "random")) {
> > +   lexer_syntax_error(ctx->lexer, "Invalid value
> for "
> > +  "port hash");
> > +   }
> > +
> > +   cn->port_range.port_hash =
> xstrdup(ctx->lexer->token.s);
> > +   lexer_get(ctx->lexer);
> > +   }
> > }
> >
> > cn->port_range.exists = true;
> > @@ -777,6 +811,10 @@ format_ct_nat(const struct ovnact_ct_nat *cn, const
> char *name, struct ds *s)
> >  if (cn->port_range.port_hi) {
> >  ds_put_format(s, "-%d", cn->port_range.port_hi);
> >  }
> > +
> > +if (cn->port_range.port_hash) {
> > +ds_put_format(s, ",%s", cn->port_range.port_hash);
> > +}
> >  ds_put_char(s, ')');
> >  }
> >
> > @@ -843,8 +881,17 @@ encode_ct_nat(const struct ovnact_ct_nat *cn,
> >  }
> >
> >  if (c

Re: [ovs-dev] [PATCH v4 1/2 ovn] NAT: Provide port hash in input

[Numan Siddique]

On Mon, Sep 21, 2020 at 7:49 PM Mark Gray  wrote:

> On 17/09/2020 03:16, Ankur Sharma wrote:
> > From: Ankur Sharma 
> >
> > This patch enhances the NB OVSSCHEMA to
> > add an additional column in NAT table.
> >
> > external_port_hash: Specifies the hashing mechanism
> > if port range is specified.
> >
> > Changes also add corresponding ovn-nbctl cli.
> >
>
> Thanks for the patch.
>
> > Signed-off-by: Ankur Sharma 
> > ---
> >  ovn-nb.ovsschema  |   5 +-
> >  ovn-nb.xml|  15 ++
> >  tests/ovn-nbctl.at| 136
> +++---
> >  utilities/ovn-nbctl.c | 102 -
> >  4 files changed, 182 insertions(+), 76 deletions(-)
> >
> > diff --git a/ovn-nb.ovsschema b/ovn-nb.ovsschema
> > index 092322a..9b8e070 100644
> > --- a/ovn-nb.ovsschema
> > +++ b/ovn-nb.ovsschema
> > @@ -1,7 +1,7 @@
> >  {
> >  "name": "OVN_Northbound",
> > -"version": "5.27.0",
> > -"cksum": "3507518247 26773",
> > +"version": "5.28.0",
> > +"cksum": "2621169942 26831",
> >  "tables": {
> >  "NB_Global": {
> >  "columns": {
> > @@ -398,6 +398,7 @@
> >  "external_mac": {"type": {"key": "string",
> >"min": 0, "max": 1}},
> >  "external_port_range": {"type": "string"},
> > +"external_port_hash": {"type": "string"},
>

I think it's better to set an enum here and restrict the values to "hash"
and "random".
And also suggest to set the type with "min":0 , "max": 1 ?

For NAT entries without port range and port hash set, this column would be
an empty array.




> >  "logical_ip": {"type": "string"},
> >  "logical_port": {"type": {"key": "string",
> >"min": 0, "max": 1}},
> > diff --git a/ovn-nb.xml b/ovn-nb.xml
> > index 0bfe626..142d934 100644
> > --- a/ovn-nb.xml
> > +++ b/ovn-nb.xml
> > @@ -2729,6 +2729,21 @@
> >
> >  
> >
> > +
> > +  
> > +Hashing algorithm to hash a packet to specified port range
> > +  
> > +
> > +  
> > +Applicable only if port range is also specified.
> > +  
> > +
> > +  
> > +Takes one of the 2 values "Random" and "Hash"
>

Is the first letter capitalized for the port hash value ?



> > +  
> > +
> > +
> > +
> >  
> >An IPv4 network (e.g 192.168.1.0/24) or an IPv4 address.
> >  
> > diff --git a/tests/ovn-nbctl.at b/tests/ovn-nbctl.at
> > index baf7a87..6ce1ecf 100644
> > --- a/tests/ovn-nbctl.at
> > +++ b/tests/ovn-nbctl.at
> > @@ -476,15 +476,15 @@ AT_CHECK([ovn-nbctl lr-nat-add lr0 dnat_and_snat
> fd01::1 fd11::2])
> >  AT_CHECK([ovn-nbctl lr-nat-add lr0 dnat_and_snat 30.0.0.2 192.168.1.3
> lp0 00:00:00:01:02:03])
> >  AT_CHECK([ovn-nbctl lr-nat-add lr0 dnat_and_snat fd01::2 fd11::3 lp0
> 00:00:00:01:02:03])
> >  AT_CHECK([ovn-nbctl lr-nat-list lr0], [0], [dnl
> > -TYPE EXTERNAL_IPEXTERNAL_PORTLOGICAL_IP
> EXTERNAL_MAC LOGICAL_PORT
> > -dnat 30.0.0.1192.168.1.2
> > -dnat fd01::1 fd11::2
> > -dnat_and_snat30.0.0.1192.168.1.2
> > -dnat_and_snat30.0.0.2192.168.1.3
>00:00:00:01:02:03lp0
> > -dnat_and_snatfd01::1 fd11::2
> > -dnat_and_snatfd01::2 fd11::3
>00:00:00:01:02:03lp0
> > -snat 30.0.0.1192.168.1.0/24
> > -snat fd01::1 fd11::/64
> > +TYPE EXTERNAL_IPEXTERNAL_PORT
> EXTERNAL_PORT_HASHLOGICAL_IPEXTERNAL_MAC
>  LOGICAL_PORT
> > +dnat 30.0.0.1
> 192.168.1.2
> > +dnat fd01::1
>fd11::2
> > +dnat_and_snat30.0.0.1
> 192.168.1.2
> > +dnat_and_snat30.0.0.2
> 192.168.1.3   00:00:00:01:02:03lp0
> > +dnat_and_snatfd01::1
>fd11::2
> > +dnat_and_snatfd01::2
>fd11::3   00:00:00:01:02:03lp0
> > +snat 30.0.0.1
> 192.168.1.0/24
> > +snat fd01::1
>fd11::/64
> >  ])
> >  AT_CHECK([ovn-nbctl lr-nat-add lr0 snat 30.0.0.1 192.168.1.0/24], [1],
> [],
> >  [ovn-nbctl: 30.0.0.1, 192.168.1.0/24: a NAT with this external_ip and
> logical_ip already exists
> > @@ -512,28 +512,28 @@ AT_CHECK([ovn-nbctl lr-nat-add lr0 dnat_and_snat
> 30.0.0.1 192.168.1.3], [1], [],
> >  ])
> >  AT_CHECK([ovn-nbctl --may-exist lr-nat-add lr0 dnat_and_snat 30.0.0.2
> 192.168.1.3 lp0 00:00:00:04:05:06])
> >  AT_CHECK([ovn-nbctl lr-nat-list lr0], [0], [dnl
> > -TYPE EXTERNAL_IPEXTERNAL_PORTLOGICAL_IP
> EXTERNAL_MAC LOGICAL_PORT
> > -dnat 30.0.0.1192.168.1.2
> > -dnat fd01::1 

Re: [ovs-dev] [PATCH v10 ovn] Allow to run multiple controllers on the same machine

[0-day Robot]

Bleep bloop.  Greetings Ihar Hrachyshka, I am a robot and I have tried out your 
patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


git-am:
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0001 Allow to run multiple controllers on the same machine
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


Please check this out.  If you feel there has been an error, please email 
acon...@redhat.com

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

Re: [ovs-dev] [PATCH ovn 1/5] ovn-northd: Move out misc build_lrouter_flows() local deny rules into a function

[Numan Siddique]

On Wed, Sep 16, 2020 at 10:42 PM  wrote:

> From: Anton Ivanov 
>
> This moves various rules which deny local traffic which should not
> be forwarded such as ND, RA, ARP, etc into a separate function.
>
> Signed-off-by: Anton Ivanov 
> ---
>  northd/ovn-northd.c | 200 +++-
>  1 file changed, 105 insertions(+), 95 deletions(-)
>
> diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> index db14909fc..32f081d9d 100644
> --- a/northd/ovn-northd.c
> +++ b/northd/ovn-northd.c
> @@ -8688,6 +8688,12 @@ build_egress_delivery_flows_for_lrouter_port(
>  struct ovn_port *op, struct hmap *lflows,
>  struct ds *match, struct ds *actions);
>
> +/* Filter rules for various local traffic which should not be forwarded
> + * by default */
> +static void
> +build_misc_local_traffic_drop_flows_for_lrouter(
> +struct ovn_datapath *od, struct hmap *lflows);
> +
>  static void
>  build_lrouter_flows(struct hmap *datapaths, struct hmap *ports,
>  struct hmap *lflows, struct shash *meter_groups,
> @@ -8720,101 +8726,7 @@ build_lrouter_flows(struct hmap *datapaths, struct
> hmap *ports,
>  }
>
>  HMAP_FOR_EACH (od, key_node, datapaths) {
> -if (!od->nbr) {
> -continue;
> -}
> -
> -/* L3 admission control: drop multicast and broadcast source,
> localhost
> - * source or destination, and zero network source or destination
> - * (priority 100). */
> -ovn_lflow_add(lflows, od, S_ROUTER_IN_IP_INPUT, 100,
> -  "ip4.src_mcast ||"
> -  "ip4.src == 255.255.255.255 || "
> -  "ip4.src == 127.0.0.0/8 || "
> -  "ip4.dst == 127.0.0.0/8 || "
> -  "ip4.src == 0.0.0.0/8 || "
> -  "ip4.dst == 0.0.0.0/8",
> -  "drop;");
> -
> -/* Priority-90-92 flows handle ARP requests and ND packets. Most
> are
> - * per logical port but DNAT addresses can be handled per datapath
> - * for non gateway router ports.
> - */
> -struct sset snat_ips = SSET_INITIALIZER(&snat_ips);
> -for (int i = 0; i < od->nbr->n_nat; i++) {
> -struct ovn_nat *nat_entry = &od->nat_entries[i];
> -const struct nbrec_nat *nat = nat_entry->nb;
> -
> -/* Skip entries we failed to parse. */
> -if (!nat_entry_is_valid(nat_entry)) {
> -continue;
> -}
> -
> -struct lport_addresses *ext_addrs = &nat_entry->ext_addrs;
> -char *ext_addr = nat_entry_is_v6(nat_entry) ?
> - ext_addrs->ipv6_addrs[0].addr_s :
> - ext_addrs->ipv4_addrs[0].addr_s;
> -
> -if (!strcmp(nat->type, "snat")) {
> -if (!sset_add(&snat_ips, ext_addr)) {
> -continue;
> -}
> -}
> -
> -/* Priority 91 and 92 flows are added for each gateway router
> - * port to handle the special cases. In case we get the packet
> - * on a regular port, just reply with the port's ETH address.
> - */
> -if (nat_entry_is_v6(nat_entry)) {
> -build_lrouter_nd_flow(od, NULL, "nd_na",
> -  ext_addrs->ipv6_addrs[0].addr_s,
> -  ext_addrs->ipv6_addrs[0].sn_addr_s,
> -  REG_INPORT_ETH_ADDR, NULL, false,
> 90,
> -  &nat->header_, lflows);
> -} else {
> -build_lrouter_arp_flow(od, NULL,
> -   ext_addrs->ipv4_addrs[0].addr_s,
> -   REG_INPORT_ETH_ADDR, NULL, false,
> 90,
> -   &nat->header_, lflows);
> -}
> -}
> -sset_destroy(&snat_ips);
>

Hi Anton,

The above for loop which adds logical flows -
build_lrouter_arp_flow/build_lrouter_nd_flow do not fall into
the newly added function
- build_misc_local_traffic_drop_flows_for_lrouter()

So I excluded this part of the code
from build_misc_local_traffic_drop_flows_for_lrouter() and applied this
patch to master.

I also applied patch 3 and patch 4 of the series, as they were
straightforward to apply.
There are some conflicts in patch 2 and it needs a thorough review. Can you
please resolve the conflicts and
submit another version for the remaining 2 patches ?

Thanks
Numan


-
> -/* Drop ARP packets (priority 85). ARP request packets for
> router's own
> - * IPs are handled with priority-90 flows.
> - * Drop IPv6 ND packets (priority 85). ND NA packets for router's
> own
> - * IPs are handled with priority-90 flows.
> - */
> -ovn_lflow_add(lflows, od, S_ROUTER_IN_IP_INPUT, 85,
> -  "arp || nd", "drop;");
> -
> 

[ovs-dev] [PATCH v10 ovn] Allow to run multiple controllers on the same machine

[Ihar Hrachyshka]

User stories:
1) NFV: an admin wants to run two separate instances of OVN controller
   using the same database but configuring ports on different bridges.
   Some of these bridges may use DPDK while others may not.

2) Parallel OVN instances: an admin wants to run two separate
   instances of OVN controller using different databases. The
   instances are completely independent and serve different consumers.
   For example, the same machine runs both OpenStack and OpenShift
   stacks, each running its own separate OVN stack.

To serve these use cases, several features should be added to
ovn-controller:

- use different database configuration for multiple controllers;
- customize chassis name used by controller.

=

For each of the following database configuration options, their
extended chassis specific counterparts are introduced:

external_ids:hostname
external_ids:ovn-bridge
external_ids:ovn-bridge-datapath-type
external_ids:ovn-bridge-mappings
external_ids:ovn-chassis-mac-mappings
external_ids:ovn-cms-options
external_ids:ovn-encap-csum
external_ids:ovn-encap-ip
external_ids:ovn-encap-type
external_ids:ovn-is-interconn
external_ids:ovn-monitor-all
external_ids:ovn-openflow-probe-interval
external_ids:ovn-remote
external_ids:ovn-remote-probe-interval

For example,

external_ids:ovn-bridge -> external_ids:ovn-bridge-=
external_ids:ovn-encap-ip -> external_ids:ovn-encap-ip-=
external_ids:ovn-remote -> external_ids:ovn-remote-=

Priority wise,  specific options take precedence.

=

For system-id,

You can now pass intended chassis name via CLI argument:

  $ ovn-controller ... -n 

Alternatively, you can configure a chassis name by putting it into the
${ovn_sysconfdir}/system-id-override file before running the
controller.

The latter option may be more useful in container environment where
the same image may be reused for multiple controller instances, where
ovs_sysconfigdir/ovn/system-id-override is a volume mounted into this
generic image. The override file is read once on startup. If you want
to apply a new chassis name to a controller instance, restart it to
reread the file.

Priority wise, this is the order in which different means to configure
the chassis name are used:

- ovn-controller ... -n  CLI argument.
- ${ovs_sysconfdir}/ovn/system-id-override file;
- external_ids:system-id= ovsdb option;

=

Concurrent chassis running on the same host may inadvertantly remove
patch ports that belong to their peer chassis. To avoid that, patch
ports are now tagged in external-ids:ovn-chassis-id with the
appropriate chassis name, and only patch ports that belong to the
chassis are touched when cleaning up. Also, now only tunnels on the
active integration bridge are being cleaned up.

Note that external-ids:ovn-chassis-id key is already used for tunnel
ports to identify the remote tunnel endpoint. We can reuse the same
key for patch ports because the key usage is not overlapping.

Alternatively, we could introduce a new key with a similar but
different name. This would simplify code changes needed but would
arguably introduce even more confusion. Since the key name is not
entirely self-descriptive for tunnel ports (a better name would be
e.g. ovn-remote-chassis or ovn-peer-chassis), the ideal scenario would
be to rename the key for tunnel endpoints but reuse it for patch
ports. This would involve additional migration steps and is probably
not worth the hassle.

=

Note: this patch assumes that each chassis has its own unique IP.
Future work may consider adding support to specify custom port numbers
for tunneling that would allow to reuse the same IP address for
multiple chassis running on the same host. This work is out of scope
for this patch.

Signed-off-by: Ihar Hrachyshka 

---

v1: initial implementation.
v2: fixed test case to check ports are claimed by proper chassis.
v2: added NEWS entry.
v2: fixed some compiler warnings.
v2: moved file_system_id declaration inside a function that uses it.
v2: removed unneeded binding.h #include.
v2: docs: better explanation of alternatives to select chassis name.
v3: reverted priority order for chassis configuration: first CLI, then
system-id file, then ovsdb.
v4: introduce helpers to extract external-ids (per-chassis or global).
v4: introduce per-chassis config options for all keys.
v4: introduce -M (--concurrent) CLI argument to avoid patch ports
removed by concurrent chassis.
v5: rebased.
v6: switched from -M (--concurrent) to external-ids:ovn-is-concurrent.
v6: with ovn-is-concurrent=true, also avoid removing unknown tunnel
endpoints.
v7: don't clean up tunnel endpoints from other bridges.
v7: don't clean up patch ports that don't belong to the chassis.
v7: remove ovn-is-concurrent that is no longer needed.
v7: rebased.
v8: rename system-id -> /etc/ovn/system-id-override
v8: read the system-id-override file just once on startup
v8: free() controller_chassis (CLI arg value) on exit
v9: updated commit message, removed notion of ovn-is-con

Re: [ovs-dev] [PATCH v9 ovn] Allow to run multiple controllers on the same machine

[Ihar Hrachyshka]

On Mon, Sep 21, 2020 at 2:26 PM Han Zhou  wrote:
>
>
>
> On Sun, Sep 20, 2020 at 1:33 PM Han Zhou  wrote:
> >
> >
> >
> > On Fri, Sep 18, 2020 at 10:37 AM Ihar Hrachyshka  
> > wrote:
> > >
> > > User stories:
> > > 1) NFV: an admin wants to run two separate instances of OVN controller
> > >using the same database but configuring ports on different bridges.
> > >Some of these bridges may use DPDK while others may not.
> > >
> > > 2) Parallel OVN instances: an admin wants to run two separate
> > >instances of OVN controller using different databases. The
> > >instances are completely independent and serve different consumers.
> > >For example, the same machine runs both OpenStack and OpenShift
> > >stacks, each running its own separate OVN stack.
> > >
> > > To serve these use cases, several features should be added to
> > > ovn-controller:
> > >
> > > - use different database configuration for multiple controllers;
> > > - customize chassis name used by controller.
> > >
> > > =
> > >
> > > For each of the following database configuration options, their
> > > extended chassis specific counterparts are introduced:
> > >
> > > external_ids:hostname
> > > external_ids:ovn-bridge
> > > external_ids:ovn-bridge-datapath-type
> > > external_ids:ovn-bridge-mappings
> > > external_ids:ovn-chassis-mac-mappings
> > > external_ids:ovn-cms-options
> > > external_ids:ovn-encap-csum
> > > external_ids:ovn-encap-ip
> > > external_ids:ovn-encap-type
> > > external_ids:ovn-is-interconn
> > > external_ids:ovn-monitor-all
> > > external_ids:ovn-openflow-probe-interval
> > > external_ids:ovn-remote
> > > external_ids:ovn-remote-probe-interval
> > >
> > > For example,
> > >
> > > external_ids:ovn-bridge -> external_ids:ovn-bridge-=
> > > external_ids:ovn-encap-ip -> external_ids:ovn-encap-ip-=
> > > external_ids:ovn-remote -> external_ids:ovn-remote-=
> > >
> > > Priority wise,  specific options take precedence.
> > >
> > > =
> > >
> > > For system-id,
> > >
> > > You can now pass intended chassis name via CLI argument:
> > >
> > >   $ ovn-controller ... -n 
> > >
> > > Alternatively, you can configure a chassis name by putting it into the
> > > ${ovs_sysconfdir}/ovn/system-id-override file before running the
> > > controller.
> > >
> > > The latter option may be more useful in container environment where
> > > the same image may be reused for multiple controller instances, where
> > > ovs_sysconfigdir/ovn/system-id-override is a volume mounted into this
> > > generic image. The override file is read once on startup. If you want
> > > to apply a new chassis name to a controller instance, restart it to
> > > reread the file.
> > >
> > > Priority wise, this is the order in which different means to configure
> > > the chassis name are used:
> > >
> > > - ovn-controller ... -n  CLI argument.
> > > - ${ovs_sysconfdir}/ovn/system-id-override file;
> > > - external_ids:system-id= ovsdb option;
> > >
> > > =
> > >
> > > Concurrent chassis running on the same host may inadvertantly remove
> > > patch ports that belong to their peer chassis. To avoid that, patch
> > > ports are now tagged in external-ids:owner with the appropriate
> > > chassis name, and only patch ports that belong to the chassis are
> > > touched when cleaning up. Also, now only tunnels on the active
> > > integration bridge are cleaned up.
> > >
> > > =
> > >
> > > Note: this patch assumes that each chassis has its own unique IP.
> > > Future work may consider adding support to specify custom port numbers
> > > for tunneling that would allow to reuse the same IP address for
> > > multiple chassis running on the same host. This work is out of scope
> > > for this patch.
> > >
> > > Signed-off-by: Ihar Hrachyshka 
> > >
> > > ---
> > >
> > > v1: initial implementation.
> > > v2: fixed test case to check ports are claimed by proper chassis.
> > > v2: added NEWS entry.
> > > v2: fixed some compiler warnings.
> > > v2: moved file_system_id declaration inside a function that uses it.
> > > v2: removed unneeded binding.h #include.
> > > v2: docs: better explanation of alternatives to select chassis name.
> > > v3: reverted priority order for chassis configuration: first CLI, then
> > > system-id file, then ovsdb.
> > > v4: introduce helpers to extract external-ids (per-chassis or global).
> > > v4: introduce per-chassis config options for all keys.
> > > v4: introduce -M (--concurrent) CLI argument to avoid patch ports
> > > removed by concurrent chassis.
> > > v5: rebased.
> > > v6: switched from -M (--concurrent) to external-ids:ovn-is-concurrent.
> > > v6: with ovn-is-concurrent=true, also avoid removing unknown tunnel
> > > endpoints.
> > > v7: don't clean up tunnel endpoints from other bridges.
> > > v7: don't clean up patch ports that don't belong to the chassis.
> > > v7: remove ovn-is-concurrent that is no longer needed.
> > > v7: rebased.
> > > v8: rename system-id -> /etc/ovn/system-id-override
> > > v8: read the 

[ovs-dev] Logre captar el interés del público.

[Powerpoint y Canva para presentaciones profesionales]

Buenos día 
Quise aprovechar la oportunidad de hacerte una invitación para tomar nuestro 
curso.

En este taller conocerás los detalles de las herramientas como Powerpoint y 
Canva para preparar presentaciones de impacto.
 
Nombre: Powerpoint y Canva para presentaciones profesionales.
Fecha: 03 de Octubre
Horario: 10:00 am a 14:00 pm 
Formato: En línea con interacción en vivo.
Lugar: En Vivo desde su computadora
Instructor: Ma. de los Angeles Junco ha sido profesora del Tecnológico de 
Monterrey por 26 años, además de entrenadora de procesos de
desarrollo humano por más de 10 años.

Una presentación profesional siempre es de utilidad para enmarcar un gran 
trabajo, proyecto, idea o presentación de resultados. Es por ello por lo 
que, si deseas lograr ese gran impacto, es necesario que conozcas y te apoyes 
de herramientas visuales, de tal forma que atrape la atención e 
interés de tu público y que sean un apoyo para tu presentación.

Objetivos Específicos:

- Revisará herramientas de presentación de ideas, proyectos, resultados. 
- Conocerá las herramientas básicas para realizar una presentación en 
powerpoint.
-Conocerá algunas herramientas de Canva para incorporar diseños en powerpoint.

Solicita información respondiendo a este correo con la palabra Power, junto con 
los siguientes datos:

Nombre:
Correo electrónico:
Número telefónico:
Email Alterno:

Para información inmediata llamar al:
(+52) 55 15 54 66 30 - (+52) 55 30 16 70 85

o puede enviarnos un Whatsapp. 

Qué tengas un gran día.
Saludos.

Innova Learn México - innovalearn. mx - Mérida, Yucatán, México


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

Re: [ovs-dev] [PATCH] userspace: Switch default cache from EMC to SMC.

[Kevin Traynor]

On 19/09/2020 14:07, Flavio Leitner wrote:
> The EMC is not large enough for current production cases
> and they are scaling up, so this change switches over from
> EMC to SMC by default, which provides better results.
> 
> The EMC is still available and could be used when only a
> few number of flows is used.
> 

Andrew did perf testing of this a couple of years ago. It could be added
as a reference.
http://www.openvswitch.org/support/ovscon2018/5/1330-theurer.pdf

A lot of benchmarks run with a small number of flows that will drop a
lot by default with this. So people may get a surprise when they test
the first OVS version that includes it.

Checked the logs and we don't currently print out the default EMC/SMC
settings, only when they are changed. Perhaps it would be good to add a
log for the default state of EMC/SMC on startup. At least it may be a
clue for when someone hits this.

> Signed-off-by: Flavio Leitner 
> ---
>  Documentation/topics/dpdk/bridge.rst | 10 +-
>  NEWS |  3 +++
>  lib/dpif-netdev.c|  6 +++---
>  tests/pmd.at |  4 ++--
>  vswitchd/vswitch.xml |  4 ++--
>  5 files changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/topics/dpdk/bridge.rst 
> b/Documentation/topics/dpdk/bridge.rst
> index 526d5c959..0d9aed4eb 100644
> --- a/Documentation/topics/dpdk/bridge.rst
> +++ b/Documentation/topics/dpdk/bridge.rst
> @@ -130,13 +130,13 @@ SMC cache
>  SMC cache or signature match cache is a new cache level after EMC cache.
>  The difference between SMC and EMC is SMC only stores a signature of a flow
>  thus it is much more memory efficient. With same memory space, EMC can store 
> 8k
> -flows while SMC can store 1M flows. When traffic flow count is much larger 
> than
> -EMC size, it is generally beneficial to turn off EMC and turn on SMC. It is
> -currently turned off by default.
> +flows while SMC can store 1M flows. When traffic flow count is small than

Maybe Andrew's results can be used to put a number on 'small', even with
YMMV/caveats etc.

> +EMC size, it is generally beneficial to turn off SMC and turn on EMC. It is
> +currently turned on by default.

Not sure the advice should be to turn off the SMC here. I guess it's
almost zero overhead to keep the SMC enabled if the flows are cached in
the EMC, and if they spill out of the EMC a bit due to collisions or
increased flows it may then be beneficial to have the SMC enabled.

It might also be helpful initially if the SMC is still enabled at the
point where the EMC is first enabled to avoid going to the dpcls, though
I didn't check if it would populate the EMC from a hit in the SMC.

>  
> -To turn on SMC::
> +To turn off SMC::
>  
> -$ ovs-vsctl --no-wait set Open_vSwitch . other_config:smc-enable=true
> +$ ovs-vsctl --no-wait set Open_vSwitch . other_config:smc-enable=false
>  
>  Datapath Classifier Performance
>  ---
> diff --git a/NEWS b/NEWS
> index 2f67d5047..5b88937fb 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,6 +1,9 @@
>  Post-v2.14.0
>  -
>  
> +   - DPDK:
> + * The SMC cache is enabled by default.
> + * The EMC cache is disabled by default.
>  
>  v2.14.0 - 17 Aug 2020
>  -
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 02df8f11e..0f2bb10fd 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -2079,7 +2079,7 @@ port_create(const char *devname, const char *type,
>  port->netdev = netdev;
>  port->type = xstrdup(type);
>  port->sf = NULL;
> -port->emc_enabled = true;
> +port->emc_enabled = false;
>  port->need_reconfigure = true;
>  ovs_mutex_init(&port->txq_used_mutex);
>  
> @@ -4305,7 +4305,7 @@ dpif_netdev_set_config(struct dpif *dpif, const struct 
> smap *other_config)
>  }
>  }
>  
> -bool smc_enable = smap_get_bool(other_config, "smc-enable", false);
> +bool smc_enable = smap_get_bool(other_config, "smc-enable", true);
>  bool cur_smc;
>  atomic_read_relaxed(&dp->smc_enable_db, &cur_smc);
>  if (smc_enable != cur_smc) {
> @@ -4440,7 +4440,7 @@ dpif_netdev_port_set_config(struct dpif *dpif, 
> odp_port_t port_no,
>  struct dp_netdev_port *port;
>  int error = 0;
>  const char *affinity_list = smap_get(cfg, "pmd-rxq-affinity");
> -bool emc_enabled = smap_get_bool(cfg, "emc-enable", true);
> +bool emc_enabled = smap_get_bool(cfg, "emc-enable", false);
>  
>  ovs_mutex_lock(&dp->port_mutex);
>  error = get_port_by_number(dp, port_no, &port);
> diff --git a/tests/pmd.at b/tests/pmd.at
> index 5b612f88f..20c179b39 100644
> --- a/tests/pmd.at
> +++ b/tests/pmd.at
> @@ -238,8 +238,8 @@ pmd thread numa_id  core_id :
>packets received: 20
>packet recirculations: 0
>avg. datapath passes per packet: 1.00
> -  emc hits: 19
> -  smc hits: 0
> +  emc hits: 0
> +  smc hits: 19
>megaflow hits: 0
>avg. subta

[ovs-dev] Une expérience collaborateur RSE inédite

[Renaud OLIVIER]

Une expérience collaborateur RSE inédite

Madame, Monsieur,



J’espère que vous allez bien et que la rentrée se
passe au mieux dans le contexte actuel.

Chez OuiMoveUp, nous repartons motivés et
déterminés pour vous permettre d’engager vos
collaborateurs dans les démarches RSE de votre entreprise.

Une animation interne adaptéeau contexte  OuiMoveUp,
c’est votre challenge à thème, ludique et
collaboratif.

C’est un dispositif 100% digital (une application mobile
personnalisée + un kit de communication interne clé en
main) ! En ce sens, il est très simple à
déployer et représente une formidable alternative
à l’organisation d’évènements
présentiels.

En télétravail ou au bureau, seul.e ou à
plusieurs, impulsez une dynamique positive pour l’ensemble de vos
équipes et faites de cette reprise inédite un temps fort
de communication interne et d’engagement des collaborateurs lors
d’une action RSE qui a du sens.

N’attendez plus et choisissez une thématique depuis notre
catalogue pour déployer rapidement votre challenge en
interne : > Challenge Mobilité dans le cadre de la Semaine
de la Mobilité > Challenge Monde Durable dans le cadre de
la Semaine Européenne du Développement Durable >
Challenge Octobre Rose dans le cadre du Mois de Lutte contre le cancer
du sein > Challenge Éco-responsable pour sensibiliser en interne
aux éco-gestes > Challenge OuiMoveUp en soutien au
Téléthon 2020 > Challenge personnalisé pour
digitaliser vos évènements de rentrée

Chaque package de challenge est composé d’un thème
pour sensibiliser, de récompenses pour motiver, de défis
pour animer et d’un kit de communication pour activer !

Vous êtes intéressé.e ? Contactez-nous via le
formulaire site ou par téléphone pour une mise en place
rapide au sein de votre entreprise.

L’aventure commence ici (Ou par téléphone - +33 1
73793663)



OuiMoveUp, une entreprise dynamique est une entreprise en move-ment.



 



 



 



 



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

Re: [ovs-dev] [PATCH] dpctl: add add-flows command to dpctl

[Aaron Conole]

Eelco Chaudron  writes:

> When you would like to add, modify, or delete a lot of flows in the
> datapath, for example when you want to measure performance, adding
> one flow at the time won't scale. This as it takes a decent amount
> of time to set up the datapath connection.
>
> This new command is in-line with the same command available in
> ovs-ofctl which allows the same thing, with the only difference that
> we do not verify all lines before we start execution. This allows for
> a continuous add/delete stream. For example with a command like this:
>
> python3 -c 'while True:
>   for i in range(0, 1000):
> print("add in_port(0),eth(),eth_type(0x800),ipv4(src=100.1.{}.{}) 
> 1".format(int(i / 256), i % 256))
>   for i in range(0, 1000):
> print("delete 
> in_port(0),eth(),eth_type(0x800),ipv4(src=100.1.{}.{})".format(int(i / 256), 
> i % 256))' \
> |  sudo utilities/ovs-dpctl add-flows -
>
>
> Signed-off-by: Eelco Chaudron 
> ---

It may be worth mentioning this in NEWS.

Also, 'ovs-ofctl add-flows' is subtly different - there is the
possibility to do a single transaction with 'ovs-ofctl add-flows',
but this corresponding command cannot do that.  I guess that might be
what is intended by:

  All flow mods are executed in the order specified.

in the manpage.

Acked-by: Aaron Conole 

>  lib/dpctl.c   |  179 
> -
>  lib/dpctl.man |   11 +++
>  utilities/ovs-dpctl.c |5 +
>  3 files changed, 175 insertions(+), 20 deletions(-)
>
> diff --git a/lib/dpctl.c b/lib/dpctl.c
> index db2b1f896..eba2bdfa2 100644
> --- a/lib/dpctl.c
> +++ b/lib/dpctl.c
> @@ -52,6 +52,12 @@
>  #include "openvswitch/ofp-flow.h"
>  #include "openvswitch/ofp-port.h"
>  
> +enum {
> +DPCTL_FLOWS_ADD = 0,
> +DPCTL_FLOWS_DEL,
> +DPCTL_FLOWS_MOD
> +};
> +
>  typedef int dpctl_command_handler(int argc, const char *argv[],
>struct dpctl_params *);
>  struct dpctl_command {
> @@ -1102,28 +1108,22 @@ out_free:
>  }
>  
>  static int
> -dpctl_put_flow(int argc, const char *argv[], enum dpif_flow_put_flags flags,
> -   struct dpctl_params *dpctl_p)
> +dpctl_put_flow_dpif(struct dpif *dpif, const char *key_s,
> +const char *actions_s,
> +enum dpif_flow_put_flags flags,
> +struct dpctl_params *dpctl_p)
>  {
> -const char *key_s = argv[argc - 2];
> -const char *actions_s = argv[argc - 1];
>  struct dpif_flow_stats stats;
>  struct dpif_port dpif_port;
>  struct dpif_port_dump port_dump;
>  struct ofpbuf actions;
>  struct ofpbuf key;
>  struct ofpbuf mask;
> -struct dpif *dpif;
>  ovs_u128 ufid;
>  bool ufid_present;
>  struct simap port_names;
>  int n, error;
>  
> -error = opt_dpif_open(argc, argv, dpctl_p, 4, &dpif);
> -if (error) {
> -return error;
> -}
> -
>  ufid_present = false;
>  n = odp_ufid_from_string(key_s, &ufid);
>  if (n < 0) {
> @@ -1185,6 +1185,24 @@ out_freeactions:
>  out_freekeymask:
>  ofpbuf_uninit(&mask);
>  ofpbuf_uninit(&key);
> +return error;
> +}
> +
> +static int
> +dpctl_put_flow(int argc, const char *argv[], enum dpif_flow_put_flags flags,
> +   struct dpctl_params *dpctl_p)
> +{
> +struct dpif *dpif;
> +int error;
> +
> +error = opt_dpif_open(argc, argv, dpctl_p, 4, &dpif);
> +if (error) {
> +return error;
> +}
> +
> +error = dpctl_put_flow_dpif(dpif, argv[argc - 2], argv[argc - 1], flags,
> +dpctl_p);
> +
>  dpif_close(dpif);
>  return error;
>  }
> @@ -1258,25 +1276,20 @@ out:
>  }
>  
>  static int
> -dpctl_del_flow(int argc, const char *argv[], struct dpctl_params *dpctl_p)
> +dpctl_del_flow_dpif(struct dpif *dpif, const char *key_s,
> +struct dpctl_params *dpctl_p)
>  {
> -const char *key_s = argv[argc - 1];
>  struct dpif_flow_stats stats;
>  struct dpif_port dpif_port;
>  struct dpif_port_dump port_dump;
>  struct ofpbuf key;
>  struct ofpbuf mask; /* To be ignored. */
> -struct dpif *dpif;
> +
>  ovs_u128 ufid;
>  bool ufid_present;
>  struct simap port_names;
>  int n, error;
>  
> -error = opt_dpif_open(argc, argv, dpctl_p, 3, &dpif);
> -if (error) {
> -return error;
> -}
> -
>  ufid_present = false;
>  n = odp_ufid_from_string(key_s, &ufid);
>  if (n < 0) {
> @@ -1334,6 +1347,23 @@ out:
>  ofpbuf_uninit(&mask);
>  ofpbuf_uninit(&key);
>  simap_destroy(&port_names);
> +return error;
> +}
> +
> +static int
> +dpctl_del_flow(int argc, const char *argv[], struct dpctl_params *dpctl_p)
> +{
> +const char *key_s = argv[argc - 1];
> +struct dpif *dpif;
> +int error;
> +
> +error = opt_dpif_open(argc, argv, dpctl_p, 3, &dpif);
> +if (error) {
> +return error;
> +}
> +
> +error = dpctl_del_flow_dpif(

Re: [ovs-dev] [PATCH] userspace: Switch default cache from EMC to SMC.

[Jan Scheurich via dev]

> -Original Message-
> From: Flavio Leitner 
> On Tue, Sep 22, 2020 at 01:22:58PM +0200, Ilya Maximets wrote:
> > On 9/19/20 3:07 PM, Flavio Leitner wrote:
> > > The EMC is not large enough for current production cases and they
> > > are scaling up, so this change switches over from EMC to SMC by
> > > default, which provides better results.
> > >
> > > The EMC is still available and could be used when only a few number
> > > of flows is used.


> 
> I am curious to find out what others think about this change, so going to 
> wait a
> bit before following up with the next version if that sounds OK.
> 

For production deployments of OVS-DPDK in NFVI we also recommend switching SMC 
on and EMC off.
No problem with making that configuration default in the future.
As to be expected SMC only provides acceleration over DPCLS if the avg. number 
of sub-table lookups is > 1.

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

Re: [ovs-dev] [PATCH ovn v3] ofctrl: Add a predictable resolution for conflicting flow actions.

[Numan Siddique]

On Fri, Sep 11, 2020 at 3:07 AM Dumitru Ceara  wrote:

> Until now, in case the ACL configuration generates openflows that have
> the same match but different actions, ovn-controller was using the
> following approach:
> 1. If the flow being added contains conjunctive actions, merge its
>actions with the already existing flow.
> 2. Otherwise, if the flow is being added incrementally
>(update_installed_flows_by_track), don't install the new flow but
>instead keep the old one.
> 3. Otherwise, (update_installed_flows_by_compare), don't install the
>new flow but instead keep the old one.
>
> Even though one can argue that having an ACL with a match that includes
> the match of another ACL is a misconfiguration, it can happen that the
> users provision OVN like this. Depending on the order of reading and
> installing the logical flows, the above operations can yield
> unpredictable results, e.g., allow specific traffic but then after
> ovn-controller is restarted (or a recompute happens) that specific
> traffic starts being dropped.
>
> A simple example of ACL configuration is:
> ovn-nbctl acl-add ls to-lport 3 '(ip4.src==10.0.0.1 ||
> ip4.src==10.0.0.2) && (ip4.dst == 10.0.0.3 || ip4.dst == 10.0.0.4)' allow
> ovn-nbctl acl-add ls to-lport 3 'ip4.src==10.0.0.1' allow
> ovn-nbctl acl-add ls to-lport 2 'arp' allow
> ovn-nbctl acl-add ls to-lport 1 'ip4' drop
>
> This is a pattern used by most CMSs:
> - define a default deny policy.
> - punch holes in the default deny policy based on user specific
>   configurations.
>
> Without this commit the behavior for traffic from 10.0.0.1 to 10.0.0.5
> is unpredictable. Depending on the order of operations traffic might be
> dropped or allowed.
>
> It's also quite hard to force the CMS to ensure that such match overlaps
> never occur.
>
> To address this issue we now resolve conflicts between flows with the
> same match and different actions by giving precedence to less
> restrictive flows. This means that if the installed flow has action
> "conjunction" and the desired flow doesn't then we prefer the desired
> flow. Similarly, if the desired flow has action "conjunction" and the
> installed flow doesn't then we prefer the already installed flow.
>
> CC: Daniel Alvarez 
> CC: Han Zhou 
> CC: Mark Michelson 
> CC: Numan Siddique 
> Reported-at: https://bugzilla.redhat.com/1871931
> Acked-by: Mark Michelson 
> Signed-off-by: Dumitru Ceara 
> ---
>



Thanks Dumitru for the patch.

The added test case fails  because of recent changes to the ACL table
number. With the below changes, the test case passes.

***
diff --git a/tests/ovn.at b/tests/ovn.at
index 9d8ce3bb2e..11e7dfd160 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -13808,12 +13808,12 @@ ovn-nbctl acl-add ls1 to-lport 3
'ip4.src==10.0.0.1' allow
 ovn-nbctl --wait=hv sync

 # Check OVS flows, the less restrictive flows should have been installed.
-AT_CHECK([as hv1 ovs-ofctl dump-flows br-int table=44 | \
+AT_CHECK([as hv1 ovs-ofctl dump-flows br-int table=45 | \
 grep "priority=1003" | awk '{print $7 " " $8}' | sort], [0], [dnl
-priority=1003,conj_id=2,ip,metadata=0x1 actions=resubmit(,45)
+priority=1003,conj_id=2,ip,metadata=0x1 actions=resubmit(,46)
 priority=1003,ip,metadata=0x1,nw_dst=10.0.0.3 actions=conjunction(2,1/2)
 priority=1003,ip,metadata=0x1,nw_dst=10.0.0.4 actions=conjunction(2,1/2)
-priority=1003,ip,metadata=0x1,nw_src=10.0.0.1 actions=resubmit(,45)
+priority=1003,ip,metadata=0x1,nw_src=10.0.0.1 actions=resubmit(,46)
 priority=1003,ip,metadata=0x1,nw_src=10.0.0.2 actions=conjunction(2,2/2)
 ])

@@ -13849,9 +13849,9 @@ ovn-nbctl acl-del ls1 to-lport 3 'ip4.src==10.0.0.1'
 ovn-nbctl --wait=hv sync

 # Check OVS flows, the 10.0.0.1 conjunction should have been reinstalled.
-AT_CHECK([as hv1 ovs-ofctl dump-flows br-int table=44 | \
+AT_CHECK([as hv1 ovs-ofctl dump-flows br-int table=45 | \
 grep "priority=1003" | awk '{print $7 " " $8}' | sort], [0], [dnl
-priority=1003,conj_id=2,ip,metadata=0x1 actions=resubmit(,45)
+priority=1003,conj_id=2,ip,metadata=0x1 actions=resubmit(,46)
 priority=1003,ip,metadata=0x1,nw_dst=10.0.0.3 actions=conjunction(2,1/2)
 priority=1003,ip,metadata=0x1,nw_dst=10.0.0.4 actions=conjunction(2,1/2)
 priority=1003,ip,metadata=0x1,nw_src=10.0.0.1 actions=conjunction(2,2/2)
**

The patch LGTM with one minor comment.

Acked-by: Numan Siddique 

I will wait for Han if he has any comments before applying this patch.

Thanks
Numan


> v3:
> - Add Mark's ack.
> - Add last missing pcap check in the test.
> v2:
> - Address Han's comments:
>   - Do not delete desired flow that cannot be merged, it might be
> installed later.
>   - Fix typos in the commit log.
> - Update the test to check the OVS flows.
> ---
>  controller/ofctrl.c | 124 +++--
>  tests/ovn.at| 174
> 
>  2 files changed, 293 insertions(+), 5 deletions(-)
>
> diff --git a/

Re: [ovs-dev] [PATCH] userspace: Switch default cache from EMC to SMC.

[Flavio Leitner]

Hi Ilya,

On Tue, Sep 22, 2020 at 01:22:58PM +0200, Ilya Maximets wrote:
> On 9/19/20 3:07 PM, Flavio Leitner wrote:
> > The EMC is not large enough for current production cases
> > and they are scaling up, so this change switches over from
> > EMC to SMC by default, which provides better results.
> > 
> > The EMC is still available and could be used when only a
> > few number of flows is used.
> > 
> 
> Hi, Flavio.  Thanks for the patch!
> 
> I generally agree with this change.

Great!


> The main thing that bothers me is that
> with current version of the patch we will drop all testing on EMC at once.
>
> Right now EMC is enabled by default, so we have it tested in many cases.
> We also have probability configuration covered in one test.  And we have
> at least one test with SMC enabled.  We doesn't check SMC hits, but at least
> insertions should work. :)
> 
> After this patch we will have zero tests with EMC enabled.  And that is not
> a good thing.  In general, I think that we need much more tests for both
> SMC and EMC, but at least couple of tests needed for EMC right now since
> you're disabling it by default.  And we definitely need at least one test
> for emc-insert-inv-prob configuration.

This patch should enable more testing, indeed.


> One more thing is that our DPCLS implementation could actually be faster
> than SMC in some cases [1], so, I think, maybe it worth performing a series
> of performance tests to better understand what we actually want.  It may
> turn out that we want to disable all the caches by default and just have
> datapath classifier to handle all the traffic since it's more flexible and
> even faster in common cases.
> 
> [1] https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360586.html


Yes, but AFAICT the last proposed patch is from mid 2019 while SMC
is already merged since 2.10.  I mean, it's great that we have
further optimizations that might not even require caching, but not
sure if such work will be ready for 2.15.

> Few minor comments inline.

ACK to below changes.

I am curious to find out what others think about this change, so
going to wait a bit before following up with the next version if
that sounds OK.

Thanks for your review Ilya,
fbl

> 
> Best regards, Ilya Maximets.
> 
> > Signed-off-by: Flavio Leitner 
> > ---
> >  Documentation/topics/dpdk/bridge.rst | 10 +-
> >  NEWS |  3 +++
> >  lib/dpif-netdev.c|  6 +++---
> >  tests/pmd.at |  4 ++--
> >  vswitchd/vswitch.xml |  4 ++--
> >  5 files changed, 15 insertions(+), 12 deletions(-)
> > 
> > diff --git a/Documentation/topics/dpdk/bridge.rst 
> > b/Documentation/topics/dpdk/bridge.rst
> > index 526d5c959..0d9aed4eb 100644
> > --- a/Documentation/topics/dpdk/bridge.rst
> > +++ b/Documentation/topics/dpdk/bridge.rst
> > @@ -130,13 +130,13 @@ SMC cache
> >  SMC cache or signature match cache is a new cache level after EMC cache.
> >  The difference between SMC and EMC is SMC only stores a signature of a flow
> >  thus it is much more memory efficient. With same memory space, EMC can 
> > store 8k
> > -flows while SMC can store 1M flows. When traffic flow count is much larger 
> > than
> > -EMC size, it is generally beneficial to turn off EMC and turn on SMC. It is
> > -currently turned off by default.
> > +flows while SMC can store 1M flows. When traffic flow count is small than
> > +EMC size, it is generally beneficial to turn off SMC and turn on EMC. It is
> > +currently turned on by default.
> >  
> > -To turn on SMC::
> > +To turn off SMC::
> >  
> > -$ ovs-vsctl --no-wait set Open_vSwitch . other_config:smc-enable=true
> > +$ ovs-vsctl --no-wait set Open_vSwitch . other_config:smc-enable=false
> >  
> >  Datapath Classifier Performance
> >  ---
> > diff --git a/NEWS b/NEWS
> > index 2f67d5047..5b88937fb 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -1,6 +1,9 @@
> >  Post-v2.14.0
> >  -
> >  
> 
> Usually, we do not have an empty line here.
> 
> > +   - DPDK:
> 
> This should say "Userspace datapath:" instead, as this is a generic change
> for all port types.
> 
> > + * The SMC cache is enabled by default.
> > + * The EMC cache is disabled by default.
> >  
> >  v2.14.0 - 17 Aug 2020
> >  -
> > diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> > index 02df8f11e..0f2bb10fd 100644
> > --- a/lib/dpif-netdev.c
> > +++ b/lib/dpif-netdev.c
> > @@ -2079,7 +2079,7 @@ port_create(const char *devname, const char *type,
> >  port->netdev = netdev;
> >  port->type = xstrdup(type);
> >  port->sf = NULL;
> > -port->emc_enabled = true;
> > +port->emc_enabled = false;
> >  port->need_reconfigure = true;
> >  ovs_mutex_init(&port->txq_used_mutex);
> >  
> > @@ -4305,7 +4305,7 @@ dpif_netdev_set_config(struct dpif *dpif, const 
> > struct smap *other_config)
> >  }
> >  }
> >  
> > -bool

Re: [ovs-dev] [PATCH] ofproto-dpif-upcall: Log the emergency flow flush.

[Aaron Conole]

Flavio Leitner  writes:

> When the number of flows in the datapath reaches twice the
> maximum, revalidators will delete all flows as an emergency
> action to recover. In that case, log a message with values
> and increase a coverage counter.
>
> Signed-off-by: Flavio Leitner 
> ---

Acked-by: Aaron Conole 

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

Re: [ovs-dev] [PATCH] ofproto-dpif-upcall: Log the value of flow limit.

[Aaron Conole]

Flavio Leitner  writes:

> The datapath flow limit is calculated by revalidators so
> log the value as well.
>
> Signed-off-by: Flavio Leitner 
> ---

Acked-by: Aaron Conole 

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

Re: [ovs-dev] [PATCH v2 2/8] windows: Add default value for VSTUDIO_CONFIG

[Ilya Maximets]

On 9/21/20 3:32 AM, Alin Gabriel Serdean wrote:
> VSTUDIO_CONFIG is used when generating the windows installer.
> 
> If the parameter passed to configure `--with-vstudiotarget` is not specified
> to configure we default it to `Default`.
> 
> Fixes bug: vstudiotarget/vstudiotargetver should be available only on Windows.
> 
> Signed-off-by: Alin Gabriel Serdean 
> ---
>  m4/openvswitch.m4 | 93 ---
>  1 file changed, 47 insertions(+), 46 deletions(-)


Hi, Alin.  Thanks for the series!

However it still breaks the linux build with the following error:

  configure: error: conditional "VSTUDIO_WIN8" was never defined.

  Usually this means the macro was only invoked conditionally.

Details here: https://travis-ci.org/github/ovsrobot/ovs/builds/728856195

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

Re: [ovs-dev] [PATCH v3 2/2] documentation, windows: Fix line endings at 79 characters

[Ilya Maximets]

On 9/22/20 12:03 PM, Alin Gabriel Serdean wrote:
> Found by inspection.
> 
> Signed-off-by: Alin Gabriel Serdean 
> Acked-by: Greg Rose 
> ---
> v2: Address comments
> ---
>  Documentation/intro/install/windows.rst | 8 
>  Documentation/topics/windows.rst| 6 +++---
>  2 files changed, 7 insertions(+), 7 deletions(-)

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

Re: [ovs-dev] [PATCH v3 1/2] windows: Document how to generate the Windows installer

[Ilya Maximets]

On 9/22/20 12:01 PM, Alin Gabriel Serdean wrote:
> This patch adds information on how to generate the Windows installer
> which can be used to easily deploy the userspace binaries, kernel module
> and create services on new environments.
> 
> Signed-off-by: Alin Gabriel Serdean 
> ---
> v3: Address comments
> v2: Change line endings at 79 characters
> ---
>  Documentation/intro/install/windows.rst | 24 +---
>  1 file changed, 21 insertions(+), 3 deletions(-)

LGTM,
Acked-by: Ilya Maximets 

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

Re: [ovs-dev] [PATCH] userspace: Switch default cache from EMC to SMC.

[Ilya Maximets]

On 9/19/20 3:07 PM, Flavio Leitner wrote:
> The EMC is not large enough for current production cases
> and they are scaling up, so this change switches over from
> EMC to SMC by default, which provides better results.
> 
> The EMC is still available and could be used when only a
> few number of flows is used.
> 

Hi, Flavio.  Thanks for the patch!

I generally agree with this change.  The main thing that bothers me is that
with current version of the patch we will drop all testing on EMC at once.

Right now EMC is enabled by default, so we have it tested in many cases.
We also have probability configuration covered in one test.  And we have
at least one test with SMC enabled.  We doesn't check SMC hits, but at least
insertions should work. :)

After this patch we will have zero tests with EMC enabled.  And that is not
a good thing.  In general, I think that we need much more tests for both
SMC and EMC, but at least couple of tests needed for EMC right now since
you're disabling it by default.  And we definitely need at least one test
for emc-insert-inv-prob configuration.

One more thing is that our DPCLS implementation could actually be faster
than SMC in some cases [1], so, I think, maybe it worth performing a series
of performance tests to better understand what we actually want.  It may
turn out that we want to disable all the caches by default and just have
datapath classifier to handle all the traffic since it's more flexible and
even faster in common cases.

[1] https://mail.openvswitch.org/pipermail/ovs-dev/2019-July/360586.html

Few minor comments inline.

Best regards, Ilya Maximets.

> Signed-off-by: Flavio Leitner 
> ---
>  Documentation/topics/dpdk/bridge.rst | 10 +-
>  NEWS |  3 +++
>  lib/dpif-netdev.c|  6 +++---
>  tests/pmd.at |  4 ++--
>  vswitchd/vswitch.xml |  4 ++--
>  5 files changed, 15 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/topics/dpdk/bridge.rst 
> b/Documentation/topics/dpdk/bridge.rst
> index 526d5c959..0d9aed4eb 100644
> --- a/Documentation/topics/dpdk/bridge.rst
> +++ b/Documentation/topics/dpdk/bridge.rst
> @@ -130,13 +130,13 @@ SMC cache
>  SMC cache or signature match cache is a new cache level after EMC cache.
>  The difference between SMC and EMC is SMC only stores a signature of a flow
>  thus it is much more memory efficient. With same memory space, EMC can store 
> 8k
> -flows while SMC can store 1M flows. When traffic flow count is much larger 
> than
> -EMC size, it is generally beneficial to turn off EMC and turn on SMC. It is
> -currently turned off by default.
> +flows while SMC can store 1M flows. When traffic flow count is small than
> +EMC size, it is generally beneficial to turn off SMC and turn on EMC. It is
> +currently turned on by default.
>  
> -To turn on SMC::
> +To turn off SMC::
>  
> -$ ovs-vsctl --no-wait set Open_vSwitch . other_config:smc-enable=true
> +$ ovs-vsctl --no-wait set Open_vSwitch . other_config:smc-enable=false
>  
>  Datapath Classifier Performance
>  ---
> diff --git a/NEWS b/NEWS
> index 2f67d5047..5b88937fb 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,6 +1,9 @@
>  Post-v2.14.0
>  -
>  

Usually, we do not have an empty line here.

> +   - DPDK:

This should say "Userspace datapath:" instead, as this is a generic change
for all port types.

> + * The SMC cache is enabled by default.
> + * The EMC cache is disabled by default.
>  
>  v2.14.0 - 17 Aug 2020
>  -
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 02df8f11e..0f2bb10fd 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -2079,7 +2079,7 @@ port_create(const char *devname, const char *type,
>  port->netdev = netdev;
>  port->type = xstrdup(type);
>  port->sf = NULL;
> -port->emc_enabled = true;
> +port->emc_enabled = false;
>  port->need_reconfigure = true;
>  ovs_mutex_init(&port->txq_used_mutex);
>  
> @@ -4305,7 +4305,7 @@ dpif_netdev_set_config(struct dpif *dpif, const struct 
> smap *other_config)
>  }
>  }
>  
> -bool smc_enable = smap_get_bool(other_config, "smc-enable", false);
> +bool smc_enable = smap_get_bool(other_config, "smc-enable", true);
>  bool cur_smc;
>  atomic_read_relaxed(&dp->smc_enable_db, &cur_smc);
>  if (smc_enable != cur_smc) {
> @@ -4440,7 +4440,7 @@ dpif_netdev_port_set_config(struct dpif *dpif, 
> odp_port_t port_no,
>  struct dp_netdev_port *port;
>  int error = 0;
>  const char *affinity_list = smap_get(cfg, "pmd-rxq-affinity");
> -bool emc_enabled = smap_get_bool(cfg, "emc-enable", true);
> +bool emc_enabled = smap_get_bool(cfg, "emc-enable", false);
>  
>  ovs_mutex_lock(&dp->port_mutex);
>  error = get_port_by_number(dp, port_no, &port);
> diff --git a/tests/pmd.at b/tests/pmd.at
> index 5b612f88f..20c179b39 100644
> --- a/tests/pm

[ovs-dev] Notification

[Ontario49]

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

Re: [ovs-dev] [PATCH] compat: Replace the HAVE_L4_RXHASH define with HAVE_L4_HASH

[Ilya Maximets]

On 9/17/20 9:59 PM, Greg Rose wrote:
> The skb now uses l4_hash and it is easier to check for it.  Also
> fixes a compile error for RHEL 7.7.
> 
> Signed-off-by: Greg Rose 
> ---
>  acinclude.m4 | 4 ++--
>  datapath/datapath.c  | 6 +++---
>  datapath/linux/compat/include/linux/skbuff.h | 4 ++--
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/acinclude.m4 b/acinclude.m4
> index 84f344da0..d4e249dac 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -874,8 +874,8 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
>OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [skb_clear_hash])
>OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [int.skb_zerocopy(],
>[OVS_DEFINE([HAVE_SKB_ZEROCOPY])])
> -  OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [u8.*l4_rxhash],
> -  [OVS_DEFINE([HAVE_L4_RXHASH])])
> +  OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [l4_hash],
> +  [OVS_DEFINE([HAVE_L4_HASH])])
>OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [skb_ensure_writable])
>OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [skb_vlan_pop])
>OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [__skb_vlan_pop])
> diff --git a/datapath/datapath.c b/datapath/datapath.c
> index 05c1e4274..c3f57f62a 100644
> --- a/datapath/datapath.c
> +++ b/datapath/datapath.c
> @@ -532,10 +532,10 @@ static int queue_userspace_packet(struct datapath *dp, 
> struct sk_buff *skb,
>   hash |= OVS_PACKET_HASH_SW_BIT;
>  #endif
>  
> -#ifdef HAVE_L4_RXHASH
> - if (skb->l4_rxhash)
> -#else
> +#ifdef HAVE_L4_HASH
>   if (skb->l4_hash)
> +#else
> + if (skb->l4_rxhash)
>  #endif
>   hash |= OVS_PACKET_HASH_L4_BIT;
>  
> diff --git a/datapath/linux/compat/include/linux/skbuff.h 
> b/datapath/linux/compat/include/linux/skbuff.h
> index 6d248b3ed..29253e433 100644
> --- a/datapath/linux/compat/include/linux/skbuff.h
> +++ b/datapath/linux/compat/include/linux/skbuff.h
> @@ -278,7 +278,7 @@ static inline void skb_clear_hash(struct sk_buff *skb)
>  #ifdef HAVE_RXHASH
>   skb->rxhash = 0;
>  #endif
> -#if defined(HAVE_L4_RXHASH) && !defined(HAVE_RHEL_OVS_HOOK)
> +#if !defined(HAVE_L4_HASH) && !defined(HAVE_RHEL_OVS_HOOK)

It looks like commit 21a719d658b4 ("datapath: check for el6 kernels for 
per_cpu")
missed updating of this line with HAVE_RHEL6_PER_CPU instead of 
HAVE_RHEL_OVS_HOOK.
Maybe that is the root cause of your build issue?

I'm not sure why, but this check here was introduced as part of the percpu API 
fix
in commit 3d174bfd1a6d ("datapath: compat: Fix build on RHEL 6.6").

Flavio, could you, please, take a look too?

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

Re: [ovs-dev] [PATCH 1/2] Documentation, windows: Document how to generate the Windows installer

[Alin Serdean]

Thank you for the review!

I addressed the comments and sent a new patchset:
https://patchwork.ozlabs.org/project/openvswitch/list/?series=203406

On 9/8/20 4:04 AM, Alin Gabriel Serdean wrote:
> This patch adds information on how to generate the Windows installer
> which can be used to easily deploy the userspace binaries, kernel module
> and create services on new environments.
>
> Signed-off-by: Alin Gabriel Serdean 
> ---
> v2: Change line endings at 79 characters
> ---
>  Documentation/intro/install/windows.rst | 31 +++--
>  1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/intro/install/windows.rst 
> b/Documentation/intro/install/windows.rst
> index 394572f00..caa8dd062 100644
> --- a/Documentation/intro/install/windows.rst
> +++ b/Documentation/intro/install/windows.rst
> @@ -71,7 +71,10 @@ The following explains the steps in some detail.
>
>You will need at least Visual Studio 2013 (update 4) to compile userspace
>binaries.  In addition to that, if you want to compile the kernel module 
> you
> -  will also need to install Windows Driver Kit (WDK) 8.1 Update.
> +  will also need to install Windows Driver Kit (WDK) 8.1 Update or later.
> +  To generate the Windows installer you need
> +  `WiX Toolset `__ and also be able to build the
> +  kernel module.
>
>It is important to get the Visual Studio related environment variables and 
> to
>have the $PATH inside the bash to point to the proper compiler and linker.
> @@ -319,6 +322,21 @@ An alternative way to do the same is to run the 
> following command:
> seconds has been observed for the change to be reflected in the UI.  This 
> is
> not a bug in Open vSwitch.
>
> +Generate the Windows installer
> +~~
> +
> +To generate the Windows installler run the following command from the top
> +source directory:
> +
> +::
> +
> +   $ make windows_installer
> +
> +.. note::

It might be good to have an empty line here.

> +   This will generate the Windows installer in the following location 
> (relative
> +   to the top source directory):
> +   windows/ovs-windows-installer/bin/Release/OpenvSwitch.msi
> +
>  Starting
>  
>
> @@ -785,10 +803,10 @@ Windows CI Service
>  --
>
>  `AppVeyor http://www.appveyor.com>>`__ provides a free 
> Windows autobuild service for
> -open source projects.  Open vSwitch has integration with AppVeyor for 
> continuous
> -build.  A developer can build test his changes for Windows by logging into
> -appveyor.com using a github account, creating a new project by linking it to
> -his development repository in github and triggering a new build.
> +open source projects.  Open vSwitch has integration with AppVeyor for
> +continuous build.  A developer can build test his changes for Windows by
> +logging into appveyor.com using a github account, creating a new project by
> +linking it to his development repository in github and triggering a new 
> build.

This should be part of the next patch, right?

>
>  TODO
>  
> @@ -797,5 +815,4 @@ TODO
>
>  * Investigate and add the feature to provide QoS.
>
> -* Sign the driver & create an MSI for installing the different Open vSwitch
> -  components on Windows.
> +* Sign the driver.
>

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

[ovs-dev] [PATCH v3 2/2] documentation, windows: Fix line endings at 79 characters

[Alin Gabriel Serdean]

Found by inspection.

Signed-off-by: Alin Gabriel Serdean 
Acked-by: Greg Rose 
---
v2: Address comments
---
 Documentation/intro/install/windows.rst | 8 
 Documentation/topics/windows.rst| 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/intro/install/windows.rst 
b/Documentation/intro/install/windows.rst
index 31cef13b8..61582f791 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst
@@ -804,10 +804,10 @@ Windows CI Service
 --
 
 `AppVeyor `__ provides a free Windows autobuild service for
-open source projects.  Open vSwitch has integration with AppVeyor for 
continuous
-build.  A developer can build test his changes for Windows by logging into
-appveyor.com using a github account, creating a new project by linking it to
-his development repository in github and triggering a new build.
+open source projects.  Open vSwitch has integration with AppVeyor for
+continuous build.  A developer can build test his changes for Windows by
+logging into appveyor.com using a github account, creating a new project by
+linking it to his development repository in github and triggering a new build.
 
 TODO
 
diff --git a/Documentation/topics/windows.rst b/Documentation/topics/windows.rst
index 3a103b4e8..be6e2861e 100644
--- a/Documentation/topics/windows.rst
+++ b/Documentation/topics/windows.rst
@@ -253,9 +253,9 @@ Netlink Message Parser
 ~~
 
 The communication between OVS userspace and OVS kernel datapath is in the form
-of Netlink messages [1]_, [8]_. More details about this are provided below.  
In the
-kernel, a full fledged netlink message parser has been implemented along the
-lines of the netlink message parser in OVS userspace. In fact, a lot of the
+of Netlink messages [1]_, [8]_. More details about this are provided below.  In
+the kernel, a full fledged netlink message parser has been implemented along
+the lines of the netlink message parser in OVS userspace. In fact, a lot of the
 code is ported code.
 
 On the lines of ``struct ofpbuf`` in OVS userspace, a managed buffer has been
-- 
2.27.0.windows.1

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

[ovs-dev] [PATCH v3 1/2] windows: Document how to generate the Windows installer

[Alin Gabriel Serdean]

This patch adds information on how to generate the Windows installer
which can be used to easily deploy the userspace binaries, kernel module
and create services on new environments.

Signed-off-by: Alin Gabriel Serdean 
---
v3: Address comments
v2: Change line endings at 79 characters
---
 Documentation/intro/install/windows.rst | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/Documentation/intro/install/windows.rst 
b/Documentation/intro/install/windows.rst
index 394572f00..31cef13b8 100644
--- a/Documentation/intro/install/windows.rst
+++ b/Documentation/intro/install/windows.rst
@@ -71,7 +71,10 @@ The following explains the steps in some detail.
 
   You will need at least Visual Studio 2013 (update 4) to compile userspace
   binaries.  In addition to that, if you want to compile the kernel module you
-  will also need to install Windows Driver Kit (WDK) 8.1 Update.
+  will also need to install Windows Driver Kit (WDK) 8.1 Update or later.
+  To generate the Windows installer you need
+  `WiX Toolset `__ and also be able to build the
+  kernel module.
 
   It is important to get the Visual Studio related environment variables and to
   have the $PATH inside the bash to point to the proper compiler and linker.
@@ -319,6 +322,22 @@ An alternative way to do the same is to run the following 
command:
seconds has been observed for the change to be reflected in the UI.  This is
not a bug in Open vSwitch.
 
+Generate the Windows installer
+~~
+
+To generate the Windows installler run the following command from the top
+source directory:
+
+::
+
+   $ make windows_installer
+
+.. note::
+
+   This will generate the Windows installer in the following location (relative
+   to the top source directory):
+   windows/ovs-windows-installer/bin/Release/OpenvSwitch.msi
+
 Starting
 
 
@@ -797,5 +816,4 @@ TODO
 
 * Investigate and add the feature to provide QoS.
 
-* Sign the driver & create an MSI for installing the different Open vSwitch
-  components on Windows.
+* Sign the driver.
-- 
2.27.0.windows.1

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

Re: [ovs-dev] [PATCH] Remove duplicate include file

[Alin Serdean]

Thank you for the patch. Applied on master!

Alin.

From: Yi Li
Sent: Tuesday, September 22, 2020 5:26 AM
To: d...@openvswitch.org
Cc: Yi Li
Subject: [ovs-dev] [PATCH] Remove duplicate include file

Found by checkincludes.pl

Signed-off-by: Yi Li 
---
 AUTHORS.rst | 1 +
 datapath-windows/ovsext/Vxlan.c | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/AUTHORS.rst b/AUTHORS.rst
index ba47c9c2c..b47806bf7 100644
--- a/AUTHORS.rst
+++ b/AUTHORS.rst
@@ -411,6 +411,7 @@ xu rongxu.r...@zte.com.cn
 YAMAMOTO Takashi   yamam...@midokura.com
 Yanqin Wei yanqin@arm.com
 Yasuhito Takamiya  yasuh...@gmail.com
+Yi Li  y...@winhong.com
 Yi Yangyangy...@inspur.com
 Yi-Hung Weiyihung@gmail.com
 Yifeng Sun pkusunyif...@gmail.com
diff --git a/datapath-windows/ovsext/Vxlan.c b/datapath-windows/ovsext/Vxlan.c
index 09809d397..04df9f6c9 100644
--- a/datapath-windows/ovsext/Vxlan.c
+++ b/datapath-windows/ovsext/Vxlan.c
@@ -19,7 +19,6 @@
 #include "Atomic.h"
 #include "Debug.h"
 #include "Flow.h"
-#include "Flow.h"
 #include "IpHelper.h"
 #include "NetProto.h"
 #include "Offload.h"
--
2.25.3



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

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

[ovs-dev] [PATCH] ofproto:ipv6 mld report error send to fports

[XiaoXiong Ding]

According with rfc4541 section 2.1.1, a snooping switch should forward 
membership reports only to ports with routers attached.
The current code violates the RFC forwarding membership reports to group ports 
as well.
The same issue doesn't exist with IPv4.

Fixes: 06994f879c ("mcast-snooping: Add Multicast Listener Discovery support")
Signed-off-by: XiaoXiong Ding 
---
 ofproto/ofproto-dpif-xlate.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ofproto/ofproto-dpif-xlate.c b/ofproto/ofproto-dpif-xlate.c
index e0ede2cab..47571e790 100644
--- a/ofproto/ofproto-dpif-xlate.c
+++ b/ofproto/ofproto-dpif-xlate.c
@@ -3100,6 +3100,7 @@ xlate_normal(struct xlate_ctx *ctx)
 xlate_report(ctx, OFT_DETAIL, "MLD query, flooding");
 xlate_normal_flood(ctx, in_xbundle, &xvlan);
 }
+return;
 } else {
 if (is_ip_local_multicast(flow, wc)) {
 /* RFC4541: section 2.1.2, item 2: Packets with a dst IP
-- 
2.14.1.windows.1

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