Re: [ovs-dev] [PATCH] ovs: fix the bug of bucket counter is not updated
> On Thu, Mar 21, 2019 at 10:41:05AM +0800, solomon wrote: >> Ben Pfaff wrote: >> > On Wed, Mar 20, 2019 at 08:16:18PM +0800, Li Wei wrote: >> >> >> >> After inserting/removing a bucket, we don't update the bucket counter. >> >> When we call ovs-ofctl dump-group-stats br-int, a panic happened. >> > >> > Thanks for the patch! It looks correct to me. Thank you for adding a >> > test, too. >> > >> > I took a closer look and I saw that 'n_buckets' is not very useful, >> > because it is only used in cases where the code is already >> > O(n_buckets). I think that we can just remove it. Then it cannot get >> > out-of-sync. What do you think of this variation of your patch? >> >> >> ovs_list_size() will traversing the list to get the total length. >> >> In our custom scheduling algorithms (eg wrr, least-connection), >> we need to know the total number of buckets before traversing the bucket >> list to hit target bucket. >> so, it is traversed twice. >> >> If the number of buckets reaches 100+, there are tens of thousands of >> groups, don't this modification affect performance? >> >> I hope to keep n_buckets in struct ofgroup. > > OK. > > I applied the original to master and backported as far as branch-2.6. This patch broke the testsuite on branches 2.6 to 2.10. Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3 0/2] ovn-controller: Add a new thread in pinctrl module to process packet-ins
On Tue, Mar 26, 2019 at 3:15 AM Ben Pfaff wrote: > On Sat, Mar 16, 2019 at 11:27:06AM +0530, nusid...@redhat.com wrote: > > From: Numan Siddique > > > > This series attempts to add a new thread in pinctrl module. This thread > > will handle the packet-ins. > > > > > > v2 -> v3 > > - > >* Fixed the clang errors. > > > > v1 -> v2 > > -- > > * Added a new patch p1 to the series suggessted by Mark. > > * Addressed the review comments from Han and Mark. > > Thanks. I applied these patches to master. > Thanks for the review and applying the patches. Numan ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovs: fix the bug of bucket counter is not updated
Ilya Maximets wrote: >> On Thu, Mar 21, 2019 at 10:41:05AM +0800, solomon wrote: >>> Ben Pfaff wrote: On Wed, Mar 20, 2019 at 08:16:18PM +0800, Li Wei wrote: > > After inserting/removing a bucket, we don't update the bucket counter. > When we call ovs-ofctl dump-group-stats br-int, a panic happened. Thanks for the patch! It looks correct to me. Thank you for adding a test, too. I took a closer look and I saw that 'n_buckets' is not very useful, because it is only used in cases where the code is already O(n_buckets). I think that we can just remove it. Then it cannot get out-of-sync. What do you think of this variation of your patch? >>> >>> >>> ovs_list_size() will traversing the list to get the total length. >>> >>> In our custom scheduling algorithms (eg wrr, least-connection), >>> we need to know the total number of buckets before traversing the bucket >>> list to hit target bucket. >>> so, it is traversed twice. >>> >>> If the number of buckets reaches 100+, there are tens of thousands of >>> groups, don't this modification affect performance? >>> >>> I hope to keep n_buckets in struct ofgroup. >> >> OK. >> >> I applied the original to master and backported as far as branch-2.6. > > This patch broke the testsuite on branches 2.6 to 2.10. The new testcase in this patch insert new bucket using insert-buckets command. But there is a bug in inserting bucket with weight fixed in commit 0b4caa2eba22a516a312e7b404107eaebe618ee1 （ofp-group: support to insert bucket with weight value for select type） Also need to backport commit 0b4caa2eba to branch2.6~2.10. > > Best regards, Ilya Maximets. > ___ > 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] From:Mrs.Aileen Billanes
Good Day, I am Mrs. Aileen Billanes the wife of Mr. Eleaza Billanes from Philippine. It’s my pleasure writing you this letter. To make it short, my late husband Mr.Billanes was a leader of bayan Muna Party List Group and a secretary general of the Samahan ng mga Magsasaka sa Timog Kutabato and one of the founders of the south Cotabato people’s alliance for Nationalism and democracy (socpand) here in Philippine.He was attacked and assassinated in Osmena street on the 09 / 03 / 2009. Ever since then, my children and I have been facing massive challenges from the family of my late husband over his wealth. The pressure given to us by them has made us explore our chances which is why I have decided to contact you. I do believe you are a honest person For this reason, my children and I are asking for your help as we urgently intend to leave Philippine.My late husnabd I have a total sum of ($5.3USD) five million three hundred thousand Dollars concealed in a box which he managed to deposit in a firm abroad for the future of my kids. Already my late husband’s family have succeeded through their intimidations in claiming most of his properties that were under my control and a huge amount of money belonging to him from his Philippine account after his death. I’m asking you to please help me secure the funds from the firm so that the many years labor of my late husband wouldn’t be in vain. This is because my husband’s family may try to trace the funds. I’m willing to give you the contact of the security company to enable you contact them so that the box will be released to you as soon as we have reached agreement. We will be relocating to your country as soon as the concealment is under your care. I have made up my mind to give you 25% of the total money for your help after you have secured the money for me and my children's future, willingness and hopefully great assistance.Please endeavor to Contact me for more details. Best regards Mrs. Aileen Billanes. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v5 3/3] dpif-netdev: split out generic lookup function
On 25 Mar 2019, at 17:30, Van Haaren, Harry wrote: -Original Message- From: Ilya Maximets [mailto:i.maxim...@samsung.com] Sent: Friday, March 22, 2019 1:19 PM To: Van Haaren, Harry ; Eelco Chaudron Cc: ovs-dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH v5 3/3] dpif-netdev: split out generic lookup function On 22.03.2019 16:08, Van Haaren, Harry wrote: Hey Eelco, -Original Message- I'll work on addressing your comments early next week - thanks again! -H Hi Harry, I didn't look at this series closely yet. But if you're going to prepare new version, it'll be good to fix checkpatch issues reported by 0-day robot too: https://mail.openvswitch.org/pipermail/ovs-dev/2019-February/356615.html https://mail.openvswitch.org/pipermail/ovs-dev/2019-February/356616.html BTW, commented out counters looks suspicious. Best regards, Ilya Maximets. Thanks Ilya, fixing checkpatch issues now, no problems. Correct the lookups_match counter isn't implemented yet - will add it in v6 implementation. The name of the variable is a bit misleading - it really counts the number of subtables searched for a match, per packet that it found a hit for. Eg: a packet that matched the 3rd subtable searched, will += counter by 3. So really, it counts "subtable-effort per packet match". Does this align with you understanding of it? Thanks, -Harry Ran the PVP tests over the weekend and the results look good. The Zero loss ones have quite some deviation, so I would ignore them. Here is a link to the results: https://docs.google.com/spreadsheets/u/0/d/e/2PACX-1vSrHgy18vTWFWk_SCF4vggtr1qpimMUkhZuHCSQtmEQi77yCjPrxlAr4hvNvtuIO3Vzzsy31bls2_wP/pubhtml?skip_itp2_check=true# Will continue the review on v6. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] netdev-rte-offloads: Fix printing masks with wrong byte order.
'spec's and 'mask's should be printed in a same byte order.
Fixes: daf90186e291 ("netdev-dpdk: add debug for rte flow patterns")
Signed-off-by: Ilya Maximets
---
lib/netdev-rte-offloads.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/netdev-rte-offloads.c b/lib/netdev-rte-offloads.c
index b945b3243..e9ab08624 100644
--- a/lib/netdev-rte-offloads.c
+++ b/lib/netdev-rte-offloads.c
@@ -146,7 +146,7 @@ dump_flow_pattern(struct rte_flow_item *item)
"type=0x%04"PRIx16"\n",
ETH_ADDR_BYTES_ARGS(eth_mask->src.addr_bytes),
ETH_ADDR_BYTES_ARGS(eth_mask->dst.addr_bytes),
- eth_mask->type);
+ ntohs(eth_mask->type));
} else {
ds_put_cstr(&s, " Mask = null\n");
}
@@ -224,8 +224,8 @@ dump_flow_pattern(struct rte_flow_item *item)
ds_put_format(&s,
" Mask: src_port=0x%"PRIx16
", dst_port=0x%"PRIx16"\n",
- udp_mask->hdr.src_port,
- udp_mask->hdr.dst_port);
+ ntohs(udp_mask->hdr.src_port),
+ ntohs(udp_mask->hdr.dst_port));
} else {
ds_put_cstr(&s, " Mask = null\n");
}
@@ -248,8 +248,8 @@ dump_flow_pattern(struct rte_flow_item *item)
ds_put_format(&s,
" Mask: src_port=0x%"PRIx16
", dst_port=0x%"PRIx16"\n",
- sctp_mask->hdr.src_port,
- sctp_mask->hdr.dst_port);
+ ntohs(sctp_mask->hdr.src_port),
+ ntohs(sctp_mask->hdr.dst_port));
} else {
ds_put_cstr(&s, " Mask = null\n");
}
@@ -299,8 +299,8 @@ dump_flow_pattern(struct rte_flow_item *item)
ds_put_format(&s,
" Mask: src_port=%"PRIx16", dst_port=%"PRIx16
", data_off=0x%"PRIx8", tcp_flags=0x%"PRIx8"\n",
- tcp_mask->hdr.src_port,
- tcp_mask->hdr.dst_port,
+ ntohs(tcp_mask->hdr.src_port),
+ ntohs(tcp_mask->hdr.dst_port),
tcp_mask->hdr.data_off,
tcp_mask->hdr.tcp_flags);
} else {
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] explanation and workaround
Ben Pfaff writes: > I obtained an explanation from LF about this issue. It is not due to an > mailing list configuration change. It results from DMARC, which is a > setting for email sender domains that causes receivers to reject email > that is allegedly from the domain if it cannot be verified that it > really came from it. Since mail to mailing lists break these rules, > Mailman and other mailing list software rewrites From headers with DMARC > senders so that the messages do not appear to originate from them. > Otherwise, the receiver would probably discard the email, since it > breaks the DMARC rules. > > The most likely reason that we are seeing this often now is that some > new domains have turned on DMARC. > > We can't do anything about this directly, because we don't control DMARC > on senders' domains and we don't control email processing on receivers. > > I wrote the following script to un-rewrite the From: header before > passing it to git-am. It isn't perfect but it worked on the few > examples I tried. > > #! /bin/sh > tmp=$(mktemp) > cat >$tmp > if grep '^From:.*via dev.*' "$tmp" >/dev/null 2>&1; then >sed '/^From:.*via dev.*/d > s/^[Rr]eply-[tT]o:/From:/' $tmp > else >cat "$tmp" > fi | git am "$@" > rm "$tmp" Thanks for the explanation and script. I'll try this out with the 0-day robot processing to skip out on the 'via dev' signoff mails being spammed. I guess the committers will need to remember to make the appropriate adjustments in their workflow. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovs: fix the bug of bucket counter is not updated
On Tue, Mar 26, 2019 at 04:50:03PM +0800, solomon wrote: > Ilya Maximets wrote: > >> On Thu, Mar 21, 2019 at 10:41:05AM +0800, solomon wrote: > >>> Ben Pfaff wrote: > On Wed, Mar 20, 2019 at 08:16:18PM +0800, Li Wei wrote: > > > > After inserting/removing a bucket, we don't update the bucket counter. > > When we call ovs-ofctl dump-group-stats br-int, a panic happened. > > Thanks for the patch! It looks correct to me. Thank you for adding a > test, too. > > I took a closer look and I saw that 'n_buckets' is not very useful, > because it is only used in cases where the code is already > O(n_buckets). I think that we can just remove it. Then it cannot get > out-of-sync. What do you think of this variation of your patch? > >>> > >>> > >>> ovs_list_size() will traversing the list to get the total length. > >>> > >>> In our custom scheduling algorithms (eg wrr, least-connection), > >>> we need to know the total number of buckets before traversing the bucket > >>> list to hit target bucket. > >>> so, it is traversed twice. > >>> > >>> If the number of buckets reaches 100+, there are tens of thousands of > >>> groups, don't this modification affect performance? > >>> > >>> I hope to keep n_buckets in struct ofgroup. > >> > >> OK. > >> > >> I applied the original to master and backported as far as branch-2.6. > > > > This patch broke the testsuite on branches 2.6 to 2.10. > > The new testcase in this patch insert new bucket using insert-buckets command. > But there is a bug in inserting bucket with weight fixed in commit > 0b4caa2eba22a516a312e7b404107eaebe618ee1 > （ofp-group: support to insert bucket with weight value for select type） > > Also need to backport commit 0b4caa2eba to branch2.6~2.10. Thanks, I have made preliminary backports to the relevant branches and am running travisci to see if the tests pass. https://travis-ci.org/horms2/ovs/builds/511479533 https://travis-ci.org/horms2/ovs/builds/511482871 https://travis-ci.org/horms2/ovs/builds/511482977 https://travis-ci.org/horms2/ovs/builds/511482911 https://travis-ci.org/horms2/ovs/builds/511482945 From my point of view travisci passing is a base requirement for applying patches, in particular backports to released versions. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Haga su solicitud de préstamo dinero seguro y honesto
Hola, Sr. y Sra. , Necesitan préstamo de dinero? Oferta de préstamo para todos Tener un préstamo de dinero urgente al 2% sin un protocolo Hecho una solicitud de préstamo de dinero seguro y rápido en 48 horas, Escríbanos por correo: prestamos.din...@solucion-finanzas.org Buenos tarde señora / señor ,Necesita préstamo de dinero? Hacemos de préstamos entre individuo y sociedad e inversión también ayuda a todo el mundo. ¿Préstamo individual y para sus necesidades de préstamos entre particulares para hacer frente a dificultades financieras para romper finalmente el impasse causado por los bancos, por el rechazo de su solicitud para expedientes crediticios?Soy capaz de conseguir préstamos en la cantidad que necesite y con las condiciones que faciliten la vida. Nos ponemos a su disposición una oferta de préstamo Part de $2.000USD a $50.000.000USD Mi tasa de interés es del 2% a condiciones simples y el préstamo son confiables y seguro que es rápidamente sin protocolo. Desea obtener un crédito para la ejecución de sus proyectos, desea aprovechar lasventajas de un negocio, desea obtener un crédito para el progreso de sus estudios, usted quiere cambiar el auto, desea encajar los aparatos electrodomésticos, le ofrecemos un nuevo hogar. Por desgracia es que está en el desempleo, alumno o estudiante, persona a servir aguas abajo, usted está desempleado o fiché banco donde tu sujeto a Banco prohibida por incidente no-independiente de su voluntad, a cualquier institución financiera se compromete a prestarle estás registrado, Banco prohibido y no tiene el favor de los bancos o mejor tiene un proyecto y necesita financiaciónarchivo de crédito o necesitan dinero para pagar cuentas, fondos para invertir en las empresas.Tiene preocupaciones financieras? Quieres ser un préstamo para comprar tu coche? Quieres un préstamo para completar tu casa? Quieres un préstamo para la financiación de sus proyectos?. Soy un comerciante y otorga préstamos con interés anual del 2% para todas las personas honnetes.Tiene preocupaciones financieras? Quieres ser un préstamo para comprar tu coche? Quieres un préstamo para completar tu casa? Quieres un préstamo para la financiación de sus proyectos? Sus necesidades de préstamo personal permanecieron sin resultados? Quieres un préstamo para la educación de sus hijos, más preocupación para usted. Soy un comerciante y otorga préstamos con interés anual del 2% para todas las personas honnetes.Yo estoy disponible para el préstamo válido desde $2.000USD a $50.000.000USD. Simplemente comuníquese conmigo por mi Correo electrónico: prestamos.din...@solucion-finanzas.org E-mail : (prestamos.din...@solucion-finanzas.org).Si usted necesita el dinero listo que enviar mensajes por correo electrónico y tener su respuesta pronto rápidamente Pásaselo a tus amigos que están en necesidad seria y honesta teléfono y Whatapp: +22 996 876 778 Nuestra dirección de correo electrónico oficial: prestamos.din...@solucion-finanzas.org * Hello Mrs. / Mr Do you need a quick money loan at 2% in 48 hours without any worries, without any problem? write us by mail: prestamos.din...@solucion-finanzas.org money loan between individual, between company or between agency, company, whether for an emergency (medical expenses, replacement cost of a vehicle, repair costs summer ...) Or for a less vital project (Opportunity to go on a real estate investment opportunity trip ...) we are here to help you in all your need for financing money.If you need a loan to finance your projects, buy an apartment, to solve your financial problems, contact us. You needed money loan? We make money lending between private individual and company and investment also we help everyone We make all types of loans with a reduced rate of 2%. For investment loans to finance your projects, we are here to make you a loan or an investment, in the amount of $5.000,00 USD to $50.000.000,00 USD to 2% you receive your loan on your bank account in 48 time without any worry, without any protocol. You need a loan or an investment for your home, for your Company, for the purchase of a car, to create your own company, for familiar debts or to create a restaurant. a hotel? Regardless of your situation we can grant you loans from $ 5.000USD up to $50.000.000 USD on very simple terms with insurance. And our loan are reliable and rest assured it's fast without a protocol. We are specialized in investing in abroad. If you really need a loan in all fields of finance contacted us as soon as possible write us by mail on our email address to have a result of satisfaction quickly. So if you need a loan please do not hesitate to contact us To find out more about our conditions. Send us a message by email on this e-mail address: prestamos.din...@solucion-finanzas.org Our whatsapp phone number is: +22 996 876 778 Contact us not mail on our email address: prestamos.din...@sol
Re: [ovs-dev] [PATCH] ovs: fix the bug of bucket counter is not updated
On Tue, Mar 26, 2019 at 02:17:07PM +0100, Simon Horman wrote: > From my point of view travisci passing is a base requirement > for applying patches, in particular backports to released versions. I agree in principle, but I don't know how to work that in with the number of patches I apply. It would blow up my workflow and I would be ineffective. If we designated a new LTS, then it would work out better because there wouldn't be 7 release branches to deal with. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Project management
Cursos Top - Webinar Interactivo – Viernes 05 de Abril Introducción al project management Te presentamos una guía para planear, ejecutar, controlar, evaluar y cerrar proyectos mediante la gestión más eficaz de recursos humanos y materiales. Revisaremos la metodología y conceptos del Project Management así como las habilidades interpersonales esperadas para ser un Project Manager efectivo.. OBJETIVOS ESPECÍFICOS: - El participante identificará cuales procesos son claves para la gestión de proyectos. - El participante revisará la planificación general de un proyecto, cada etapa y el desempeño del proyecto. - El participante revisará los conceptos relacionados al Project Management. Para mayor información, responder sobre este correo con la palabra Project + los siguientes datos: NOMBRE: TELÉFONO: EMPRSA: CORREO ALTERNO: Llamanos al (045) 55 1554 6630 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net-next v3] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode
On Mon, Mar 25, 2019 at 8:46 PM wrote:
>
> From: wenxu
>
> There is currently no support for the multicast/broadcast aspects
> of VXLAN in ovs. In the datapath flow the tun_dst must specific.
> But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
> And the packet can forward through the fdb table of vxlan devcice. In
> this mode the broadcast/multicast packet can be sent through the
> following ways in ovs.
>
> ovs-vsctl add-port br0 vxlan -- set in vxlan type=vxlan \
> options:key=1000 options:remote_ip=flow
> ovs-ofctl add-flow br0 in_port=LOCAL,dl_dst=ff:ff:ff:ff:ff:ff, \
> action=output:vxlan
>
> bridge fdb append ff:ff:ff:ff:ff:ff dev vxlan_sys_4789 dst 172.168.0.1 \
> src_vni 1000 vni 1000 self
> bridge fdb append ff:ff:ff:ff:ff:ff dev vxlan_sys_4789 dst 172.168.0.2 \
> src_vni 1000 vni 1000 self
>
> Signed-off-by: wenxu
> ---
> include/uapi/linux/openvswitch.h | 1 +
> net/openvswitch/flow_netlink.c | 29 +
> 2 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/linux/openvswitch.h
> b/include/uapi/linux/openvswitch.h
> index dbe0cbe..b8913b9 100644
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -364,6 +364,7 @@ enum ovs_tunnel_key_attr {
> OVS_TUNNEL_KEY_ATTR_IPV6_DST, /* struct in6_addr dst IPv6
> address. */
> OVS_TUNNEL_KEY_ATTR_PAD,
> OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS,/* struct erspan_metadata */
> + OVS_TUNNEL_KEY_ATTR_IPV4_INFO_BRIDGE, /* No argument.
> IPV4_INFO_BRIDGE mode.*/
> __OVS_TUNNEL_KEY_ATTR_MAX
> };
>
> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
> index 691da85..ed12b3f 100644
> --- a/net/openvswitch/flow_netlink.c
> +++ b/net/openvswitch/flow_netlink.c
> @@ -403,6 +403,7 @@ size_t ovs_key_attr_size(void)
> [OVS_TUNNEL_KEY_ATTR_IPV6_SRC] = { .len = sizeof(struct
> in6_addr) },
> [OVS_TUNNEL_KEY_ATTR_IPV6_DST] = { .len = sizeof(struct
> in6_addr) },
> [OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS] = { .len = OVS_ATTR_VARIABLE },
> + [OVS_TUNNEL_KEY_ATTR_IPV4_INFO_BRIDGE] = { .len = 0 },
> };
>
> static const struct ovs_len_tbl
> @@ -666,6 +667,7 @@ static int ip_tun_from_nlattr(const struct nlattr *attr,
> bool log)
> {
> bool ttl = false, ipv4 = false, ipv6 = false;
> + bool info_bridge_mode = false;
> __be16 tun_flags = 0;
> int opts_type = 0;
> struct nlattr *a;
> @@ -782,6 +784,10 @@ static int ip_tun_from_nlattr(const struct nlattr *attr,
> tun_flags |= TUNNEL_ERSPAN_OPT;
> opts_type = type;
> break;
> + case OVS_TUNNEL_KEY_ATTR_IPV4_INFO_BRIDGE:
> + info_bridge_mode = true;
> + ipv4 = true;
> + break;
> default:
> OVS_NLERR(log, "Unknown IP tunnel attribute %d",
> type);
> @@ -812,16 +818,29 @@ static int ip_tun_from_nlattr(const struct nlattr *attr,
> OVS_NLERR(log, "IP tunnel dst address not specified");
> return -EINVAL;
> }
> - if (ipv4 && !match->key->tun_key.u.ipv4.dst) {
> - OVS_NLERR(log, "IPv4 tunnel dst address is zero");
> - return -EINVAL;
> + if (ipv4) {
> + if (info_bridge_mode) {
> + if (match->key->tun_key.u.ipv4.src ||
> + match->key->tun_key.u.ipv4.dst ||
> + match->key->tun_key.tp_src ||
> + match->key->tun_key.tp_dst ||
> + match->key->tun_key.ttl ||
> + match->key->tun_key.tos ||
> + tun_flags & ~TUNNEL_KEY) {
> + OVS_NLERR(log, "IPv4 tun info is not
> correct");
> + return -EINVAL;
> + }
> + } else if (!match->key->tun_key.u.ipv4.dst) {
> + OVS_NLERR(log, "IPv4 tunnel dst address is
> zero");
> + return -EINVAL;
> + }
> }
> if (ipv6 && ipv6_addr_any(&match->key->tun_key.u.ipv6.dst)) {
> OVS_NLERR(log, "IPv6 tunnel dst address is zero");
> return -EINVAL;
> }
>
> - if (!ttl) {
> + if (!ttl && !info_bridge_mode) {
> OVS_NLERR(log, "IP tunnel TTL not specified.");
> return -EINVAL;
> }
ip_tun_to_nlattr() also needs to
Re: [ovs-dev] [PATCH net-next v2] openvswitch: add seqadj extension when NAT is used.
On Mon, Mar 25, 2019 at 11:58 AM Flavio Leitner wrote:
>
> When the conntrack is initialized, there is no helper attached
> yet so the nat info initialization (nf_nat_setup_info) skips
> adding the seqadj ext.
>
> A helper is attached later when the conntrack is not confirmed
> but is going to be committed. In this case, if NAT is needed then
> adds the seqadj ext as well.
>
> Fixes: 16ec3d4fbb96 ("openvswitch: Fix cached ct with helper.")
> Signed-off-by: Flavio Leitner
> ---
> net/openvswitch/conntrack.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> Changelog:
> v2 - removed nfct_help(ct) check as it is not necessary.
>
> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
> index 51080004677e..845b83598e0d 100644
> --- a/net/openvswitch/conntrack.c
> +++ b/net/openvswitch/conntrack.c
> @@ -990,6 +990,12 @@ static int __ovs_ct_lookup(struct net *net, struct
> sw_flow_key *key,
> GFP_ATOMIC);
> if (err)
> return err;
> +
> + /* helper installed, add seqadj if NAT is required */
> + if (info->nat && !nfct_seqadj(ct)) {
> + if (!nfct_seqadj_ext_add(ct))
> + return -EINVAL;
> + }
> }
>
> /* Call the helper only if:
Acked-by: Pravin B Shelar
Thanks,
Pravin.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 net-next] net: openvswitch: Add a new action check_pkt_len
On Mon, Mar 25, 2019 at 5:44 PM wrote: > > From: Numan Siddique > > This patch adds a new action - 'check_pkt_len' which checks the > packet length and executes a set of actions if the packet > length is greater than the specified length or executes > another set of actions if the packet length is lesser or equal to. > > This action takes below nlattrs > * OVS_CHECK_PKT_LEN_ATTR_PKT_LEN - 'pkt_len' to check for > > * OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_GREATER - Nested actions > to apply if the packet length is greater than the specified 'pkt_len' > > * OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_LESS_EQUAL - Nested > actions to apply if the packet length is lesser or equal to the > specified 'pkt_len'. > > The main use case for adding this action is to solve the packet > drops because of MTU mismatch in OVN virtual networking solution. > When a VM (which belongs to a logical switch of OVN) sends a packet > destined to go via the gateway router and if the nic which provides > external connectivity, has a lesser MTU, OVS drops the packet > if the packet length is greater than this MTU. > > With the help of this action, OVN will check the packet length > and if it is greater than the MTU size, it will generate an > ICMP packet (type 3, code 4) and includes the next hop mtu in it > so that the sender can fragment the packets. > > Reported-at: > https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html > Suggested-by: Ben Pfaff > Signed-off-by: Numan Siddique > CC: Gregory Rose > CC: Pravin B Shelar > --- > v1 -> v2 > - >* Addressed the review comments. > - Removed the vlan-tag length when checking the packet length > - Reordered the netlink attributes > - Changed the comments to use 'attribute' instead of 'action' > > Corresponding OVS patch (submitted as RFC for now) which makes use of this > action can be > found here - https://patchwork.ozlabs.org/patch/1059081/ > Looks good to me. Acked-by: Pravin B Shelar ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] faq: Add Q&A for applying patches from email.
Signed-off-by: Ben Pfaff --- Documentation/faq/contributing.rst | 49 ++ 1 file changed, 49 insertions(+) diff --git a/Documentation/faq/contributing.rst b/Documentation/faq/contributing.rst index cfc9cf7b5035..d8de9a49e255 100644 --- a/Documentation/faq/contributing.rst +++ b/Documentation/faq/contributing.rst @@ -121,3 +121,52 @@ Q: What's a Signed-off-by and how do I provide one? commit -s". If you use the "git citool" GUI for commits, you can add a Signed-off-by line to the commit message by pressing Control+S. Other Git user interfaces may provide similar support. + +Q: How do I apply patches from email? + + A: You can use ``git am`` on raw email contents, either from a file saved by + or piped from an email client. In ``mutt``, for example, when you are + viewing a patch, you can apply it to the tree in ~/ovs by issuing the + command ``|cd ~/ovs && git am``. If you are an OVS committer, you might + want to add ``-s`` to sign off on the patch as part of applying it. If you + do this often, then you can make the keystrokes ``,a`` shorthand for it by + adding the following line to your ``.muttrc``: + + macro index,pager ,a "cd ~/ovs && git am -s" "apply patch" + + ``git am`` has a problem with some email messages from the ovs-dev list for + which the mailing list manager edits the From: address, replacing it by the + list's own address. The mailing list manager must do this for messages + whose sender's email domain has DMARC configured, because receivers will + otherwise discard these messages when they do not come directly from the + sender's email domain. This editing makes the patches look like they come + from the mailing list instead of the author. To work around this problem, + one can use the following wrapper script for ``git am``:: + + #! /bin/sh + tmp=$(mktemp) + cat >$tmp + if grep '^From:.*via dev.*' "$tmp" >/dev/null 2>&1; then +sed '/^From:.*via dev.*/d + s/^[Rr]eply-[tT]o:/From:/' $tmp + else +cat "$tmp" + fi | git am "$@" + rm "$tmp" + + Another way to apply emailed patches is to use the ``pwclient`` program, + which can obtain patches from patchwork and apply them directly. Download + ``pwclient`` at https://patchwork.ozlabs.org/project/openvswitch/. You + probably want to set up a ``.pwclientrc`` that looks something like this:: + + [options] + default=openvswitch + signoff=true + + [openvswitch] + url=https://patchwork.ozlabs.org/xmlrpc/ + + After you install ``pwclient``, you can apply a patch from patchwork with + ``pwclient git-am #``, where # is the patch's number. (This fails with + certain patches that contain form-feeds, due to a limitation of the protocol + underlying ``pwclient``.) -- 2.20.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] explanation and workaround
On Tue, Mar 26, 2019 at 08:57:41AM -0400, Aaron Conole wrote: > Ben Pfaff writes: > > > I obtained an explanation from LF about this issue. It is not due to an > > mailing list configuration change. It results from DMARC, which is a > > setting for email sender domains that causes receivers to reject email > > that is allegedly from the domain if it cannot be verified that it > > really came from it. Since mail to mailing lists break these rules, > > Mailman and other mailing list software rewrites From headers with DMARC > > senders so that the messages do not appear to originate from them. > > Otherwise, the receiver would probably discard the email, since it > > breaks the DMARC rules. > > > > The most likely reason that we are seeing this often now is that some > > new domains have turned on DMARC. > > > > We can't do anything about this directly, because we don't control DMARC > > on senders' domains and we don't control email processing on receivers. > > > > I wrote the following script to un-rewrite the From: header before > > passing it to git-am. It isn't perfect but it worked on the few > > examples I tried. > > > > #! /bin/sh > > tmp=$(mktemp) > > cat >$tmp > > if grep '^From:.*via dev.*' "$tmp" >/dev/null 2>&1; then > >sed '/^From:.*via dev.*/d > > s/^[Rr]eply-[tT]o:/From:/' $tmp > > else > >cat "$tmp" > > fi | git am "$@" > > rm "$tmp" > > Thanks for the explanation and script. I'll try this out with the 0-day > robot processing to skip out on the 'via dev' signoff mails being > spammed. I guess the committers will need to remember to make the > appropriate adjustments in their workflow. I sent out a patch that adds this to the FAQ: https://patchwork.ozlabs.org/patch/1065786/ ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v2] hmap: Improve debug log message when reporting unusually large buckets.
I was seeing a lot of these messages, including a lot of them suppressed
by rate-limiting, and I wondered whether any really big messages were
being suppressed. By reporting the largest bucket, instead of just every
large bucket, it becomes more likely that the truly too-large buckets get
reported.
(The problem I saw was a false alarm.)
Signed-off-by: Ben Pfaff
---
v1->v2: Further improve the log message, thanks Han.
lib/hmap.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/lib/hmap.c b/lib/hmap.c
index 1ba4a5716a78..9ee05b6d499b 100644
--- a/lib/hmap.c
+++ b/lib/hmap.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2008, 2009, 2010, 2012, 2013, 2015 Nicira, Inc.
+ * Copyright (c) 2008, 2009, 2010, 2012, 2013, 2015, 2019 Nicira, Inc.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -103,6 +103,9 @@ resize(struct hmap *hmap, size_t new_mask, const char
*where)
tmp.buckets[i] = NULL;
}
}
+int n_big_buckets = 0;
+int biggest_count = 0;
+int n_biggest_buckets = 0;
for (i = 0; i <= hmap->mask; i++) {
struct hmap_node *node, *next;
int count = 0;
@@ -112,14 +115,30 @@ resize(struct hmap *hmap, size_t new_mask, const char
*where)
count++;
}
if (count > 5) {
-static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(10, 10);
-COVERAGE_INC(hmap_pathological);
-VLOG_DBG_RL(&rl, "%s: %d nodes in bucket (%"PRIuSIZE" nodes,
%"PRIuSIZE" buckets)",
-where, count, hmap->n, hmap->mask + 1);
+n_big_buckets++;
+if (count > biggest_count) {
+biggest_count = count;
+n_biggest_buckets = 1;
+} else if (count == biggest_count) {
+n_biggest_buckets++;
+}
}
}
hmap_swap(hmap, &tmp);
hmap_destroy(&tmp);
+
+if (n_big_buckets) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(10, 10);
+COVERAGE_INC(hmap_pathological);
+VLOG_DBG_RL(&rl, "%s: %d bucket%s with 6+ nodes, "
+"including %d bucket%s with %d nodes "
+"(%"PRIuSIZE" nodes total across %"PRIuSIZE" buckets)",
+where,
+n_big_buckets, n_big_buckets > 1 ? "s" : "",
+n_biggest_buckets, n_biggest_buckets > 1 ? "s" : "",
+biggest_count,
+hmap->n, hmap->mask + 1);
+}
}
static size_t
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] hmap: Improve debug log message when reporting unusually large buckets.
On Mon, Mar 25, 2019 at 05:16:20PM -0700, Han Zhou wrote:
> On Mon, Mar 25, 2019 at 4:57 PM Ben Pfaff wrote:
> >
> > I was seeing a lot of these messages, including a lot of them suppressed
> > by rate-limiting, and I wondered whether any really big messages were
> > being suppressed. By reporting the largest bucket, instead of just every
> > large bucket, it becomes more likely that the truly too-large buckets get
> > reported.
> >
> > (The problem I saw was a false alarm.)
> >
> > Signed-off-by: Ben Pfaff
> > ---
> > lib/hmap.c | 18 --
> > 1 file changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/lib/hmap.c b/lib/hmap.c
> > index 1ba4a5716a78..20161698af5d 100644
> > --- a/lib/hmap.c
> > +++ b/lib/hmap.c
> > @@ -1,5 +1,5 @@
> > /*
> > - * Copyright (c) 2008, 2009, 2010, 2012, 2013, 2015 Nicira, Inc.
> > + * Copyright (c) 2008, 2009, 2010, 2012, 2013, 2015, 2019 Nicira, Inc.
> > *
> > * Licensed under the Apache License, Version 2.0 (the "License");
> > * you may not use this file except in compliance with the License.
> > @@ -103,6 +103,7 @@ resize(struct hmap *hmap, size_t new_mask, const char
> > *where)
> > tmp.buckets[i] = NULL;
> > }
> > }
> > +int max_count = 0;
> > for (i = 0; i <= hmap->mask; i++) {
> > struct hmap_node *node, *next;
> > int count = 0;
> > @@ -111,15 +112,20 @@ resize(struct hmap *hmap, size_t new_mask, const char
> > *where)
> > hmap_insert_fast(&tmp, node, node->hash);
> > count++;
> > }
> > -if (count > 5) {
> > -static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(10,
> > 10);
> > -COVERAGE_INC(hmap_pathological);
> > -VLOG_DBG_RL(&rl, "%s: %d nodes in bucket (%"PRIuSIZE" nodes,
> > %"PRIuSIZE" buckets)",
> > -where, count, hmap->n, hmap->mask + 1);
> > +if (count > max_count) {
> > +max_count = count;
> > }
> > }
> > hmap_swap(hmap, &tmp);
> > hmap_destroy(&tmp);
> > +
> > +if (max_count > 5) {
> > +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(10, 10);
> > +COVERAGE_INC(hmap_pathological);
> > +VLOG_DBG_RL(&rl, "%s: %d nodes in bucket "
> > +"(%"PRIuSIZE" nodes, %"PRIuSIZE" buckets)",
> > +where, max_count, hmap->n, hmap->mask + 1);
> > +}
> > }
>
> Would it be more helpful in the same log print out how many buckets
> has count > 5? For example, 1 entry with count = 10 maybe is not a big
> deal, but too many entries with count > 5 may indicate bad hashing.
> The new log may not tell this information.
Good idea, I sent out a v2.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 2/5] ovn: Add generic HA chassis group
Thanks Han for the review. I will address them
Please see comments inline
Thanks
Numan
On Tue, Mar 26, 2019 at 8:07 AM Han Zhou wrote:
> Mostly looks good to me, just minor comments.
>
> On Thu, Mar 14, 2019 at 12:32 PM wrote:
> >
> > +static void
> > +build_lrouter_groups__(struct hmap *ports, struct ovn_datapath *od)
> > +{
> > +ovs_assert((od && od->nbr && od->lr_group));
> > +
> > +if (od->l3dgw_port && od->l3redirect_port) {
> > +/* It's a logical router with gateway port. If it
> > + * has HA_Chassis_Group associated to it in SB DB, then store
> the
> > + * ha chassis group name. */
> > +if (od->l3redirect_port->sb->ha_chassis_group) {
> > +sset_add(&od->lr_group->ha_chassis_groups,
> > + od->l3redirect_port->sb->ha_chassis_group->name);
> > +}
> > +}
> > +
> > +for (size_t i = 0; i < od->nbr->n_ports; i++) {
> > +struct ovn_port *router_port =
> > +ovn_port_find(ports, od->nbr->ports[i]->name);
> > +
> > +if (!router_port || !router_port->peer) {
> > +continue;
> > +}
> > +
> > +/* Get the peer logical switch/logical router datapath. */
> > +struct ovn_datapath *peer_dp = router_port->peer->od;
> > +if (peer_dp->nbr) {
> > +if (!peer_dp->lr_group) {
> > +peer_dp->lr_group = od->lr_group;
> > +od->lr_group->router_dps[od->lr_group->n_router_dps++]
> > += peer_dp;
> > +build_lrouter_groups__(ports, peer_dp);
> > +}
> > +} else {
> > +for (size_t j = 0; j < peer_dp->n_router_ports; j++) {
> > +if (!peer_dp->router_ports[j]->peer) {
> > +/* If there is no peer port connecting to the
> > +* router datapath, ignore it. */
>
> s/router datapath/router port
>
> > +continue;
> > +}
> > +
>
> > +static void
> > +build_lrouter_groups(struct hmap *ports, struct ovs_list *lr_list)
> > +{
> > +struct ovn_datapath *od;
> > +size_t n_router_dps = ovs_list_size(lr_list);
> > +
> > +LIST_FOR_EACH (od, lr_list, lr_list) {
> > +if (!od->lr_group) {
> > +od->lr_group = xzalloc(sizeof *od->lr_group);
> > +/* Each logical router group can have max
> > + * 'n_router_dps'. So allocate enough memory. */
> > +od->lr_group->router_dps = xcalloc(sizeof *od,
> n_router_dps);
> > +od->lr_group->router_dps[od->lr_group->n_router_dps] = od;
>
> Here it is more clear to be: od->lr_group->router_dps[0] = od;
>
> > +od->lr_group->n_router_dps = 1;
> > +sset_init(&od->lr_group->ha_chassis_groups);
> > +build_lrouter_groups__(ports, od);
> > +}
> > +}
> > +}
> > +
>
> > static void
> > -destroy_datapaths_and_ports(struct hmap *datapaths, struct hmap *ports)
> > +destroy_datapaths_and_ports(struct hmap *datapaths, struct hmap *ports,
> > +struct ovs_list *lr_list)
> > {
> > +struct ovn_datapath *router_dp;
> > +LIST_FOR_EACH_POP (router_dp, lr_list, lr_list) {
> > +if (router_dp->lr_group) {
> > +struct lrouter_group *lr_group = router_dp->lr_group;
> > +
> > +for (size_t i = 0; i < router_dp->lr_group->n_router_dps;
> i++) {
> > +if (router_dp->lr_group->router_dps[i] != router_dp) {
>
> This if-condition seems not needed.
>
> > +router_dp->lr_group->router_dps[i]->lr_group = NULL;
> > +}
> > +}
>
> s/router_dp->lr_group/lr_group in above for-loop.
>
> > +
> > +free(lr_group->router_dps);
> > +sset_destroy(&lr_group->ha_chassis_groups);
> > +free(lr_group);
> > +router_dp->lr_group = NULL;
> > +}
> > +}
> > +
>
> > diff --git a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
> > index 10a59649a..48d27b960 100644
> > --- a/ovn/ovn-nb.ovsschema
> > +++ b/ovn/ovn-nb.ovsschema
> > @@ -1,7 +1,7 @@
> > {
> > "name": "OVN_Northbound",
> > -"version": "5.14.1",
> > -"cksum": "3758097843 20509",
> > +"version": "5.15.0",
> > +"cksum": "1078795414 21917",
> > "tables": {
> > "NB_Global": {
> > "columns": {
> > @@ -271,6 +271,12 @@
> > "refType": "strong"},
> > "min": 0,
> > "max": "unlimited"}},
> > +"ha_chassis_group": {
> > +"type": {"key": {"type": "uuid",
> > + "refTable": "HA_Chassis_Group",
> > + "refType": "weak"},
>
> Shall this be strong ref instead? In normal case logical ports hosted
> by a HA-chassis-group should be deleted before the HA-chassis-group is
> removed. (same for SB schema)
>
I would prefer weak r
[ovs-dev] [PATCH 0/2] netdev-linux: fix update via netlink
The first patch is actually an improvement to avoid reallocation. The second patch is a bug fix. More details in each patch. Those patches need to be applied on master, branch-2.11 and branch-2.10. The same patches apply on those branches, but let me know if you need a per branch formal submission. Flavio Leitner (2): netlink linux: account for the netnsid netlink attr. netlink linux: fix to append the netnsid netlink attr. lib/netdev-linux.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.20.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 2/2] netlink linux: fix to append the netnsid netlink attr.
The attribute was being prepended to the netlink buffer, but
the function nl_sock_transact_multiple__() expects to find the
netlink header as first to update the length, seq and pid fields.
This patch fixes to append the attribute instead of prepending it.
Fixes: 756819ddd788 ("netdev-linux: use netlink to update netdev.")
Signed-off-by: Flavio Leitner
---
lib/netdev-linux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c
index 965e7eee8..5fcd2188a 100644
--- a/lib/netdev-linux.c
+++ b/lib/netdev-linux.c
@@ -6054,7 +6054,7 @@ netdev_linux_update_via_netlink(struct netdev_linux
*netdev)
* and the interface name statically stored in ovsdb. */
nl_msg_put_string(&request, IFLA_IFNAME, netdev_get_name(&netdev->up));
if (netdev_linux_netnsid_is_remote(netdev)) {
-nl_msg_push_u32(&request, IFLA_IF_NETNSID, netdev->netnsid);
+nl_msg_put_u32(&request, IFLA_IF_NETNSID, netdev->netnsid);
}
error = nl_transact(NETLINK_ROUTE, &request, &reply);
ofpbuf_uninit(&request);
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/2] netlink linux: account for the netnsid netlink attr.
The buffer needs to be reallocated and data copied when
the netnsid netlink attribute is included, so avoid that
by accounting the attribute when the buffer is initially
allocated.
Fixes: 756819ddd788 ("netdev-linux: use netlink to update netdev.")
Signed-off-by: Flavio Leitner
---
lib/netdev-linux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/netdev-linux.c b/lib/netdev-linux.c
index deedc6954..965e7eee8 100644
--- a/lib/netdev-linux.c
+++ b/lib/netdev-linux.c
@@ -6045,8 +6045,8 @@ netdev_linux_update_via_netlink(struct netdev_linux
*netdev)
ofpbuf_init(&request, 0);
nl_msg_put_nlmsghdr(&request,
-sizeof(struct ifinfomsg) + NL_ATTR_SIZE(IFNAMSIZ),
-RTM_GETLINK, NLM_F_REQUEST);
+sizeof(struct ifinfomsg) + NL_ATTR_SIZE(IFNAMSIZ) +
+NL_A_U32_SIZE, RTM_GETLINK, NLM_F_REQUEST);
ofpbuf_put_zeros(&request, sizeof(struct ifinfomsg));
/* The correct identifiers for a Linux device are netnsid and ifindex,
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 net-next] net: openvswitch: Add a new action check_pkt_len
On 3/26/2019 9:31 AM, Pravin Shelar wrote: On Mon, Mar 25, 2019 at 5:44 PM wrote: From: Numan Siddique This patch adds a new action - 'check_pkt_len' which checks the packet length and executes a set of actions if the packet length is greater than the specified length or executes another set of actions if the packet length is lesser or equal to. This action takes below nlattrs * OVS_CHECK_PKT_LEN_ATTR_PKT_LEN - 'pkt_len' to check for * OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_GREATER - Nested actions to apply if the packet length is greater than the specified 'pkt_len' * OVS_CHECK_PKT_LEN_ATTR_ACTIONS_IF_LESS_EQUAL - Nested actions to apply if the packet length is lesser or equal to the specified 'pkt_len'. The main use case for adding this action is to solve the packet drops because of MTU mismatch in OVN virtual networking solution. When a VM (which belongs to a logical switch of OVN) sends a packet destined to go via the gateway router and if the nic which provides external connectivity, has a lesser MTU, OVS drops the packet if the packet length is greater than this MTU. With the help of this action, OVN will check the packet length and if it is greater than the MTU size, it will generate an ICMP packet (type 3, code 4) and includes the next hop mtu in it so that the sender can fragment the packets. Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2018-July/047039.html Suggested-by: Ben Pfaff Signed-off-by: Numan Siddique CC: Gregory Rose CC: Pravin B Shelar --- v1 -> v2 - * Addressed the review comments. - Removed the vlan-tag length when checking the packet length - Reordered the netlink attributes - Changed the comments to use 'attribute' instead of 'action' Corresponding OVS patch (submitted as RFC for now) which makes use of this action can be found here - https://patchwork.ozlabs.org/patch/1059081/ Looks good to me. Acked-by: Pravin B Shelar Tested-by: Greg Rose Reviewed-by: Greg Rose ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 2/5] ovn: Add generic HA chassis group
On Tue, Mar 26, 2019 at 9:59 AM Numan Siddique wrote:
>
>
> Thanks Han for the review. I will address them
> Please see comments inline
>
> Thanks
> Numan
>
>
> On Tue, Mar 26, 2019 at 8:07 AM Han Zhou wrote:
>>
>> Mostly looks good to me, just minor comments.
>>
>> On Thu, Mar 14, 2019 at 12:32 PM wrote:
>> >
>> > +static void
>> > +build_lrouter_groups__(struct hmap *ports, struct ovn_datapath *od)
>> > +{
>> > +ovs_assert((od && od->nbr && od->lr_group));
>> > +
>> > +if (od->l3dgw_port && od->l3redirect_port) {
>> > +/* It's a logical router with gateway port. If it
>> > + * has HA_Chassis_Group associated to it in SB DB, then store the
>> > + * ha chassis group name. */
>> > +if (od->l3redirect_port->sb->ha_chassis_group) {
>> > +sset_add(&od->lr_group->ha_chassis_groups,
>> > + od->l3redirect_port->sb->ha_chassis_group->name);
>> > +}
>> > +}
>> > +
>> > +for (size_t i = 0; i < od->nbr->n_ports; i++) {
>> > +struct ovn_port *router_port =
>> > +ovn_port_find(ports, od->nbr->ports[i]->name);
>> > +
>> > +if (!router_port || !router_port->peer) {
>> > +continue;
>> > +}
>> > +
>> > +/* Get the peer logical switch/logical router datapath. */
>> > +struct ovn_datapath *peer_dp = router_port->peer->od;
>> > +if (peer_dp->nbr) {
>> > +if (!peer_dp->lr_group) {
>> > +peer_dp->lr_group = od->lr_group;
>> > +od->lr_group->router_dps[od->lr_group->n_router_dps++]
>> > += peer_dp;
>> > +build_lrouter_groups__(ports, peer_dp);
>> > +}
>> > +} else {
>> > +for (size_t j = 0; j < peer_dp->n_router_ports; j++) {
>> > +if (!peer_dp->router_ports[j]->peer) {
>> > +/* If there is no peer port connecting to the
>> > +* router datapath, ignore it. */
>>
>> s/router datapath/router port
>>
>> > +continue;
>> > +}
>> > +
>>
>> > +static void
>> > +build_lrouter_groups(struct hmap *ports, struct ovs_list *lr_list)
>> > +{
>> > +struct ovn_datapath *od;
>> > +size_t n_router_dps = ovs_list_size(lr_list);
>> > +
>> > +LIST_FOR_EACH (od, lr_list, lr_list) {
>> > +if (!od->lr_group) {
>> > +od->lr_group = xzalloc(sizeof *od->lr_group);
>> > +/* Each logical router group can have max
>> > + * 'n_router_dps'. So allocate enough memory. */
>> > +od->lr_group->router_dps = xcalloc(sizeof *od, n_router_dps);
>> > +od->lr_group->router_dps[od->lr_group->n_router_dps] = od;
>>
>> Here it is more clear to be: od->lr_group->router_dps[0] = od;
>>
>> > +od->lr_group->n_router_dps = 1;
>> > +sset_init(&od->lr_group->ha_chassis_groups);
>> > +build_lrouter_groups__(ports, od);
>> > +}
>> > +}
>> > +}
>> > +
>>
>> > static void
>> > -destroy_datapaths_and_ports(struct hmap *datapaths, struct hmap *ports)
>> > +destroy_datapaths_and_ports(struct hmap *datapaths, struct hmap *ports,
>> > +struct ovs_list *lr_list)
>> > {
>> > +struct ovn_datapath *router_dp;
>> > +LIST_FOR_EACH_POP (router_dp, lr_list, lr_list) {
>> > +if (router_dp->lr_group) {
>> > +struct lrouter_group *lr_group = router_dp->lr_group;
>> > +
>> > +for (size_t i = 0; i < router_dp->lr_group->n_router_dps;
>> > i++) {
>> > +if (router_dp->lr_group->router_dps[i] != router_dp) {
>>
>> This if-condition seems not needed.
>>
>> > +router_dp->lr_group->router_dps[i]->lr_group = NULL;
>> > +}
>> > +}
>>
>> s/router_dp->lr_group/lr_group in above for-loop.
>>
>> > +
>> > +free(lr_group->router_dps);
>> > +sset_destroy(&lr_group->ha_chassis_groups);
>> > +free(lr_group);
>> > +router_dp->lr_group = NULL;
>> > +}
>> > +}
>> > +
>>
>> > diff --git a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
>> > index 10a59649a..48d27b960 100644
>> > --- a/ovn/ovn-nb.ovsschema
>> > +++ b/ovn/ovn-nb.ovsschema
>> > @@ -1,7 +1,7 @@
>> > {
>> > "name": "OVN_Northbound",
>> > -"version": "5.14.1",
>> > -"cksum": "3758097843 20509",
>> > +"version": "5.15.0",
>> > +"cksum": "1078795414 21917",
>> > "tables": {
>> > "NB_Global": {
>> > "columns": {
>> > @@ -271,6 +271,12 @@
>> > "refType": "strong"},
>> > "min": 0,
>> > "max": "unlimited"}},
>> > +"ha_chassis_group": {
>> > +"type": {"key": {"type": "uuid",
>> > + "refTable": "HA_Chassis_Group",
>> > + "refType": "weak"},
>>
>>
Re: [ovs-dev] [PATCH v2] hmap: Improve debug log message when reporting unusually large buckets.
On Tue, Mar 26, 2019 at 9:58 AM Ben Pfaff wrote:
>
> I was seeing a lot of these messages, including a lot of them suppressed
> by rate-limiting, and I wondered whether any really big messages were
> being suppressed. By reporting the largest bucket, instead of just every
> large bucket, it becomes more likely that the truly too-large buckets get
> reported.
>
> (The problem I saw was a false alarm.)
>
> Signed-off-by: Ben Pfaff
> ---
> v1->v2: Further improve the log message, thanks Han.
>
> lib/hmap.c | 29 -
> 1 file changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/lib/hmap.c b/lib/hmap.c
> index 1ba4a5716a78..9ee05b6d499b 100644
> --- a/lib/hmap.c
> +++ b/lib/hmap.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2008, 2009, 2010, 2012, 2013, 2015 Nicira, Inc.
> + * Copyright (c) 2008, 2009, 2010, 2012, 2013, 2015, 2019 Nicira, Inc.
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
> @@ -103,6 +103,9 @@ resize(struct hmap *hmap, size_t new_mask, const char
> *where)
> tmp.buckets[i] = NULL;
> }
> }
> +int n_big_buckets = 0;
> +int biggest_count = 0;
> +int n_biggest_buckets = 0;
> for (i = 0; i <= hmap->mask; i++) {
> struct hmap_node *node, *next;
> int count = 0;
> @@ -112,14 +115,30 @@ resize(struct hmap *hmap, size_t new_mask, const char
> *where)
> count++;
> }
> if (count > 5) {
> -static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(10, 10);
> -COVERAGE_INC(hmap_pathological);
> -VLOG_DBG_RL(&rl, "%s: %d nodes in bucket (%"PRIuSIZE" nodes,
> %"PRIuSIZE" buckets)",
> -where, count, hmap->n, hmap->mask + 1);
> +n_big_buckets++;
> +if (count > biggest_count) {
> +biggest_count = count;
> +n_biggest_buckets = 1;
> +} else if (count == biggest_count) {
> +n_biggest_buckets++;
> +}
> }
> }
> hmap_swap(hmap, &tmp);
> hmap_destroy(&tmp);
> +
> +if (n_big_buckets) {
> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(10, 10);
> +COVERAGE_INC(hmap_pathological);
> +VLOG_DBG_RL(&rl, "%s: %d bucket%s with 6+ nodes, "
> +"including %d bucket%s with %d nodes "
> +"(%"PRIuSIZE" nodes total across %"PRIuSIZE" buckets)",
> +where,
> +n_big_buckets, n_big_buckets > 1 ? "s" : "",
> +n_biggest_buckets, n_biggest_buckets > 1 ? "s" : "",
> +biggest_count,
> +hmap->n, hmap->mask + 1);
> +}
> }
>
> static size_t
> --
> 2.20.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Thanks Ben!
Acked-by: Han Zhou
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 2/5] ovn: Add generic HA chassis group
On Tue, Mar 26, 2019 at 11:21 PM Han Zhou wrote:
> On Tue, Mar 26, 2019 at 9:59 AM Numan Siddique
> wrote:
> >
> >
> > Thanks Han for the review. I will address them
> > Please see comments inline
> >
> > Thanks
> > Numan
> >
> >
> > On Tue, Mar 26, 2019 at 8:07 AM Han Zhou wrote:
> >>
> >> Mostly looks good to me, just minor comments.
> >>
> >> On Thu, Mar 14, 2019 at 12:32 PM wrote:
> >> >
> >> > +static void
> >> > +build_lrouter_groups__(struct hmap *ports, struct ovn_datapath *od)
> >> > +{
> >> > +ovs_assert((od && od->nbr && od->lr_group));
> >> > +
> >> > +if (od->l3dgw_port && od->l3redirect_port) {
> >> > +/* It's a logical router with gateway port. If it
> >> > + * has HA_Chassis_Group associated to it in SB DB, then
> store the
> >> > + * ha chassis group name. */
> >> > +if (od->l3redirect_port->sb->ha_chassis_group) {
> >> > +sset_add(&od->lr_group->ha_chassis_groups,
> >> > +
> od->l3redirect_port->sb->ha_chassis_group->name);
> >> > +}
> >> > +}
> >> > +
> >> > +for (size_t i = 0; i < od->nbr->n_ports; i++) {
> >> > +struct ovn_port *router_port =
> >> > +ovn_port_find(ports, od->nbr->ports[i]->name);
> >> > +
> >> > +if (!router_port || !router_port->peer) {
> >> > +continue;
> >> > +}
> >> > +
> >> > +/* Get the peer logical switch/logical router datapath. */
> >> > +struct ovn_datapath *peer_dp = router_port->peer->od;
> >> > +if (peer_dp->nbr) {
> >> > +if (!peer_dp->lr_group) {
> >> > +peer_dp->lr_group = od->lr_group;
> >> > +
> od->lr_group->router_dps[od->lr_group->n_router_dps++]
> >> > += peer_dp;
> >> > +build_lrouter_groups__(ports, peer_dp);
> >> > +}
> >> > +} else {
> >> > +for (size_t j = 0; j < peer_dp->n_router_ports; j++) {
> >> > +if (!peer_dp->router_ports[j]->peer) {
> >> > +/* If there is no peer port connecting to the
> >> > +* router datapath, ignore it. */
> >>
> >> s/router datapath/router port
> >>
> >> > +continue;
> >> > +}
> >> > +
> >>
> >> > +static void
> >> > +build_lrouter_groups(struct hmap *ports, struct ovs_list *lr_list)
> >> > +{
> >> > +struct ovn_datapath *od;
> >> > +size_t n_router_dps = ovs_list_size(lr_list);
> >> > +
> >> > +LIST_FOR_EACH (od, lr_list, lr_list) {
> >> > +if (!od->lr_group) {
> >> > +od->lr_group = xzalloc(sizeof *od->lr_group);
> >> > +/* Each logical router group can have max
> >> > + * 'n_router_dps'. So allocate enough memory. */
> >> > +od->lr_group->router_dps = xcalloc(sizeof *od,
> n_router_dps);
> >> > +od->lr_group->router_dps[od->lr_group->n_router_dps] =
> od;
> >>
> >> Here it is more clear to be: od->lr_group->router_dps[0] = od;
> >>
> >> > +od->lr_group->n_router_dps = 1;
> >> > +sset_init(&od->lr_group->ha_chassis_groups);
> >> > +build_lrouter_groups__(ports, od);
> >> > +}
> >> > +}
> >> > +}
> >> > +
> >>
> >> > static void
> >> > -destroy_datapaths_and_ports(struct hmap *datapaths, struct hmap
> *ports)
> >> > +destroy_datapaths_and_ports(struct hmap *datapaths, struct hmap
> *ports,
> >> > +struct ovs_list *lr_list)
> >> > {
> >> > +struct ovn_datapath *router_dp;
> >> > +LIST_FOR_EACH_POP (router_dp, lr_list, lr_list) {
> >> > +if (router_dp->lr_group) {
> >> > +struct lrouter_group *lr_group = router_dp->lr_group;
> >> > +
> >> > +for (size_t i = 0; i <
> router_dp->lr_group->n_router_dps; i++) {
> >> > +if (router_dp->lr_group->router_dps[i] != router_dp)
> {
> >>
> >> This if-condition seems not needed.
> >>
> >> > +router_dp->lr_group->router_dps[i]->lr_group =
> NULL;
> >> > +}
> >> > +}
> >>
> >> s/router_dp->lr_group/lr_group in above for-loop.
> >>
> >> > +
> >> > +free(lr_group->router_dps);
> >> > +sset_destroy(&lr_group->ha_chassis_groups);
> >> > +free(lr_group);
> >> > +router_dp->lr_group = NULL;
> >> > +}
> >> > +}
> >> > +
> >>
> >> > diff --git a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
> >> > index 10a59649a..48d27b960 100644
> >> > --- a/ovn/ovn-nb.ovsschema
> >> > +++ b/ovn/ovn-nb.ovsschema
> >> > @@ -1,7 +1,7 @@
> >> > {
> >> > "name": "OVN_Northbound",
> >> > -"version": "5.14.1",
> >> > -"cksum": "3758097843 20509",
> >> > +"version": "5.15.0",
> >> > +"cksum": "1078795414 21917",
> >> > "tables": {
> >> > "NB_Global": {
> >> > "columns": {
> >> > @@ -271,6 +271,12 @@
> >> > "refType": "strong"},
> >> > "min": 0,
> >> >
Re: [ovs-dev] [PATCH v2] OVN: Add support for Transport Zones
Thanks Lucas, looks good to me.
Acked-by: Mark Michelson
On 3/25/19 2:24 PM, lmart...@redhat.com wrote:
From: Lucas Alvares Gomes
This patch is adding support for Transport Zones. Transport zones (a.k.a
TZs) is way to enable users of OVN to separate Chassis into different
logical groups that will form tunnels only between members of the same
group(s).
Each Chassis can belong to one or more Transport Zones. If not set,
the Chassis will be considered part of a default group; this feature
is backward compatible and did not require any changes to the database
schemas.
Configuring Transport Zones is done by creating a key called
"ovn-transport-zones" in the external_ids of the Open_vSwitch table of the
local OVS instance. The value is a string with the name of the Transport
Zone that this instance is part of. Multiple TZs may be specified with
a comma-separated list. For example:
$ sudo ovs-vsctl set open . external-ids:ovn-transport-zones=tz1
or
$ sudo ovs-vsctl set open . external-ids:ovn-transport-zones=tz1,tz2,tz3
This configuration will be also exposed in the Chassis table of the OVN
Southbound Database so that external systems can see what TZ(s) each
Chassis are part of and make decisions based those values.
The use for Transport Zones includes but are not limited to:
* Edge computing: As a way to preventing edge sites from trying to create
tunnels with every node on every other edge site while still allowing
these sites to create tunnels with the central node.
* Extra security layer: Where users wants to create "trust zones"
and prevent computes in a more secure zone to communicate with a less
secure zone.
Reported-by: Daniel Alvarez Sanchez
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-discuss/2019-February/048255.html
Signed-off-by: Lucas Alvares Gomes
---
v1 -> v2
* Rename the function check_chassis_tzones to chassis_tzones_overlap.
* Fix a memory leak in chassis_tzones_overlap.
* Pass the transport_zones to encaps_run() as a "const char *"
instead of "struct sbrec_chassis". With this we can also avoid not
running the function in case the Chassis entry is not yet created.
NEWS| 3 +
ovn/controller/chassis.c| 8 ++-
ovn/controller/encaps.c | 58 +-
ovn/controller/encaps.h | 3 +-
ovn/controller/ovn-controller.8.xml | 9 +++
ovn/controller/ovn-controller.c | 14 -
tests/ovn.at| 93 +
7 files changed, 183 insertions(+), 5 deletions(-)
diff --git a/NEWS b/NEWS
index 1e4744dbd..4adf49f57 100644
--- a/NEWS
+++ b/NEWS
@@ -24,6 +24,9 @@ Post-v2.11.0
protocol extension.
- OVN:
* Select IPAM mac_prefix in a random manner if not provided by the user
+ * Support for Transport Zones, a way to separate chassis into
+ logical groups which results in tunnels only been formed between
+ members of the same transport zone(s).
- New QoS type "linux-netem" on Linux.
v2.11.0 - 19 Feb 2019
diff --git a/ovn/controller/chassis.c b/ovn/controller/chassis.c
index 3ea908d18..34c260410 100644
--- a/ovn/controller/chassis.c
+++ b/ovn/controller/chassis.c
@@ -139,6 +139,8 @@ chassis_run(struct ovsdb_idl_txn *ovnsb_idl_txn,
const char *datapath_type =
br_int && br_int->datapath_type ? br_int->datapath_type : "";
const char *cms_options = get_cms_options(&cfg->external_ids);
+const char *transport_zones = smap_get_def(&cfg->external_ids,
+ "ovn-transport-zones", "");
struct ds iface_types = DS_EMPTY_INITIALIZER;
ds_put_cstr(&iface_types, "");
@@ -167,18 +169,22 @@ chassis_run(struct ovsdb_idl_txn *ovnsb_idl_txn,
= smap_get_def(&chassis_rec->external_ids, "iface-types", "");
const char *chassis_cms_options
= get_cms_options(&chassis_rec->external_ids);
+const char *chassis_transport_zones = smap_get_def(
+&chassis_rec->external_ids, "ovn-transport-zones", "");
/* If any of the external-ids should change, update them. */
if (strcmp(bridge_mappings, chassis_bridge_mappings) ||
strcmp(datapath_type, chassis_datapath_type) ||
strcmp(iface_types_str, chassis_iface_types) ||
-strcmp(cms_options, chassis_cms_options)) {
+strcmp(cms_options, chassis_cms_options) ||
+strcmp(transport_zones, chassis_transport_zones)) {
struct smap new_ids;
smap_clone(&new_ids, &chassis_rec->external_ids);
smap_replace(&new_ids, "ovn-bridge-mappings", bridge_mappings);
smap_replace(&new_ids, "datapath-type", datapath_type);
smap_replace(&new_ids, "iface-types", iface_types_str);
smap_replace(&new_ids, "ovn-cms-options", cms_options);
+smap_replace(&new_ids, "ovn-transport-zones",
Re: [ovs-dev] [PATCH 2/2] netlink linux: fix to append the netnsid netlink attr.
Flavio Leitner writes:
> The attribute was being prepended to the netlink buffer, but
> the function nl_sock_transact_multiple__() expects to find the
> netlink header as first to update the length, seq and pid fields.
>
> This patch fixes to append the attribute instead of prepending it.
>
> Fixes: 756819ddd788 ("netdev-linux: use netlink to update netdev.")
> 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 1/2] netlink linux: account for the netnsid netlink attr.
Flavio Leitner writes:
> The buffer needs to be reallocated and data copied when
> the netnsid netlink attribute is included, so avoid that
> by accounting the attribute when the buffer is initially
> allocated.
>
> Fixes: 756819ddd788 ("netdev-linux: use netlink to update netdev.")
> 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] faq: Add Q&A for applying patches from email.
Ben Pfaff writes: > Signed-off-by: Ben Pfaff > --- > Documentation/faq/contributing.rst | 49 ++ > 1 file changed, 49 insertions(+) > LGTM! Acked-by: Aaron Conole ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 2/5] ovn: Add generic HA chassis group
On Tue, Mar 26, 2019 at 11:08 AM Numan Siddique wrote:
>
>
>
> On Tue, Mar 26, 2019 at 11:21 PM Han Zhou wrote:
>>
>> On Tue, Mar 26, 2019 at 9:59 AM Numan Siddique wrote:
>> >
>> >
>> > Thanks Han for the review. I will address them
>> > Please see comments inline
>> >
>> > Thanks
>> > Numan
>> >
>> >
>> > On Tue, Mar 26, 2019 at 8:07 AM Han Zhou wrote:
>> >>
>> >> Mostly looks good to me, just minor comments.
>> >>
>> >> On Thu, Mar 14, 2019 at 12:32 PM wrote:
>> >> >
>> >> > +static void
>> >> > +build_lrouter_groups__(struct hmap *ports, struct ovn_datapath *od)
>> >> > +{
>> >> > +ovs_assert((od && od->nbr && od->lr_group));
>> >> > +
>> >> > +if (od->l3dgw_port && od->l3redirect_port) {
>> >> > +/* It's a logical router with gateway port. If it
>> >> > + * has HA_Chassis_Group associated to it in SB DB, then store
>> >> > the
>> >> > + * ha chassis group name. */
>> >> > +if (od->l3redirect_port->sb->ha_chassis_group) {
>> >> > +sset_add(&od->lr_group->ha_chassis_groups,
>> >> > + od->l3redirect_port->sb->ha_chassis_group->name);
>> >> > +}
>> >> > +}
>> >> > +
>> >> > +for (size_t i = 0; i < od->nbr->n_ports; i++) {
>> >> > +struct ovn_port *router_port =
>> >> > +ovn_port_find(ports, od->nbr->ports[i]->name);
>> >> > +
>> >> > +if (!router_port || !router_port->peer) {
>> >> > +continue;
>> >> > +}
>> >> > +
>> >> > +/* Get the peer logical switch/logical router datapath. */
>> >> > +struct ovn_datapath *peer_dp = router_port->peer->od;
>> >> > +if (peer_dp->nbr) {
>> >> > +if (!peer_dp->lr_group) {
>> >> > +peer_dp->lr_group = od->lr_group;
>> >> > +od->lr_group->router_dps[od->lr_group->n_router_dps++]
>> >> > += peer_dp;
>> >> > +build_lrouter_groups__(ports, peer_dp);
>> >> > +}
>> >> > +} else {
>> >> > +for (size_t j = 0; j < peer_dp->n_router_ports; j++) {
>> >> > +if (!peer_dp->router_ports[j]->peer) {
>> >> > +/* If there is no peer port connecting to the
>> >> > +* router datapath, ignore it. */
>> >>
>> >> s/router datapath/router port
>> >>
>> >> > +continue;
>> >> > +}
>> >> > +
>> >>
>> >> > +static void
>> >> > +build_lrouter_groups(struct hmap *ports, struct ovs_list *lr_list)
>> >> > +{
>> >> > +struct ovn_datapath *od;
>> >> > +size_t n_router_dps = ovs_list_size(lr_list);
>> >> > +
>> >> > +LIST_FOR_EACH (od, lr_list, lr_list) {
>> >> > +if (!od->lr_group) {
>> >> > +od->lr_group = xzalloc(sizeof *od->lr_group);
>> >> > +/* Each logical router group can have max
>> >> > + * 'n_router_dps'. So allocate enough memory. */
>> >> > +od->lr_group->router_dps = xcalloc(sizeof *od,
>> >> > n_router_dps);
>> >> > +od->lr_group->router_dps[od->lr_group->n_router_dps] = od;
>> >>
>> >> Here it is more clear to be: od->lr_group->router_dps[0] = od;
>> >>
>> >> > +od->lr_group->n_router_dps = 1;
>> >> > +sset_init(&od->lr_group->ha_chassis_groups);
>> >> > +build_lrouter_groups__(ports, od);
>> >> > +}
>> >> > +}
>> >> > +}
>> >> > +
>> >>
>> >> > static void
>> >> > -destroy_datapaths_and_ports(struct hmap *datapaths, struct hmap *ports)
>> >> > +destroy_datapaths_and_ports(struct hmap *datapaths, struct hmap *ports,
>> >> > +struct ovs_list *lr_list)
>> >> > {
>> >> > +struct ovn_datapath *router_dp;
>> >> > +LIST_FOR_EACH_POP (router_dp, lr_list, lr_list) {
>> >> > +if (router_dp->lr_group) {
>> >> > +struct lrouter_group *lr_group = router_dp->lr_group;
>> >> > +
>> >> > +for (size_t i = 0; i < router_dp->lr_group->n_router_dps;
>> >> > i++) {
>> >> > +if (router_dp->lr_group->router_dps[i] != router_dp) {
>> >>
>> >> This if-condition seems not needed.
>> >>
>> >> > +router_dp->lr_group->router_dps[i]->lr_group =
>> >> > NULL;
>> >> > +}
>> >> > +}
>> >>
>> >> s/router_dp->lr_group/lr_group in above for-loop.
>> >>
>> >> > +
>> >> > +free(lr_group->router_dps);
>> >> > +sset_destroy(&lr_group->ha_chassis_groups);
>> >> > +free(lr_group);
>> >> > +router_dp->lr_group = NULL;
>> >> > +}
>> >> > +}
>> >> > +
>> >>
>> >> > diff --git a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
>> >> > index 10a59649a..48d27b960 100644
>> >> > --- a/ovn/ovn-nb.ovsschema
>> >> > +++ b/ovn/ovn-nb.ovsschema
>> >> > @@ -1,7 +1,7 @@
>> >> > {
>> >> > "name": "OVN_Northbound",
>> >> > -"version": "5.14.1",
>> >> > -"cksum": "3758097843 20509",
>> >> > +"version": "5.15.0",
>> >> > +"cksum": "1078795414 21917",
Re: [ovs-dev] on stock :PIC10F202T-I/OT Microchip 2018+ 0.257
Dear my friend, Good day to you! We are strong independent distributor of electronic ICs, Diodes, Transistors, Capacitors, Resistors, LED,etc. Our strong brand is Microchip, Xilinx, Altera，Micron,Murata,Samsung etc. By the way ,do you need free sample or free shipping fee Hot offer (On stock) Part number Brand D/C Our Price Digikey Price PIC16F876A-I/SP Microchip 2018+ 2.3usd $4.6700 PIC16F877A-I/P Microchip 2018+ 1.99usd $5.0900 LM7815CT Microchip 2018+ 2.73usd $6.5500 LM2575S-3.3 Microchip 2018+ 2.57usd $5.4400 LM2575S-ADJ Microchip 2018+ 1.33usd $2.0900 LM2576S-ADJ Microchip 2017+ 0.95usd $1.8300 Strong lines: Microchip, Xilinx, Altera，Micron(1 piece order;1 year warranty;100 price reference) Irene Sales Manager Hard FindElectronics Ltd. 315, Shahe Rod, Long Gang District, Shenzhen, CN, 518000 Tel: +86-755-8418 8103 Fax: +86-755-8418 8303 Skype: irene.hardfind Follow us: Facebook & Linkedin Email: ir...@hardfindelectronics.com Web: www.hardfindelectronics.com Your trust small quantity & short lead time ISO 9001:2008 Certified distributor Please log in our website for more electronic components If you don't want to receive this mail, pls return with "remove" on the subject line. 如果你不想再收到该产品的推荐邮件，请点击这里退订 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net-next v2] openvswitch: add seqadj extension when NAT is used.
From: Flavio Leitner
Date: Mon, 25 Mar 2019 15:58:31 -0300
> When the conntrack is initialized, there is no helper attached
> yet so the nat info initialization (nf_nat_setup_info) skips
> adding the seqadj ext.
>
> A helper is attached later when the conntrack is not confirmed
> but is going to be committed. In this case, if NAT is needed then
> adds the seqadj ext as well.
>
> Fixes: 16ec3d4fbb96 ("openvswitch: Fix cached ct with helper.")
> Signed-off-by: Flavio Leitner
Applied.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCHv2] lib: added check to prevent int overflow
Looks good to me, thanks.
Reviewed-by: Yifeng Sun
On Wed, Mar 20, 2019 at 1:43 PM Toms Atteka wrote:
>
> If enough large input is given ofpact_finish will fail.
> Implemented ofpbuf_oversized function to check for oversized
> buffer. Checks were added for parse functions and error messages
> returned.
>
> Basic manual testing performed.
>
> Reported-by:
> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=12972
> Signed-off-by: Toms Atteka
>
> v1->v2: added over sized check as a separate function and added
> checks for other parse functions where they might fail.
> ---
> include/openvswitch/ofpbuf.h | 6 ++
> lib/bundle.c | 5 +
> lib/learn.c | 5 +
> lib/ofp-actions.c| 29 +
> 4 files changed, 45 insertions(+)
>
> diff --git a/include/openvswitch/ofpbuf.h b/include/openvswitch/ofpbuf.h
> index e4cf088..1136ba0 100644
> --- a/include/openvswitch/ofpbuf.h
> +++ b/include/openvswitch/ofpbuf.h
> @@ -162,6 +162,7 @@ char *ofpbuf_to_string(const struct ofpbuf *, size_t
> maxbytes);
> static inline struct ofpbuf *ofpbuf_from_list(const struct ovs_list *);
> void ofpbuf_list_delete(struct ovs_list *);
> static inline bool ofpbuf_equal(const struct ofpbuf *, const struct ofpbuf
> *);
> +static inline bool ofpbuf_oversized(const struct ofpbuf *ofpacts);
>
>
> /* Frees memory that 'b' points to, as well as 'b' itself. */
> @@ -272,6 +273,11 @@ static inline bool ofpbuf_equal(const struct ofpbuf *a,
> const struct ofpbuf *b)
> memcmp(a->data, b->data, a->size) == 0;
> }
>
> +static inline bool ofpbuf_oversized(const struct ofpbuf *ofpacts)
> +{
> +return (char *)ofpbuf_tail(ofpacts) - (char *)ofpacts->header >
> UINT16_MAX;
> +}
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/bundle.c b/lib/bundle.c
> index 558e890..edb11f6 100644
> --- a/lib/bundle.c
> +++ b/lib/bundle.c
> @@ -183,6 +183,11 @@ bundle_parse__(const char *s, const struct
> ofputil_port_map *port_map,
> bundle = ofpacts->header;
> bundle->n_slaves++;
> }
> +
> +if (ofpbuf_oversized(ofpacts)) {
> +return xasprintf("input too big");
> +}
> +
> ofpact_finish_BUNDLE(ofpacts, &bundle);
> bundle->basis = atoi(basis);
>
> diff --git a/lib/learn.c b/lib/learn.c
> index 642ce18..a40209e 100644
> --- a/lib/learn.c
> +++ b/lib/learn.c
> @@ -455,6 +455,11 @@ learn_parse__(char *orig, char *arg, const struct
> ofputil_port_map *port_map,
> learn = ofpacts->header;
> }
> }
> +
> +if (ofpbuf_oversized(ofpacts)) {
> +return xasprintf("input too big");
> +}
> +
> ofpact_finish_LEARN(ofpacts, &learn);
>
> return NULL;
> diff --git a/lib/ofp-actions.c b/lib/ofp-actions.c
> index e8e88ac..1340614 100644
> --- a/lib/ofp-actions.c
> +++ b/lib/ofp-actions.c
> @@ -989,6 +989,11 @@ parse_CONTROLLER(char *arg, const struct
> ofpact_parse_params *pp)
> controller = pp->ofpacts->header;
> controller->userdata_len = userdata_len;
> }
> +
> +if (ofpbuf_oversized(pp->ofpacts)) {
> +return xasprintf("input too big");
> +}
> +
> ofpact_finish_CONTROLLER(pp->ofpacts, &controller);
> }
>
> @@ -3690,6 +3695,11 @@ parse_DEC_TTL(char *arg, const struct
> ofpact_parse_params *pp)
> return xstrdup("dec_ttl_cnt_ids: expected at least one
> controller "
> "id.");
> }
> +
> +if (ofpbuf_oversized(pp->ofpacts)) {
> +return xasprintf("input too big");
> +}
> +
> ofpact_finish_DEC_TTL(pp->ofpacts, &ids);
> }
> return NULL;
> @@ -4443,6 +4453,11 @@ parse_ENCAP(char *arg, const struct
> ofpact_parse_params *pp)
> /* ofpbuf may have been re-allocated. */
> encap = pp->ofpacts->header;
> encap->n_props = n_props;
> +
> +if (ofpbuf_oversized(pp->ofpacts)) {
> +return xasprintf("input too big");
> +}
> +
> ofpact_finish_ENCAP(pp->ofpacts, &encap);
> return NULL;
> }
> @@ -5772,6 +5787,11 @@ parse_NOTE(const char *arg, const struct
> ofpact_parse_params *pp)
> struct ofpact_note *note = ofpbuf_at_assert(pp->ofpacts, start_ofs,
> sizeof *note);
> note->length = pp->ofpacts->size - (start_ofs + sizeof *note);
> +
> +if (ofpbuf_oversized(pp->ofpacts)) {
> +return xasprintf("input too big");
> +}
> +
> ofpact_finish_NOTE(pp->ofpacts, ¬e);
> return NULL;
> }
> @@ -5929,6 +5949,10 @@ parse_CLONE(char *arg, const struct
> ofpact_parse_params *pp)
> pp->ofpacts->header = ofpbuf_push_uninit(pp->ofpacts, sizeof *clone);
> clone = pp->ofpacts->header;
>
> +if (ofpbuf_oversized(pp->ofpacts)) {
> +return xasprintf("input too big");
> +}
> +
> ofpact_finish_CLONE(pp->ofpacts, &clone);
> ofpbuf_push_uninit(pp->ofpacts, clone_offset);
> return
[ovs-dev] OVN/OVS Split POC: version 2
I've once again rolled another OVN/OVS split version. It can be found at https://github.com/putnopvut/ovn_mk2.git The main changes between this and the old split POC are as follows: * This is based on a much newer build of OVS master. Therefore, build errors people had with dhparams.c *should* be cleared up. * This fixes errors with manpages.mk generation/checking, so there is no need to do a pointless `touch` of manpages.mk during the build process. * In many cases, rather than hard-coding paths to OVS, we use variables. This isn't universally applied, but it's used for the locations of C headers, libraries, and manpages. Please give this a look and let me know what you think. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] faq: Add Q&A for applying patches from email.
On Tue, Mar 26, 2019 at 02:51:10PM -0400, Aaron Conole wrote: > Ben Pfaff writes: > > > Signed-off-by: Ben Pfaff > > --- > > Documentation/faq/contributing.rst | 49 ++ > > 1 file changed, 49 insertions(+) > > > > LGTM! > > Acked-by: Aaron Conole Thanks, applied to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] hmap: Improve debug log message when reporting unusually large buckets.
On Tue, Mar 26, 2019 at 10:55:34AM -0700, Han Zhou wrote: > On Tue, Mar 26, 2019 at 9:58 AM Ben Pfaff wrote: > > > > I was seeing a lot of these messages, including a lot of them suppressed > > by rate-limiting, and I wondered whether any really big messages were > > being suppressed. By reporting the largest bucket, instead of just every > > large bucket, it becomes more likely that the truly too-large buckets get > > reported. > > > > (The problem I saw was a false alarm.) > > > > Signed-off-by: Ben Pfaff > > --- > > v1->v2: Further improve the log message, thanks Han. > > Thanks Ben! > > Acked-by: Han Zhou Thanks, applied to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovsdb-idl.c: Remove meaningless MAX().
On Wed, Mar 20, 2019 at 10:48:22PM -0700, Han Zhou wrote: > From: Han Zhou > > In the else condition, it is already ensured that index >= idl->min_index. > So the MAX() is confusing and misleading here. > > Signed-off-by: Han Zhou Thanks, applied to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH net-next 0/8] openvswitch: load and reference the NAT helper.
The request_module() is quite expensive and triggers the usermode helper in userspace. Instead, load only if the module is not present and keep module references to avoid problems. The first patch standardize the module alias which is already there, but not in a formal way. The second patch adds an API to point to the NAT helper. The following patches will register each NAT helper using the new API. The last patch fixes openvswitch to use the new API to load and reference the NAT helper and also report an error if the operation fails. Flavio Leitner (8): netfilter: use macros to create module aliases. netfilter: add API to manage NAT helpers. netfilter: nf_nat: register amanda NAT helper. netfilter: nf_nat: register ftp NAT helper. netfilter: nf_nat: register irc NAT helper. netfilter: nf_nat: register sip NAT helper. netfilter: nf_nat: register tftp NAT helper. openvswitch: load and reference the NAT helper. include/net/netfilter/nf_conntrack_helper.h | 23 - net/ipv4/netfilter/nf_nat_h323.c| 2 +- net/ipv4/netfilter/nf_nat_pptp.c| 2 +- net/netfilter/nf_conntrack_amanda.c | 2 + net/netfilter/nf_conntrack_ftp.c| 6 +- net/netfilter/nf_conntrack_helper.c | 108 +++- net/netfilter/nf_conntrack_irc.c| 3 +- net/netfilter/nf_conntrack_sane.c | 4 +- net/netfilter/nf_conntrack_sip.c| 12 ++- net/netfilter/nf_conntrack_tftp.c | 6 +- net/netfilter/nf_nat_amanda.c | 9 +- net/netfilter/nf_nat_ftp.c | 8 +- net/netfilter/nf_nat_irc.c | 8 +- net/netfilter/nf_nat_sip.c | 8 +- net/netfilter/nf_nat_tftp.c | 8 +- net/openvswitch/conntrack.c | 27 +++-- 16 files changed, 209 insertions(+), 27 deletions(-) -- 2.20.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH net-next 1/8] netfilter: use macros to create module aliases.
Each NAT helper creates a module alias which follows a pattern.
Use macros for consistency.
Signed-off-by: Flavio Leitner
---
include/net/netfilter/nf_conntrack_helper.h | 4
net/ipv4/netfilter/nf_nat_h323.c| 2 +-
net/ipv4/netfilter/nf_nat_pptp.c| 2 +-
net/netfilter/nf_nat_amanda.c | 2 +-
net/netfilter/nf_nat_ftp.c | 2 +-
net/netfilter/nf_nat_irc.c | 2 +-
net/netfilter/nf_nat_sip.c | 2 +-
net/netfilter/nf_nat_tftp.c | 2 +-
8 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_helper.h
b/include/net/netfilter/nf_conntrack_helper.h
index ec52a8dc32fd..e86fadf7e7c5 100644
--- a/include/net/netfilter/nf_conntrack_helper.h
+++ b/include/net/netfilter/nf_conntrack_helper.h
@@ -15,6 +15,10 @@
#include
#include
+#define NF_CT_NAT_HELPER_MOD_NAME(name)"ip_nat_" name
+#define MODULE_ALIAS_NFCT_HELPER_NAT(name) \
+ MODULE_ALIAS(NF_CT_NAT_HELPER_MOD_NAME(name))
+
struct module;
enum nf_ct_helper_flags {
diff --git a/net/ipv4/netfilter/nf_nat_h323.c b/net/ipv4/netfilter/nf_nat_h323.c
index 4e6b53ab6c33..09754e787692 100644
--- a/net/ipv4/netfilter/nf_nat_h323.c
+++ b/net/ipv4/netfilter/nf_nat_h323.c
@@ -631,4 +631,4 @@ module_exit(fini);
MODULE_AUTHOR("Jing Min Zhao ");
MODULE_DESCRIPTION("H.323 NAT helper");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("ip_nat_h323");
+MODULE_ALIAS_NFCT_HELPER_NAT("h323");
diff --git a/net/ipv4/netfilter/nf_nat_pptp.c b/net/ipv4/netfilter/nf_nat_pptp.c
index 68b4d450391b..1a984e5db88a 100644
--- a/net/ipv4/netfilter/nf_nat_pptp.c
+++ b/net/ipv4/netfilter/nf_nat_pptp.c
@@ -37,7 +37,7 @@
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Harald Welte ");
MODULE_DESCRIPTION("Netfilter NAT helper module for PPTP");
-MODULE_ALIAS("ip_nat_pptp");
+MODULE_ALIAS_NFCT_HELPER_NAT("pptp");
static void pptp_nat_expected(struct nf_conn *ct,
struct nf_conntrack_expect *exp)
diff --git a/net/netfilter/nf_nat_amanda.c b/net/netfilter/nf_nat_amanda.c
index e4d61a7a5258..e87075763f73 100644
--- a/net/netfilter/nf_nat_amanda.c
+++ b/net/netfilter/nf_nat_amanda.c
@@ -22,7 +22,7 @@
MODULE_AUTHOR("Brian J. Murrell ");
MODULE_DESCRIPTION("Amanda NAT helper");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("ip_nat_amanda");
+MODULE_ALIAS_NFCT_HELPER_NAT("amanda");
static unsigned int help(struct sk_buff *skb,
enum ip_conntrack_info ctinfo,
diff --git a/net/netfilter/nf_nat_ftp.c b/net/netfilter/nf_nat_ftp.c
index 5063cbf1689c..19f5739fd5e2 100644
--- a/net/netfilter/nf_nat_ftp.c
+++ b/net/netfilter/nf_nat_ftp.c
@@ -24,7 +24,7 @@
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Rusty Russell ");
MODULE_DESCRIPTION("ftp NAT helper");
-MODULE_ALIAS("ip_nat_ftp");
+MODULE_ALIAS_NFCT_HELPER_NAT("ftp");
/* FIXME: Time out? --RR */
diff --git a/net/netfilter/nf_nat_irc.c b/net/netfilter/nf_nat_irc.c
index 3aa35a43100d..c18e3ce6589b 100644
--- a/net/netfilter/nf_nat_irc.c
+++ b/net/netfilter/nf_nat_irc.c
@@ -26,7 +26,7 @@
MODULE_AUTHOR("Harald Welte ");
MODULE_DESCRIPTION("IRC (DCC) NAT helper");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("ip_nat_irc");
+MODULE_ALIAS_NFCT_HELPER_NAT("irc");
static unsigned int help(struct sk_buff *skb,
enum ip_conntrack_info ctinfo,
diff --git a/net/netfilter/nf_nat_sip.c b/net/netfilter/nf_nat_sip.c
index aa1be643d7a0..f31c2a1b95b8 100644
--- a/net/netfilter/nf_nat_sip.c
+++ b/net/netfilter/nf_nat_sip.c
@@ -27,7 +27,7 @@
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Christian Hentschel ");
MODULE_DESCRIPTION("SIP NAT helper");
-MODULE_ALIAS("ip_nat_sip");
+MODULE_ALIAS_NFCT_HELPER_NAT("sip");
static unsigned int mangle_packet(struct sk_buff *skb, unsigned int protoff,
diff --git a/net/netfilter/nf_nat_tftp.c b/net/netfilter/nf_nat_tftp.c
index 7f67e1d5310d..51673aa6e1dc 100644
--- a/net/netfilter/nf_nat_tftp.c
+++ b/net/netfilter/nf_nat_tftp.c
@@ -16,7 +16,7 @@
MODULE_AUTHOR("Magnus Boden ");
MODULE_DESCRIPTION("TFTP NAT helper");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("ip_nat_tftp");
+MODULE_ALIAS_NFCT_HELPER_NAT("tftp");
static unsigned int help(struct sk_buff *skb,
enum ip_conntrack_info ctinfo,
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] bridge: Propagate patch port pairing errors to db.
On Mon, Mar 25, 2019 at 12:48:34PM +0100, Eelco Chaudron wrote:
>
>
> On 22 Mar 2019, at 13:58, Ilya Maximets wrote:
>
> > Virtual ports like 'patch' ports that almost fully implemented on
> > 'ofproto' layer could have internal to 'ofproto' statuses that
> > could not be retrieved from 'netdev' or other layers. For example,
> > in current implementation there is no way to get the patch port
> > pairing status (i.e. if it has usable peer?).
> >
> > New 'ofproto-provider' API function 'vport_get_status' introduced to
> > cover this gap. It allowes 'bridge' layer to retrive current status
> > of ofproto virtual ports and propagate it to DB.
> > For now we're only interested in pairing errors of 'patch' ports.
> > That are propagated to the 'error' column of the 'Interface' table.
> >
> > Ex.:
> >
> > $ ovs-vsctl show
> > ...
> > Bridge "br1"
> > ...
> > Port "patch1"
> > Interface "patch1"
> > type: patch
> > options: {peer="patch0"}
> > error: "No usable peer 'patch0' exists in 'system' datapath."
> >
> > Bridge "br0"
> > datapath_type: netdev
> > ...
> > Port "patch0"
> > Interface "patch0"
> > type: patch
> > options: {peer="patch1"}
> > error: "No usable peer 'patch1' exists in 'netdev' datapath."
> >
> > Signed-off-by: Ilya Maximets
>
> Thanks for taking care of this Ilya!
>
> Acked-by: Eelco Chaudron
Thanks, Ilya (and Eelco). I applied this to master.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH net-next 2/8] netfilter: add API to manage NAT helpers.
The API allows a conntrack helper to indicate its corresponding
NAT helper which then can be loaded and reference counted.
Signed-off-by: Flavio Leitner
---
include/net/netfilter/nf_conntrack_helper.h | 19 +++-
net/netfilter/nf_conntrack_amanda.c | 2 +
net/netfilter/nf_conntrack_ftp.c| 6 +-
net/netfilter/nf_conntrack_helper.c | 108 +++-
net/netfilter/nf_conntrack_irc.c| 3 +-
net/netfilter/nf_conntrack_sane.c | 4 +-
net/netfilter/nf_conntrack_sip.c| 12 ++-
net/netfilter/nf_conntrack_tftp.c | 6 +-
8 files changed, 147 insertions(+), 13 deletions(-)
diff --git a/include/net/netfilter/nf_conntrack_helper.h
b/include/net/netfilter/nf_conntrack_helper.h
index e86fadf7e7c5..0d36d6bfb522 100644
--- a/include/net/netfilter/nf_conntrack_helper.h
+++ b/include/net/netfilter/nf_conntrack_helper.h
@@ -58,6 +58,8 @@ struct nf_conntrack_helper {
unsigned int queue_num;
/* length of userspace private data stored in nf_conn_help->data */
u16 data_len;
+ /* name of NAT helper module */
+ char nat_mod_name[NF_CT_HELPER_NAME_LEN];
};
/* Must be kept in sync with the classes defined by helpers */
@@ -98,7 +100,8 @@ void nf_ct_helper_init(struct nf_conntrack_helper *helper,
enum ip_conntrack_info ctinfo),
int (*from_nlattr)(struct nlattr *attr,
struct nf_conn *ct),
- struct module *module);
+ struct module *module,
+ const char *nat_mod_name);
int nf_conntrack_helper_register(struct nf_conntrack_helper *);
void nf_conntrack_helper_unregister(struct nf_conntrack_helper *);
@@ -157,4 +160,18 @@ nf_ct_helper_expectfn_find_by_symbol(const void *symbol);
extern struct hlist_head *nf_ct_helper_hash;
extern unsigned int nf_ct_helper_hsize;
+struct nf_conntrack_helper_nat {
+ struct list_head list;
+ char name[NF_CT_HELPER_NAME_LEN];
+ struct module *module; /* pointer to self */
+};
+
+void nf_ct_helper_nat_init(struct nf_conntrack_helper_nat *nat,
+ const char *name, struct module *module);
+
+void nf_conntrack_helper_nat_register(struct nf_conntrack_helper_nat *nat);
+void nf_conntrack_helper_nat_unregister(struct nf_conntrack_helper_nat *nat);
+int nf_conntrack_helper_nat_try_module_get(const char *name, u16 l3num,
+ u8 protonum);
+void nf_conntrack_helper_nat_put(struct nf_conntrack_helper *helper);
#endif /*_NF_CONNTRACK_HELPER_H*/
diff --git a/net/netfilter/nf_conntrack_amanda.c
b/net/netfilter/nf_conntrack_amanda.c
index f2681ec5b5f6..b5d255897d9e 100644
--- a/net/netfilter/nf_conntrack_amanda.c
+++ b/net/netfilter/nf_conntrack_amanda.c
@@ -186,6 +186,7 @@ static struct nf_conntrack_helper amanda_helper[2]
__read_mostly = {
.tuple.src.u.udp.port = cpu_to_be16(10080),
.tuple.dst.protonum = IPPROTO_UDP,
.expect_policy = &amanda_exp_policy,
+ .nat_mod_name = NF_CT_NAT_HELPER_MOD_NAME("amanda"),
},
{
.name = "amanda",
@@ -195,6 +196,7 @@ static struct nf_conntrack_helper amanda_helper[2]
__read_mostly = {
.tuple.src.u.udp.port = cpu_to_be16(10080),
.tuple.dst.protonum = IPPROTO_UDP,
.expect_policy = &amanda_exp_policy,
+ .nat_mod_name = NF_CT_NAT_HELPER_MOD_NAME("amanda"),
},
};
diff --git a/net/netfilter/nf_conntrack_ftp.c b/net/netfilter/nf_conntrack_ftp.c
index a11c304fb771..fec9bb462071 100644
--- a/net/netfilter/nf_conntrack_ftp.c
+++ b/net/netfilter/nf_conntrack_ftp.c
@@ -590,10 +590,12 @@ static int __init nf_conntrack_ftp_init(void)
for (i = 0; i < ports_c; i++) {
nf_ct_helper_init(&ftp[2 * i], AF_INET, IPPROTO_TCP, "ftp",
FTP_PORT, ports[i], ports[i], &ftp_exp_policy,
- 0, help, nf_ct_ftp_from_nlattr, THIS_MODULE);
+ 0, help, nf_ct_ftp_from_nlattr, THIS_MODULE,
+ NF_CT_NAT_HELPER_MOD_NAME("ftp"));
nf_ct_helper_init(&ftp[2 * i + 1], AF_INET6, IPPROTO_TCP, "ftp",
FTP_PORT, ports[i], ports[i], &ftp_exp_policy,
- 0, help, nf_ct_ftp_from_nlattr, THIS_MODULE);
+ 0, help, nf_ct_ftp_from_nlattr, THIS_MODULE,
+ NF_CT_NAT_HELPER_MOD_NAME("ftp"));
}
ret = nf_conntrack_helpers_register(ftp, ports_c * 2);
diff --git a/net/netfilter/nf_conntrack_helper.c
b/net/netfilter/nf_conntrack_helper.c
index 274baf1dab87..883a8d438503 100644
--- a/net/netfilter/nf_conntrack_helper.c
+++ b/ne
[ovs-dev] [PATCH net-next 3/8] netfilter: nf_nat: register amanda NAT helper.
Signed-off-by: Flavio Leitner
---
net/netfilter/nf_nat_amanda.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/netfilter/nf_nat_amanda.c b/net/netfilter/nf_nat_amanda.c
index e87075763f73..344096418224 100644
--- a/net/netfilter/nf_nat_amanda.c
+++ b/net/netfilter/nf_nat_amanda.c
@@ -24,6 +24,8 @@ MODULE_DESCRIPTION("Amanda NAT helper");
MODULE_LICENSE("GPL");
MODULE_ALIAS_NFCT_HELPER_NAT("amanda");
+static struct nf_conntrack_helper_nat helper_nat_amanda;
+
static unsigned int help(struct sk_buff *skb,
enum ip_conntrack_info ctinfo,
unsigned int protoff,
@@ -74,6 +76,7 @@ static unsigned int help(struct sk_buff *skb,
static void __exit nf_nat_amanda_fini(void)
{
+ nf_conntrack_helper_nat_unregister(&helper_nat_amanda);
RCU_INIT_POINTER(nf_nat_amanda_hook, NULL);
synchronize_rcu();
}
@@ -81,6 +84,10 @@ static void __exit nf_nat_amanda_fini(void)
static int __init nf_nat_amanda_init(void)
{
BUG_ON(nf_nat_amanda_hook != NULL);
+ nf_ct_helper_nat_init(&helper_nat_amanda,
+ NF_CT_NAT_HELPER_MOD_NAME("amanda"),
+ THIS_MODULE);
+ nf_conntrack_helper_nat_register(&helper_nat_amanda);
RCU_INIT_POINTER(nf_nat_amanda_hook, help);
return 0;
}
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH net-next 4/8] netfilter: nf_nat: register ftp NAT helper.
Signed-off-by: Flavio Leitner
---
net/netfilter/nf_nat_ftp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/netfilter/nf_nat_ftp.c b/net/netfilter/nf_nat_ftp.c
index 19f5739fd5e2..70fddcddad54 100644
--- a/net/netfilter/nf_nat_ftp.c
+++ b/net/netfilter/nf_nat_ftp.c
@@ -28,6 +28,8 @@ MODULE_ALIAS_NFCT_HELPER_NAT("ftp");
/* FIXME: Time out? --RR */
+static struct nf_conntrack_helper_nat helper_nat_ftp;
+
static int nf_nat_ftp_fmt_cmd(struct nf_conn *ct, enum nf_ct_ftp_type type,
char *buffer, size_t buflen,
union nf_inet_addr *addr, u16 port)
@@ -124,6 +126,7 @@ static unsigned int nf_nat_ftp(struct sk_buff *skb,
static void __exit nf_nat_ftp_fini(void)
{
+ nf_conntrack_helper_nat_unregister(&helper_nat_ftp);
RCU_INIT_POINTER(nf_nat_ftp_hook, NULL);
synchronize_rcu();
}
@@ -131,6 +134,9 @@ static void __exit nf_nat_ftp_fini(void)
static int __init nf_nat_ftp_init(void)
{
BUG_ON(nf_nat_ftp_hook != NULL);
+ nf_ct_helper_nat_init(&helper_nat_ftp,
+ NF_CT_NAT_HELPER_MOD_NAME("ftp"), THIS_MODULE);
+ nf_conntrack_helper_nat_register(&helper_nat_ftp);
RCU_INIT_POINTER(nf_nat_ftp_hook, nf_nat_ftp);
return 0;
}
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH net-next 5/8] netfilter: nf_nat: register irc NAT helper.
Signed-off-by: Flavio Leitner
---
net/netfilter/nf_nat_irc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/netfilter/nf_nat_irc.c b/net/netfilter/nf_nat_irc.c
index c18e3ce6589b..853e91c1cea5 100644
--- a/net/netfilter/nf_nat_irc.c
+++ b/net/netfilter/nf_nat_irc.c
@@ -28,6 +28,8 @@ MODULE_DESCRIPTION("IRC (DCC) NAT helper");
MODULE_LICENSE("GPL");
MODULE_ALIAS_NFCT_HELPER_NAT("irc");
+static struct nf_conntrack_helper_nat helper_nat_irc;
+
static unsigned int help(struct sk_buff *skb,
enum ip_conntrack_info ctinfo,
unsigned int protoff,
@@ -96,6 +98,7 @@ static unsigned int help(struct sk_buff *skb,
static void __exit nf_nat_irc_fini(void)
{
+ nf_conntrack_helper_nat_unregister(&helper_nat_irc);
RCU_INIT_POINTER(nf_nat_irc_hook, NULL);
synchronize_rcu();
}
@@ -103,6 +106,9 @@ static void __exit nf_nat_irc_fini(void)
static int __init nf_nat_irc_init(void)
{
BUG_ON(nf_nat_irc_hook != NULL);
+ nf_ct_helper_nat_init(&helper_nat_irc,
+ NF_CT_NAT_HELPER_MOD_NAME("irc"), THIS_MODULE);
+ nf_conntrack_helper_nat_register(&helper_nat_irc);
RCU_INIT_POINTER(nf_nat_irc_hook, help);
return 0;
}
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH net-next 7/8] netfilter: nf_nat: register tftp NAT helper.
Signed-off-by: Flavio Leitner
---
net/netfilter/nf_nat_tftp.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/netfilter/nf_nat_tftp.c b/net/netfilter/nf_nat_tftp.c
index 51673aa6e1dc..5a7af30e3e02 100644
--- a/net/netfilter/nf_nat_tftp.c
+++ b/net/netfilter/nf_nat_tftp.c
@@ -18,6 +18,8 @@ MODULE_DESCRIPTION("TFTP NAT helper");
MODULE_LICENSE("GPL");
MODULE_ALIAS_NFCT_HELPER_NAT("tftp");
+static struct nf_conntrack_helper_nat helper_nat_tftp;
+
static unsigned int help(struct sk_buff *skb,
enum ip_conntrack_info ctinfo,
struct nf_conntrack_expect *exp)
@@ -37,6 +39,7 @@ static unsigned int help(struct sk_buff *skb,
static void __exit nf_nat_tftp_fini(void)
{
+ nf_conntrack_helper_nat_unregister(&helper_nat_tftp);
RCU_INIT_POINTER(nf_nat_tftp_hook, NULL);
synchronize_rcu();
}
@@ -44,6 +47,9 @@ static void __exit nf_nat_tftp_fini(void)
static int __init nf_nat_tftp_init(void)
{
BUG_ON(nf_nat_tftp_hook != NULL);
+ nf_ct_helper_nat_init(&helper_nat_tftp,
+ NF_CT_NAT_HELPER_MOD_NAME("tftp"), THIS_MODULE);
+ nf_conntrack_helper_nat_register(&helper_nat_tftp);
RCU_INIT_POINTER(nf_nat_tftp_hook, help);
return 0;
}
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH net-next 6/8] netfilter: nf_nat: register sip NAT helper.
Signed-off-by: Flavio Leitner
---
net/netfilter/nf_nat_sip.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nf_nat_sip.c b/net/netfilter/nf_nat_sip.c
index f31c2a1b95b8..42b3d2e7ecbd 100644
--- a/net/netfilter/nf_nat_sip.c
+++ b/net/netfilter/nf_nat_sip.c
@@ -29,6 +29,7 @@ MODULE_AUTHOR("Christian Hentschel
");
MODULE_DESCRIPTION("SIP NAT helper");
MODULE_ALIAS_NFCT_HELPER_NAT("sip");
+static struct nf_conntrack_helper_nat helper_nat_sip;
static unsigned int mangle_packet(struct sk_buff *skb, unsigned int protoff,
unsigned int dataoff,
@@ -656,8 +657,8 @@ static struct nf_ct_helper_expectfn sip_nat = {
static void __exit nf_nat_sip_fini(void)
{
+ nf_conntrack_helper_nat_unregister(&helper_nat_sip);
RCU_INIT_POINTER(nf_nat_sip_hooks, NULL);
-
nf_ct_helper_expectfn_unregister(&sip_nat);
synchronize_rcu();
}
@@ -675,6 +676,9 @@ static const struct nf_nat_sip_hooks sip_hooks = {
static int __init nf_nat_sip_init(void)
{
BUG_ON(nf_nat_sip_hooks != NULL);
+ nf_ct_helper_nat_init(&helper_nat_sip,
+ NF_CT_NAT_HELPER_MOD_NAME("sip"), THIS_MODULE);
+ nf_conntrack_helper_nat_register(&helper_nat_sip);
RCU_INIT_POINTER(nf_nat_sip_hooks, &sip_hooks);
nf_ct_helper_expectfn_register(&sip_nat);
return 0;
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH net-next 8/8] openvswitch: load and reference the NAT helper.
This improves the original commit 17c357efe5ec ("openvswitch: load
NAT helper") where it unconditionally tries to load the module for
every flow using NAT, so not efficient when loading multiple flows.
It also doesn't hold any references to the NAT module while the
flow is active.
This change fixes those problems. It will try to load the module
only if it's not present. It grabs a reference to the NAT module
and holds it while the flow is active. Finally, an error message
shows up if either actions above fails.
Fixes: 17c357efe5ec ("openvswitch: load NAT helper")
Signed-off-by: Flavio Leitner
---
net/openvswitch/conntrack.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 845b83598e0d..fb58637a27c9 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -1305,6 +1305,7 @@ static int ovs_ct_add_helper(struct ovs_conntrack_info
*info, const char *name,
{
struct nf_conntrack_helper *helper;
struct nf_conn_help *help;
+ int ret = 0;
helper = nf_conntrack_helper_try_module_get(name, info->family,
key->ip.proto);
@@ -1319,13 +1320,22 @@ static int ovs_ct_add_helper(struct ovs_conntrack_info
*info, const char *name,
return -ENOMEM;
}
+#ifdef CONFIG_NF_NAT_NEEDED
+ if (info->nat) {
+ ret = nf_conntrack_helper_nat_try_module_get(name,
+info->family,
+key->ip.proto);
+ if (ret) {
+ nf_conntrack_helper_put(helper);
+ OVS_NLERR(log, "Failed to load \"%s\" NAT helper, err:
%d",
+ name, ret);
+ return ret;
+ }
+ }
+#endif
rcu_assign_pointer(help->helper, helper);
info->helper = helper;
-
- if (info->nat)
- request_module("ip_nat_%s", name);
-
- return 0;
+ return ret;
}
#ifdef CONFIG_NF_NAT_NEEDED
@@ -1776,8 +1786,13 @@ void ovs_ct_free_action(const struct nlattr *a)
static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info)
{
- if (ct_info->helper)
+ if (ct_info->helper) {
+#ifdef CONFIG_NF_NAT_NEEDED
+ if (ct_info->nat)
+ nf_conntrack_helper_nat_put(ct_info->helper);
+#endif
nf_conntrack_helper_put(ct_info->helper);
+ }
if (ct_info->ct)
nf_ct_tmpl_free(ct_info->ct);
}
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] stream-ssl: Add support for TLS SNI (Server Name Indication).
Looks good to me, thanks.
Tested-by: Yifeng Sun
Reviewed-by: Yifeng Sun
On Wed, Mar 20, 2019 at 5:39 PM Ben Pfaff wrote:
>
> This TLS extension, introduced in RFC 3546, allows the server to know what
> host the client believes it is contacting, the TLS equivalent of the Host:
> header in HTTP.
>
> Requested-by: Shivaram Mysore
> Signed-off-by: Ben Pfaff
> ---
> NEWS | 2 ++
> lib/stream-ssl.c | 63 ++
> m4/openvswitch.m4 | 23 ++---
> tests/atlocal.in | 2 ++
> tests/ovs-vsctl.at | 20 +++
> 5 files changed, 102 insertions(+), 8 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index 1e4744dbd244..0f8d02817e61 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -25,6 +25,8 @@ Post-v2.11.0
> - OVN:
> * Select IPAM mac_prefix in a random manner if not provided by the user
> - New QoS type "linux-netem" on Linux.
> + - Added support for TLS Server Name Indication (SNI).
> +
>
> v2.11.0 - 19 Feb 2019
> -
> diff --git a/lib/stream-ssl.c b/lib/stream-ssl.c
> index fed71801b823..81f2409965b2 100644
> --- a/lib/stream-ssl.c
> +++ b/lib/stream-ssl.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016
> Nicira, Inc.
> + * Copyright (c) 2008-2016, 2019 Nicira, Inc.
> *
> * Licensed under the Apache License, Version 2.0 (the "License");
> * you may not use this file except in compliance with the License.
> @@ -220,9 +220,19 @@ want_to_poll_events(int want)
> }
> }
>
> -/* Takes ownership of 'name'. */
> +/* Creates a new SSL connection based on socket 'fd', as either a client or a
> + * server according to 'type', initially in 'state'. On success, returns 0
> and
> + * stores the new stream in '*streamp', otherwise returns an errno value and
> + * doesn't bother with '*streamp'.
> + *
> + * Takes ownership of 'name', which should be the name of the connection in
> the
> + * format that would be used to connect to it, e.g. "ssl:1.2.3.4:5".
> + *
> + * For client connections, 'server_name' should be the host name of the
> server
> + * being connected to, for use with SSL SNI (server name indication). Takes
> + * ownership of 'server_name'. */
> static int
> -new_ssl_stream(char *name, int fd, enum session_type type,
> +new_ssl_stream(char *name, char *server_name, int fd, enum session_type type,
> enum ssl_state state, struct stream **streamp)
> {
> struct ssl_stream *sslv;
> @@ -274,6 +284,14 @@ new_ssl_stream(char *name, int fd, enum session_type
> type,
> if (!verify_peer_cert || (bootstrap_ca_cert && type == CLIENT)) {
> SSL_set_verify(ssl, SSL_VERIFY_NONE, NULL);
> }
> +#if OPENSSL_SUPPORTS_SNI
> +if (server_name && !SSL_set_tlsext_host_name(ssl, server_name)) {
> +VLOG_ERR("%s: failed to set server name indication (%s)",
> + server_name, ERR_error_string(ERR_get_error(), NULL));
> +retval = ENOPROTOOPT;
> +goto error;
> +}
> +#endif
>
> /* Create and return the ssl_stream. */
> sslv = xmalloc(sizeof *sslv);
> @@ -293,6 +311,7 @@ new_ssl_stream(char *name, int fd, enum session_type type,
> }
>
> *streamp = &sslv->stream;
> +free(server_name);
> return 0;
>
> error:
> @@ -301,6 +320,7 @@ error:
> }
> closesocket(fd);
> free(name);
> +free(server_name);
> return retval;
> }
>
> @@ -311,6 +331,30 @@ ssl_stream_cast(struct stream *stream)
> return CONTAINER_OF(stream, struct ssl_stream, stream);
> }
>
> +/* Extracts and returns the server name from 'suffix'. The caller must
> + * eventually free it.
> + *
> + * Returns NULL if there is no server name, and particularly if it is an IP
> + * address rather than a host name, since RFC 3546 is explicit that IP
> + * addresses are unsuitable as server name indication (SNI). */
> +static char *
> +get_server_name(const char *suffix_)
> +{
> +char *suffix = xstrdup(suffix_);
> +
> +char *host, *port;
> +inet_parse_host_port_tokens(suffix, &host, &port);
> +
> +ovs_be32 ipv4;
> +struct in6_addr ipv6;
> +char *server_name = (ip_parse(host, &ipv4) || ipv6_parse(host, &ipv6)
> + ? NULL : xstrdup(host));
> +
> +free(suffix);
> +
> +return server_name;
> +}
> +
> static int
> ssl_open(const char *name, char *suffix, struct stream **streamp, uint8_t
> dscp)
> {
> @@ -325,7 +369,8 @@ ssl_open(const char *name, char *suffix, struct stream
> **streamp, uint8_t dscp)
> dscp);
> if (fd >= 0) {
> int state = error ? STATE_TCP_CONNECTING : STATE_SSL_CONNECTING;
> -return new_ssl_stream(xstrdup(name), fd, CLIENT, state, streamp);
> +return new_ssl_stream(xstrdup(name), get_server_name(suffix),
> + fd, CLIENT, state, streamp);
> } else {
> VLOG_ERR("%s: connect: %s", name, ovs_strerror(error));
> r
Re: [ovs-dev] [PATCH 1/2] test: Fix fragment-related tests that fail due to small-sized packets
I've create a pull request on github as v2 because this patch contains long lines that can't be handled by email protocol. https://github.com/openvswitch/ovs/pull/278 Thanks, Yifeng On Mon, Mar 18, 2019 at 10:42 AM Yifeng Sun wrote: > > Thanks Darrell for the review. Will do. > Yifeng > > On Sat, Mar 16, 2019 at 11:43 AM Darrell Ball wrote: >> >> Hi Yifeng >> >> Thanks for the patch. >> >> Your patch is corrupted; if this is due to transmit via e-mail, you can post >> a pull request. >> Other comments inline >> >> >> On Fri, Mar 15, 2019 at 7:20 PM Yifeng Sun wrote: >>> >>> These fragment-related tests are failing on later kernels (4.19.x) >>> because kernel quietly drops any packet fragment that is not the last >>> but has a size smaller than IPV6_MIN_MTU. This patch fixes >>> them by increasing their sizes to IPV6_MIN_MTU. >>> >>> Signed-off-by: Yifeng Sun >>> --- >>> tests/system-traffic.at | 30 +++--- >>> 1 file changed, 15 insertions(+), 15 deletions(-) >>> >>> diff --git a/tests/system-traffic.at b/tests/system-traffic.at >>> index b1241812e..42bf09815 100644 >>> --- a/tests/system-traffic.at >>> +++ b/tests/system-traffic.at >>> @@ -2611,7 +2611,7 @@ packet-out in_port=1, >>> packet=5054000a505400090800453100310011a48 >>> ]) >>> >>> AT_CHECK([ovs-ofctl bundle br0 bundle.txt]) >>> -# There is one byte of overlap, hence the no packet gets thru. conntrack. >>> +dnl There is one byte of overlap, hence the no packet gets thru. conntrack. >> >> >> s/hence the no packet/hence no packet/ >> >> >>> >>> AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2)], [0], [dnl >>> ]) >>> >>> @@ -2635,7 +2635,7 @@ packet-out in_port=1, >>> packet=5054000a505400090800450001a400012011834 >>> ]) >>> >>> AT_CHECK([ovs-ofctl bundle br0 bundle.txt]) >>> -# There is one byte of overlap, hence the no packet gets thru. conntrack. >>> +dnl There is one byte of overlap, hence the no packet gets thru. conntrack. >> >> >> s/hence the no packet/hence no packet/ >> >>> >>> AT_CHECK([ovs-appctl dpctl/dump-conntrack | FORMAT_CT(10.1.1.2)], [0], [dnl >>> ]) >>> >>> @@ -2827,7 +2827,7 @@ ADD_VETH(p0, at_ns0, br0, "fc00::1/96") >>> ADD_VETH(p1, at_ns1, br0, "fc00::2/96") >> >> >> >> Don't change the packet size in these two tests >> >> AT_SETUP([conntrack - IPv6 fragmentation with fragments specified]) >> AT_SETUP([conntrack - IPv6 fragmentation out of order]) >> >> Add a macro >> 'CHECK_SMALL_V6_FRAG' >> and check for it in these tests. >> >> AT_SETUP([conntrack - IPv6 fragmentation with fragments specified]) >> AT_SETUP([conntrack - IPv6 fragmentation out of order]) >> >> and skip the kernel tests for kernel versions (>=4.19) where the check >> IPV6_MIN_MTU=1280 is enforced. >> >>> >>> >>> AT_DATA([bundle.txt], [dnl >>> -packet-out in_port=1, >>> packet=5054000a5054000986dd61a02cfffc01fc0211010001000100020008f62900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809, >>> actions=ct(co mmit >>> ) >>> +packet-out in_port=1, >>> packet=5054000a5054000986dd65002cfffc01fc0211010001000100020008f629000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090010203040506070 8090 >>> >>> 0010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060708090001020304050607080900010203040506070809000102030405060
Re: [ovs-dev] [PATCH v3 3/5] ovn-controller: Make use of ha_chassis_group table to bind the chassisredirect ports
On Tue, Mar 5, 2019 at 8:06 AM wrote:
> diff --git a/ovn/controller/bfd.h b/ovn/controller/bfd.h
> index e36820afb..789f7b269 100644
> --- a/ovn/controller/bfd.h
> +++ b/ovn/controller/bfd.h
> @@ -24,16 +24,17 @@ struct ovsrec_interface_table;
> struct ovsrec_open_vswitch_table;
> struct sbrec_chassis;
> struct sbrec_sb_global_table;
> +struct sbrec_ha_chassis_group_table;
> struct sset;
>
> void bfd_register_ovs_idl(struct ovsdb_idl *);
> -void bfd_run(struct ovsdb_idl_index *sbrec_chassis_by_name,
> - struct ovsdb_idl_index *sbrec_port_binding_by_datapath,
> - const struct ovsrec_interface_table *interface_table,
> +
> +void bfd_run(const struct ovsrec_interface_table *interface_table,
> const struct ovsrec_bridge *br_int,
> const struct sbrec_chassis *chassis_rec,
> - const struct sbrec_sb_global_table *sb_global_table,
> - const struct hmap *local_datapaths);
> + const struct sbrec_ha_chassis_group_table *ha_chassis_grp_table,
> + const struct sbrec_sb_global_table *sb_global_table);
> +
Most parameter names can be omitted in this prototype.
> +
> +struct ha_chassis_ordered *ordered_ha_ch;
> +if (n_ha_ch == 1) {
> +if (active_tunnels) {
> +/* If n_ha_ch is 1, it means only the local chassis is in the
> +* ha_ch_order list. Check if this local chassis has active
> +* bfd session with any of the referenced chassis. If so,
> +* then the local chassis can be active. Otherwise it can't.
> +* This can happen in the following scenario.
> +* Lets say we have chassis HA1 (prioirty 20) and HA2 (priority
> 10)
> +* in the ha_chasis_group and compute chassis C1 and C2 are in the
> +* reference chassis list. If HA1 chassis has lost the link and
> +* when this function is called for HA2 we need to consider
> +* HA2 as active since it has active BFD sessions with C1 and C2.
> +* On HA1 chassis, this function won't be called since
> +* active_tunnels set will be empty.
> +* */
> +bool can_local_chassis_be_active = false;
> +for (size_t i = 0; i < ha_ch_grp->n_ref_chassis; i++) {
> +if (sset_contains(active_tunnels,
> +ha_ch_grp->ref_chassis[i]->name)) {
> +can_local_chassis_be_active = true;
> +break;
> +}
> +}
> +if (!can_local_chassis_be_active) {
> +free(ha_ch_order);
> +return NULL;
> +}
> +}
What if, a HA-chassis-group has only one chassis, the n_ha_ch will be
1, and active_tunnels is not NULL but will be empty because bfd won't
be setup for HA group with only 1 chassis. However, it will enter this
branch and returns NULL, which will lead to
ha_chassis_group_is_active() return false, and the GW will not
function for the logical router port. Did I miss anything here?
> @@ -753,34 +753,36 @@ consider_port_binding(struct ovsdb_idl_index
> *sbrec_chassis_by_name,
> /* Output to tunnel. */
> ofpact_put_OUTPUT(ofpacts_p)->port = rem_tun->ofport;
> } else {
> -struct gateway_chassis *gwc;
> /* Make sure all tunnel endpoints use the same encapsulation,
> * and set it up */
> -LIST_FOR_EACH (gwc, node, gateway_chassis) {
> -if (gwc->db->chassis) {
> -if (!tun) {
> -tun = chassis_tunnel_find(gwc->db->chassis->name,
> NULL);
> -} else {
> -struct chassis_tunnel *chassis_tunnel =
> -chassis_tunnel_find(gwc->db->chassis->name,
> NULL);
> -if (chassis_tunnel &&
> -tun->type != chassis_tunnel->type) {
> -static struct vlog_rate_limit rl =
> -VLOG_RATE_LIMIT_INIT(1, 1);
> -VLOG_ERR_RL(&rl, "Port %s has Gateway_Chassis "
> - "with mixed encapsulations,
> only "
> - "uniform encapsulations are "
> - "supported.",
> -binding->logical_port);
> -goto out;
> -}
> +for (size_t i = 0; i < ha_ch_ordered->n_ha_ch; i++) {
> +const struct sbrec_chassis *ch =
> +ha_ch_ordered->ha_ch[i].chassis;
> +if (!ch) {
If ha_ch[i].chassis is NULL, it means a chassis is deleted before
deleting the HA_Chassis referencing it. This seems to be a situation
we never want. So I wonder maybe it is better to use strong reference
for HA_Chass
[ovs-dev] [PATCH net-next v4] openvswitch: Make metadata_dst tunnel work in IP_TUNNEL_INFO_BRIDGE mode
From: wenxu
There is currently no support for the multicast/broadcast aspects
of VXLAN in ovs. In the datapath flow the tun_dst must specific.
But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
And the packet can forward through the fdb table of vxlan devcice. In
this mode the broadcast/multicast packet can be sent through the
following ways in ovs.
ovs-vsctl add-port br0 vxlan -- set in vxlan type=vxlan \
options:key=1000 options:remote_ip=flow
ovs-ofctl add-flow br0 in_port=LOCAL,dl_dst=ff:ff:ff:ff:ff:ff, \
action=output:vxlan
bridge fdb append ff:ff:ff:ff:ff:ff dev vxlan_sys_4789 dst 172.168.0.1 \
src_vni 1000 vni 1000 self
bridge fdb append ff:ff:ff:ff:ff:ff dev vxlan_sys_4789 dst 172.168.0.2 \
src_vni 1000 vni 1000 self
Signed-off-by: wenxu
---
include/uapi/linux/openvswitch.h | 1 +
net/openvswitch/flow_netlink.c | 36
2 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index dbe0cbe..b8913b9 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -364,6 +364,7 @@ enum ovs_tunnel_key_attr {
OVS_TUNNEL_KEY_ATTR_IPV6_DST, /* struct in6_addr dst IPv6
address. */
OVS_TUNNEL_KEY_ATTR_PAD,
OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS,/* struct erspan_metadata */
+ OVS_TUNNEL_KEY_ATTR_IPV4_INFO_BRIDGE, /* No argument.
IPV4_INFO_BRIDGE mode.*/
__OVS_TUNNEL_KEY_ATTR_MAX
};
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 691da85..edd7b41 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -403,6 +403,7 @@ size_t ovs_key_attr_size(void)
[OVS_TUNNEL_KEY_ATTR_IPV6_SRC] = { .len = sizeof(struct in6_addr)
},
[OVS_TUNNEL_KEY_ATTR_IPV6_DST] = { .len = sizeof(struct in6_addr)
},
[OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS] = { .len = OVS_ATTR_VARIABLE },
+ [OVS_TUNNEL_KEY_ATTR_IPV4_INFO_BRIDGE] = { .len = 0 },
};
static const struct ovs_len_tbl
@@ -666,6 +667,7 @@ static int ip_tun_from_nlattr(const struct nlattr *attr,
bool log)
{
bool ttl = false, ipv4 = false, ipv6 = false;
+ bool info_bridge_mode = false;
__be16 tun_flags = 0;
int opts_type = 0;
struct nlattr *a;
@@ -782,6 +784,10 @@ static int ip_tun_from_nlattr(const struct nlattr *attr,
tun_flags |= TUNNEL_ERSPAN_OPT;
opts_type = type;
break;
+ case OVS_TUNNEL_KEY_ATTR_IPV4_INFO_BRIDGE:
+ info_bridge_mode = true;
+ ipv4 = true;
+ break;
default:
OVS_NLERR(log, "Unknown IP tunnel attribute %d",
type);
@@ -812,16 +818,29 @@ static int ip_tun_from_nlattr(const struct nlattr *attr,
OVS_NLERR(log, "IP tunnel dst address not specified");
return -EINVAL;
}
- if (ipv4 && !match->key->tun_key.u.ipv4.dst) {
- OVS_NLERR(log, "IPv4 tunnel dst address is zero");
- return -EINVAL;
+ if (ipv4) {
+ if (info_bridge_mode) {
+ if (match->key->tun_key.u.ipv4.src ||
+ match->key->tun_key.u.ipv4.dst ||
+ match->key->tun_key.tp_src ||
+ match->key->tun_key.tp_dst ||
+ match->key->tun_key.ttl ||
+ match->key->tun_key.tos ||
+ tun_flags & ~TUNNEL_KEY) {
+ OVS_NLERR(log, "IPv4 tun info is not
correct");
+ return -EINVAL;
+ }
+ } else if (!match->key->tun_key.u.ipv4.dst) {
+ OVS_NLERR(log, "IPv4 tunnel dst address is
zero");
+ return -EINVAL;
+ }
}
if (ipv6 && ipv6_addr_any(&match->key->tun_key.u.ipv6.dst)) {
OVS_NLERR(log, "IPv6 tunnel dst address is zero");
return -EINVAL;
}
- if (!ttl) {
+ if (!ttl && !info_bridge_mode) {
OVS_NLERR(log, "IP tunnel TTL not specified.");
return -EINVAL;
}
@@ -912,6 +931,13 @@ static int __ip_tun_to_nlattr(struct sk_buff *skb,
return -EMSGSIZE;
}
+ if (tun_proto == AF_INET && !(output->tun_flags & ~TUNNEL_KEY) &&
+ !output->u.ipv4.src && !output->u.ipv4.dst &&
+ !outp
Re: [ovs-dev] [PATCH v3 3/5] ovn-controller: Make use of ha_chassis_group table to bind the chassisredirect ports
On Tue, Mar 26, 2019 at 6:34 PM Han Zhou wrote:
>
> On Tue, Mar 5, 2019 at 8:06 AM wrote:
>
> > diff --git a/ovn/controller/bfd.h b/ovn/controller/bfd.h
> > index e36820afb..789f7b269 100644
> > --- a/ovn/controller/bfd.h
> > +++ b/ovn/controller/bfd.h
> > @@ -24,16 +24,17 @@ struct ovsrec_interface_table;
> > struct ovsrec_open_vswitch_table;
> > struct sbrec_chassis;
> > struct sbrec_sb_global_table;
> > +struct sbrec_ha_chassis_group_table;
> > struct sset;
> >
> > void bfd_register_ovs_idl(struct ovsdb_idl *);
> > -void bfd_run(struct ovsdb_idl_index *sbrec_chassis_by_name,
> > - struct ovsdb_idl_index *sbrec_port_binding_by_datapath,
> > - const struct ovsrec_interface_table *interface_table,
> > +
> > +void bfd_run(const struct ovsrec_interface_table *interface_table,
> > const struct ovsrec_bridge *br_int,
> > const struct sbrec_chassis *chassis_rec,
> > - const struct sbrec_sb_global_table *sb_global_table,
> > - const struct hmap *local_datapaths);
> > + const struct sbrec_ha_chassis_group_table
> > *ha_chassis_grp_table,
> > + const struct sbrec_sb_global_table *sb_global_table);
> > +
>
> Most parameter names can be omitted in this prototype.
>
>
> > +
> > +struct ha_chassis_ordered *ordered_ha_ch;
> > +if (n_ha_ch == 1) {
> > +if (active_tunnels) {
> > +/* If n_ha_ch is 1, it means only the local chassis is in the
> > +* ha_ch_order list. Check if this local chassis has active
> > +* bfd session with any of the referenced chassis. If so,
> > +* then the local chassis can be active. Otherwise it can't.
> > +* This can happen in the following scenario.
> > +* Lets say we have chassis HA1 (prioirty 20) and HA2 (priority
> > 10)
> > +* in the ha_chasis_group and compute chassis C1 and C2 are in
> > the
> > +* reference chassis list. If HA1 chassis has lost the link and
> > +* when this function is called for HA2 we need to consider
> > +* HA2 as active since it has active BFD sessions with C1 and
> > C2.
> > +* On HA1 chassis, this function won't be called since
> > +* active_tunnels set will be empty.
> > +* */
> > +bool can_local_chassis_be_active = false;
> > +for (size_t i = 0; i < ha_ch_grp->n_ref_chassis; i++) {
> > +if (sset_contains(active_tunnels,
> > +ha_ch_grp->ref_chassis[i]->name)) {
> > +can_local_chassis_be_active = true;
> > +break;
> > +}
> > +}
> > +if (!can_local_chassis_be_active) {
> > +free(ha_ch_order);
> > +return NULL;
> > +}
> > +}
>
> What if, a HA-chassis-group has only one chassis, the n_ha_ch will be
> 1, and active_tunnels is not NULL but will be empty because bfd won't
> be setup for HA group with only 1 chassis. However, it will enter this
> branch and returns NULL, which will lead to
> ha_chassis_group_is_active() return false, and the GW will not
> function for the logical router port. Did I miss anything here?
>
>
>
> > @@ -753,34 +753,36 @@ consider_port_binding(struct ovsdb_idl_index
> > *sbrec_chassis_by_name,
> > /* Output to tunnel. */
> > ofpact_put_OUTPUT(ofpacts_p)->port = rem_tun->ofport;
> > } else {
> > -struct gateway_chassis *gwc;
> > /* Make sure all tunnel endpoints use the same encapsulation,
> > * and set it up */
> > -LIST_FOR_EACH (gwc, node, gateway_chassis) {
> > -if (gwc->db->chassis) {
> > -if (!tun) {
> > -tun = chassis_tunnel_find(gwc->db->chassis->name,
> > NULL);
> > -} else {
> > -struct chassis_tunnel *chassis_tunnel =
> > -chassis_tunnel_find(gwc->db->chassis->name,
> > NULL);
> > -if (chassis_tunnel &&
> > -tun->type != chassis_tunnel->type) {
> > -static struct vlog_rate_limit rl =
> > -VLOG_RATE_LIMIT_INIT(1, 1);
> > -VLOG_ERR_RL(&rl, "Port %s has Gateway_Chassis "
> > - "with mixed encapsulations,
> > only "
> > - "uniform encapsulations are "
> > - "supported.",
> > -binding->logical_port);
> > -goto out;
> > -}
> > +for (size_t i = 0; i < ha_ch_ordered->n_ha_ch; i++) {
> > +const struct sbrec_chassis *ch =
> > +ha_ch_ordered->ha
Re: [ovs-dev] [PATCH v3 3/5] ovn-controller: Make use of ha_chassis_group table to bind the chassisredirect ports
On Tue, Mar 26, 2019 at 10:01 PM Han Zhou wrote:
>
> On Tue, Mar 26, 2019 at 6:34 PM Han Zhou wrote:
> >
> > On Tue, Mar 5, 2019 at 8:06 AM wrote:
> >
> > > diff --git a/ovn/controller/bfd.h b/ovn/controller/bfd.h
> > > index e36820afb..789f7b269 100644
> > > --- a/ovn/controller/bfd.h
> > > +++ b/ovn/controller/bfd.h
> > > @@ -24,16 +24,17 @@ struct ovsrec_interface_table;
> > > struct ovsrec_open_vswitch_table;
> > > struct sbrec_chassis;
> > > struct sbrec_sb_global_table;
> > > +struct sbrec_ha_chassis_group_table;
> > > struct sset;
> > >
> > > void bfd_register_ovs_idl(struct ovsdb_idl *);
> > > -void bfd_run(struct ovsdb_idl_index *sbrec_chassis_by_name,
> > > - struct ovsdb_idl_index *sbrec_port_binding_by_datapath,
> > > - const struct ovsrec_interface_table *interface_table,
> > > +
> > > +void bfd_run(const struct ovsrec_interface_table *interface_table,
> > > const struct ovsrec_bridge *br_int,
> > > const struct sbrec_chassis *chassis_rec,
> > > - const struct sbrec_sb_global_table *sb_global_table,
> > > - const struct hmap *local_datapaths);
> > > + const struct sbrec_ha_chassis_group_table
> > > *ha_chassis_grp_table,
> > > + const struct sbrec_sb_global_table *sb_global_table);
> > > +
> >
> > Most parameter names can be omitted in this prototype.
> >
> >
> > > +
> > > +struct ha_chassis_ordered *ordered_ha_ch;
> > > +if (n_ha_ch == 1) {
> > > +if (active_tunnels) {
> > > +/* If n_ha_ch is 1, it means only the local chassis is in the
> > > +* ha_ch_order list. Check if this local chassis has active
> > > +* bfd session with any of the referenced chassis. If so,
> > > +* then the local chassis can be active. Otherwise it can't.
> > > +* This can happen in the following scenario.
> > > +* Lets say we have chassis HA1 (prioirty 20) and HA2
> > > (priority 10)
> > > +* in the ha_chasis_group and compute chassis C1 and C2 are
> > > in the
> > > +* reference chassis list. If HA1 chassis has lost the link
> > > and
> > > +* when this function is called for HA2 we need to consider
> > > +* HA2 as active since it has active BFD sessions with C1 and
> > > C2.
> > > +* On HA1 chassis, this function won't be called since
> > > +* active_tunnels set will be empty.
> > > +* */
> > > +bool can_local_chassis_be_active = false;
> > > +for (size_t i = 0; i < ha_ch_grp->n_ref_chassis; i++) {
> > > +if (sset_contains(active_tunnels,
> > > +ha_ch_grp->ref_chassis[i]->name)) {
> > > +can_local_chassis_be_active = true;
> > > +break;
> > > +}
> > > +}
> > > +if (!can_local_chassis_be_active) {
> > > +free(ha_ch_order);
> > > +return NULL;
> > > +}
> > > +}
> >
> > What if, a HA-chassis-group has only one chassis, the n_ha_ch will be
> > 1, and active_tunnels is not NULL but will be empty because bfd won't
> > be setup for HA group with only 1 chassis. However, it will enter this
> > branch and returns NULL, which will lead to
> > ha_chassis_group_is_active() return false, and the GW will not
> > function for the logical router port. Did I miss anything here?
> >
> >
> >
> > > @@ -753,34 +753,36 @@ consider_port_binding(struct ovsdb_idl_index
> > > *sbrec_chassis_by_name,
> > > /* Output to tunnel. */
> > > ofpact_put_OUTPUT(ofpacts_p)->port = rem_tun->ofport;
> > > } else {
> > > -struct gateway_chassis *gwc;
> > > /* Make sure all tunnel endpoints use the same encapsulation,
> > > * and set it up */
> > > -LIST_FOR_EACH (gwc, node, gateway_chassis) {
> > > -if (gwc->db->chassis) {
> > > -if (!tun) {
> > > -tun =
> > > chassis_tunnel_find(gwc->db->chassis->name, NULL);
> > > -} else {
> > > -struct chassis_tunnel *chassis_tunnel =
> > > -chassis_tunnel_find(gwc->db->chassis->name,
> > > NULL);
> > > -if (chassis_tunnel &&
> > > -tun->type != chassis_tunnel->type) {
> > > -static struct vlog_rate_limit rl =
> > > -VLOG_RATE_LIMIT_INIT(1, 1);
> > > -VLOG_ERR_RL(&rl, "Port %s has
> > > Gateway_Chassis "
> > > - "with mixed encapsulations,
> > > only "
> > > - "uniform encapsulations are
> > > "
> > > - "supported.",
> > > -
Re: [ovs-dev] [PATCH v4 3/5] ovn-controller: Make use of ha_chassis_group table to bind the chassisredirect ports
On Thu, Mar 14, 2019 at 12:33 PM wrote:
>
> diff --git a/ovn/controller/bfd.h b/ovn/controller/bfd.h
> index e36820afb..789f7b269 100644
> --- a/ovn/controller/bfd.h
> +++ b/ovn/controller/bfd.h
> @@ -24,16 +24,17 @@ struct ovsrec_interface_table;
> struct ovsrec_open_vswitch_table;
> struct sbrec_chassis;
> struct sbrec_sb_global_table;
> +struct sbrec_ha_chassis_group_table;
> struct sset;
>
> void bfd_register_ovs_idl(struct ovsdb_idl *);
> -void bfd_run(struct ovsdb_idl_index *sbrec_chassis_by_name,
> - struct ovsdb_idl_index *sbrec_port_binding_by_datapath,
> - const struct ovsrec_interface_table *interface_table,
> +
> +void bfd_run(const struct ovsrec_interface_table *interface_table,
> const struct ovsrec_bridge *br_int,
> const struct sbrec_chassis *chassis_rec,
> - const struct sbrec_sb_global_table *sb_global_table,
> - const struct hmap *local_datapaths);
> + const struct sbrec_ha_chassis_group_table *ha_chassis_grp_table,
> + const struct sbrec_sb_global_table *sb_global_table);
> +
Most parameter names can be omitted in this prototype.
> +
> +struct ha_chassis_ordered *ordered_ha_ch;
> +if (n_ha_ch == 1) {
> +if (active_tunnels) {
> +/* If n_ha_ch is 1, it means only the local chassis is in the
> +* ha_ch_order list. Check if this local chassis has active
> +* bfd session with any of the referenced chassis. If so,
> +* then the local chassis can be active. Otherwise it can't.
> +* This can happen in the following scenario.
> +* Lets say we have chassis HA1 (prioirty 20) and HA2 (priority
> 10)
> +* in the ha_chasis_group and compute chassis C1 and C2 are in the
> +* reference chassis list. If HA1 chassis has lost the link and
> +* when this function is called for HA2 we need to consider
> +* HA2 as active since it has active BFD sessions with C1 and C2.
> +* On HA1 chassis, this function won't be called since
> +* active_tunnels set will be empty.
> +* */
> +bool can_local_chassis_be_active = false;
> +for (size_t i = 0; i < ha_ch_grp->n_ref_chassis; i++) {
> +if (sset_contains(active_tunnels,
> +ha_ch_grp->ref_chassis[i]->name)) {
> +can_local_chassis_be_active = true;
> +break;
> +}
> +}
> +if (!can_local_chassis_be_active) {
> +free(ha_ch_order);
> +return NULL;
> +}
> +}
What if, a HA-chassis-group has only one chassis, the n_ha_ch will be
1, and active_tunnels is not NULL but will be empty because bfd won't
be setup for HA group with only 1 chassis. However, it will enter this
branch and returns NULL, which will lead to
ha_chassis_group_is_active() return false, and the GW will not
function for the logical router port. Did I miss anything here?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 4/5] ovn-northd: Delete the references to gateway_chasss in SB DB
On Thu, Mar 14, 2019 at 12:33 PM wrote: > > From: Numan Siddique > > Previous patch in the series added the support in ovn-controller > to use ha_chassis_group table in SB DB to support HA chassis > and establishing BFD tunnels instead of the gateway_chassis table. > There is no need for ovn-northd to create any gateway_chassis > rows in SB DB. This patch does that and deletes the code > which is not required anymore. > > This patch also now supports 'ha_chassis_group' to be associated > with a distributed logical router port and ignores 'gateway_chassis' > and 'redirect-chassis' if set along with 'ha_chassis_group'. > > Signed-off-by: Numan Siddique > --- > NEWS| 1 + > ovn/northd/ovn-northd.c | 321 +++- > tests/ovn-northd.at | 231 + > tests/ovn.at| 175 ++ > 4 files changed, 529 insertions(+), 199 deletions(-) > > diff --git a/NEWS b/NEWS > index 89d0f19d6..74adb2562 100644 > --- a/NEWS > +++ b/NEWS > @@ -24,6 +24,7 @@ Post-v2.11.0 > protocol extension. > - OVN: > * Select IPAM mac_prefix in a random manner if not provided by the user > + * Added the HA chassis group support and deprecated Gateway chassis. > I think we agreed that we will not deprecate Gateway chassis since it is more convenient in many cases. I guess it was carried over from v3. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 4/5] ovn-northd: Delete the references to gateway_chasss in SB DB
On Thu, Mar 14, 2019 at 12:33 PM wrote:
>
> diff --git a/NEWS b/NEWS
> index 89d0f19d6..74adb2562 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -24,6 +24,7 @@ Post-v2.11.0
> protocol extension.
> - OVN:
> * Select IPAM mac_prefix in a random manner if not provided by the user
> + * Added the HA chassis group support and deprecated Gateway chassis.
I think we agreed that we will not deprecate Gateway chassis since it
is more convenient in many cases. I guess it was carried over from v3.
> @@ -2195,18 +2191,27 @@ ovn_port_update_sbrec(struct northd_context *ctx,
> if (op->derived) {
> const char *redirect_chassis = smap_get(&op->nbrp->options,
> "redirect-chassis");
> -if (op->nbrp->n_gateway_chassis && redirect_chassis) {
> +if (op->nbrp->ha_chassis_group && op->nbrp->n_gateway_chassis) {
> static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1,
> 1);
> VLOG_WARN_RL(
> -&rl, "logical router port %s has both options:"
> - "redirect-chassis and gateway_chassis populated "
> - "redirect-chassis will be ignored in favour of "
> - "gateway chassis", op->nbrp->name);
> +&rl, "logical router port %s has both:"
> + "ha_chassis_group and gateway_chassis populated "
> + "gateway_chassis will be ignored in favour of "
> + "ha_chassis_group", op->nbrp->name);
Now we have 3 ways to support port residing on gateway(s). This new
warning only mentioned about ha_chassis_group v.s. gateway_chassis.
Since redirect_chassis is still supported, it should still be warned
if it is configured together with other methods.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v4 5/5] ovn: Support a new Logical_Switch_Port.type - 'external'
On Thu, Mar 14, 2019 at 12:34 PM wrote: > > > + > + References a row in the OVN Northbound database's > + table. > + It indicates the HA chassis group to use if the > + is set to external. > + If is not to external, this s/is not to/is not Acked-by: Han Zhou ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
