[ovs-dev] [PATCH] ofproto: fix stack-buffer-overflow
Should use flow->actions not >actions. here is ASAN report: = ==57189==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x428fa0e8 at pc 0x7f61a520 bp 0x428f9420 sp 0x428f9498 READ of size 196 at 0x428fa0e8 thread T150 (revalidator22) #0 0x7f61a51f in __interceptor_memcpy (/lib64/libasan.so.4+0xa251f) #1 0xd26a3b2b in ofpbuf_put lib/ofpbuf.c:426 #2 0xd26a30cb in ofpbuf_clone_data_with_headroom lib/ofpbuf.c:248 #3 0xd26a2e77 in ofpbuf_clone_with_headroom lib/ofpbuf.c:218 #4 0xd26a2dc3 in ofpbuf_clone lib/ofpbuf.c:208 #5 0xd23e3993 in ukey_set_actions ofproto/ofproto-dpif-upcall.c:1640 #6 0xd23e3f03 in ukey_create__ ofproto/ofproto-dpif-upcall.c:1696 #7 0xd23e553f in ukey_create_from_dpif_flow ofproto/ofproto-dpif-upcall.c:1806 #8 0xd23e65fb in ukey_acquire ofproto/ofproto-dpif-upcall.c:1984 #9 0xd23eb583 in revalidate ofproto/ofproto-dpif-upcall.c:2625 #10 0xd23dee5f in udpif_revalidator ofproto/ofproto-dpif-upcall.c:1076 #11 0xd26b84ef in ovsthread_wrapper lib/ovs-thread.c:708 #12 0x7e74a8bb in start_thread (/lib64/libpthread.so.0+0x78bb) #13 0x7e0665cb in thread_start (/lib64/libc.so.6+0xd55cb) Address 0x428fa0e8 is located in stack of thread T150 (revalidator22) at offset 328 in frame #0 0xd23e4cab in ukey_create_from_dpif_flow ofproto/ofproto-dpif-upcall.c:1762 This frame has 4 object(s): [32, 96) 'actions' [128, 192) 'buf' [224, 328) 'full_flow' [384, 2432) 'stub' <== Memory access at offset 328 partially underflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) Thread T150 (revalidator22) created by T0 here: #0 0x7f5b0f7f in __interceptor_pthread_create (/lib64/libasan.so.4+0x38f7f) #1 0xd26b891f in ovs_thread_create lib/ovs-thread.c:792 #2 0xd23dc62f in udpif_start_threads ofproto/ofproto-dpif-upcall.c:639 #3 0xd23daf87 in ofproto_set_flow_table ofproto/ofproto-dpif-upcall.c:446 #4 0xd230ff7f in dpdk_evs_cfg_set vswitchd/bridge.c:1134 #5 0xd2310097 in bridge_reconfigure vswitchd/bridge.c:1148 #6 0xd23279d7 in bridge_run vswitchd/bridge.c:3944 #7 0xd23365a3 in main vswitchd/ovs-vswitchd.c:240 #8 0x7dfb1adf in __libc_start_main (/lib64/libc.so.6+0x20adf) #9 0xd230a3d3 (/usr/sbin/ovs-vswitchd-2.7.0-1.1.RC5.001.asan+0x26f3d3) SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.so.4+0xa251f) in __interceptor_memcpy Shadow bytes around the buggy address: 0x200fe851f3c0: 00 00 00 00 f1 f1 f1 f1 f8 f2 f2 f2 00 00 00 00 0x200fe851f3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f3f0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 0x200fe851f400: f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2 =>0x200fe851f410: 00 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 0x200fe851f420: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==57189==ABORTING Signed-off-by: Linhaifeng --- ofproto/ofproto-dpif-upcall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c index dc30824771..c2fc527a31 100644 --- a/ofproto/ofproto-dpif-upcall.c +++ b/ofproto/ofproto-dpif-upcall.c @@ -1796,7 +1796,7 @@ ukey_create_from_dpif_flow(const struct udpif *udpif, } reval_seq = seq_read(udpif->reval_seq) - 1; /* Ensure revalidation. */ -ofpbuf_use_const(, >actions, flow->actions_len); +ofpbuf_use_const(, flow->actions, flow->actions_len); *ukey = ukey_create__(flow->key, flow->key_len, flow->mask, flow->mask_len, flow->ufid_present, >ufid, flow->pmd_id, , -- 2.19.1 ___ dev mailing list d...@openvswitch.org
Re: [ovs-dev] [PATCH] ofproto: fix stack-buffer-overflow
Bleep bloop. Greetings Linhaifeng, I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. checkpatch: ERROR: Author Linhaifeng needs to sign off. Lines checked: 104, Warnings: 0, Errors: 1 Please check this out. If you feel there has been an error, please email acon...@redhat.com Thanks, 0-day Robot ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] (no subject)
Herzlichen Glückwunsch, Ihre E-Mail hat 3.000.000 gewonnen Kontakt: maviswancy...@gmail.com für Informationen / Ansprüche -- "Independencia y Patria Socialista, Viviremos y Venceremos" ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ofproto: fix stack-buffer-overflow
Should use flow->actions not >actions. Here is some print info for debug: @@@ flow->actions=0xb5e48844 len=196 @@@ stub=[0x7eefa120,0x7eefa918] actions->data=0x7eefa0a0 actions->size=196 actions->data != flow->actions and actions->data + 196 is in the range of stub . here is ASAN report: = ==57189==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x428fa0e8 at pc 0x7f61a520 bp 0x428f9420 sp 0x428f9498 READ of size 196 at 0x428fa0e8 thread T150 (revalidator22) #0 0x7f61a51f in __interceptor_memcpy (/lib64/libasan.so.4+0xa251f) #1 0xd26a3b2b in ofpbuf_put lib/ofpbuf.c:426 #2 0xd26a30cb in ofpbuf_clone_data_with_headroom lib/ofpbuf.c:248 #3 0xd26a2e77 in ofpbuf_clone_with_headroom lib/ofpbuf.c:218 #4 0xd26a2dc3 in ofpbuf_clone lib/ofpbuf.c:208 #5 0xd23e3993 in ukey_set_actions ofproto/ofproto-dpif-upcall.c:1640 #6 0xd23e3f03 in ukey_create__ ofproto/ofproto-dpif-upcall.c:1696 #7 0xd23e553f in ukey_create_from_dpif_flow ofproto/ofproto-dpif-upcall.c:1806 #8 0xd23e65fb in ukey_acquire ofproto/ofproto-dpif-upcall.c:1984 #9 0xd23eb583 in revalidate ofproto/ofproto-dpif-upcall.c:2625 #10 0xd23dee5f in udpif_revalidator ofproto/ofproto-dpif-upcall.c:1076 #11 0xd26b84ef in ovsthread_wrapper lib/ovs-thread.c:708 #12 0x7e74a8bb in start_thread (/lib64/libpthread.so.0+0x78bb) #13 0x7e0665cb in thread_start (/lib64/libc.so.6+0xd55cb) Address 0x428fa0e8 is located in stack of thread T150 (revalidator22) at offset 328 in frame #0 0xd23e4cab in ukey_create_from_dpif_flow ofproto/ofproto-dpif-upcall.c:1762 This frame has 4 object(s): [32, 96) 'actions' [128, 192) 'buf' [224, 328) 'full_flow' [384, 2432) 'stub' <== Memory access at offset 328 partially underflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) Thread T150 (revalidator22) created by T0 here: #0 0x7f5b0f7f in __interceptor_pthread_create (/lib64/libasan.so.4+0x38f7f) #1 0xd26b891f in ovs_thread_create lib/ovs-thread.c:792 #2 0xd23dc62f in udpif_start_threads ofproto/ofproto-dpif-upcall.c:639 #3 0xd23daf87 in ofproto_set_flow_table ofproto/ofproto-dpif-upcall.c:446 #4 0xd230ff7f in dpdk_evs_cfg_set vswitchd/bridge.c:1134 #5 0xd2310097 in bridge_reconfigure vswitchd/bridge.c:1148 #6 0xd23279d7 in bridge_run vswitchd/bridge.c:3944 #7 0xd23365a3 in main vswitchd/ovs-vswitchd.c:240 #8 0x7dfb1adf in __libc_start_main (/lib64/libc.so.6+0x20adf) #9 0xd230a3d3 (/usr/sbin/ovs-vswitchd-2.7.0-1.1.RC5.001.asan+0x26f3d3) SUMMARY: AddressSanitizer: stack-buffer-overflow (/lib64/libasan.so.4+0xa251f) in __interceptor_memcpy Shadow bytes around the buggy address: 0x200fe851f3c0: 00 00 00 00 f1 f1 f1 f1 f8 f2 f2 f2 00 00 00 00 0x200fe851f3d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f3e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f3f0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 0x200fe851f400: f2 f2 f2 f2 f8 f8 f8 f8 f8 f8 f8 f8 f2 f2 f2 f2 =>0x200fe851f410: 00 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 0x200fe851f420: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x200fe851f460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb ==57189==ABORTING --- ofproto/ofproto-dpif-upcall.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ofproto/ofproto-dpif-upcall.c b/ofproto/ofproto-dpif-upcall.c index dc30824771..c2fc527a31 100644 --- a/ofproto/ofproto-dpif-upcall.c +++ b/ofproto/ofproto-dpif-upcall.c @@ -1796,7 +1796,7 @@ ukey_create_from_dpif_flow(const struct udpif *udpif, } reval_seq = seq_read(udpif->reval_seq) - 1; /* Ensure revalidation. */ -ofpbuf_use_const(, >actions, flow->actions_len); +ofpbuf_use_const(, flow->actions, flow->actions_len); *ukey = ukey_create__(flow->key, flow->key_len,
Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI for arm
> -Original Message- > From: Ilya Maximets > Sent: Friday, November 29, 2019 3:06 AM > To: Lance Yang (Arm Technology China) ; Ilya Maximets > ; ovs-dev@openvswitch.org > Cc: Jieqiang Wang (Arm Technology China) ; Gavin Hu > (Arm > Technology China) ; Jingzhao Ni (Arm Technology China) > ; dwil...@us.ibm.com; nd ; Ruifeng Wang > (Arm > Technology China) ; Yanqin Wei (Arm Technology China) > > Subject: Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI for arm > > On 27.11.2019 8:11, Lance Yang (Arm Technology China) wrote: > > > >> -Original Message- > >> From: Ilya Maximets > >> Sent: Friday, November 22, 2019 6:36 PM > >> To: Lance Yang (Arm Technology China) ; Ilya > >> Maximets ; ovs-dev@openvswitch.org > >> Cc: Jieqiang Wang (Arm Technology China) ; > >> Gavin Hu (Arm Technology China) ; Jingzhao Ni (Arm > >> Technology China) ; dwil...@us.ibm.com; nd > >> ; Ruifeng Wang (Arm Technology China) > >> ; Yanqin Wei (Arm Technology China) > >> > >> Subject: Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI > >> for arm > >> > >> On 22.11.2019 10:35, Lance Yang (Arm Technology China) wrote: > >>> Hi Ilya, > >>> > >>> Thanks for your reply. Please see the inline reply. > >>> > >>> Best regards, > >>> Lance Yang > >>> > -Original Message- > From: Ilya Maximets > Sent: Friday, November 22, 2019 3:47 AM > To: Lance Yang (Arm Technology China) ; ovs- > d...@openvswitch.org > Cc: Jieqiang Wang (Arm Technology China) ; > Gavin Hu (Arm Technology China) ; Jingzhao Ni > (Arm Technology China) ; dwil...@us.ibm.com; > nd ; Ruifeng Wang (Arm Technology China) > > Subject: Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI > for arm > > On 20.11.2019 9:15, Lance Yang wrote: > > Enable part of travis jobs with gcc compiler for arm64 > > architecture > > > > 1. Add arm jobs into the matrix in .travis.yml and define dpdk > > cache directory for arm64 architecture. > > 2. Temporarily disable sparse checker because of static code > > checking failure on arm64 > > Could you provide the sparse error messages? > Maybe we could fix them instead of disabling. > > > > > Successful travis build jobs report: > > https://travis-ci.org/yzyuestc/ovs/builds/614299933 > > There are some issues in Travis in above build. It seems that > Travis fails to upload the resulted cache directory due to missing > md5deep: > > "" > >>> [Lance] > >>> The issue occurred because sparse checker does not recognize some arm neon > intrinsics: > >>> > >>> 1. Some components in Open vSwitch source code directly includes the > >>> header file > >> . > >>> > >>> 2. When compiling OvS with DPDK, OvS includes some DPDK headers, > >>> which sometimes includes . You can see the details of > >>> the error in the report at: > >>> https://travis-ci.org/yzyuestc/ovs/jobs/615414391 > >>> after line 2693 > >>> > >>> For the first issue where OvS directly imported the arm_neon.h, I > >>> can fix it in my patch set > >> v2. However, for the second issue that DPDK project has imported the > >> arm neon intrinsics, it seems that I am unable to fix this issue until > >> DPDK solved it. > >> > >> Hi. > >> > >> Thanks for the information. > >> Could, you, please, check if the following patch fixes the issue: > >> https://patchwork.ozlabs.org/patch/1199398/ > >> ? > >> > >>> > store build cache > 0.02s5.41sInstalling md5deep > Reading package lists... > Building dependency tree... > Reading state information... > md5deep is already the newest version (4.4-2). > 0 upgraded, 0 newly installed, 0 to remove and 8 not upgraded. > /home/travis/.casher/bin/casher: line 230: md5deep: command not > found nothing changed "" > > >>> [Lance] > >>> Thanks for pointing out the issue. The upload cache on arm is not > >>> successful, that means arm jobs will always clone and build DPDK. I > >>> just posted this issue to Travis CI community. You can see: > >>> https://travis-ci.community/t/no-cache-support-on-arm64/5416/21 > >> > >> Thanks! Let's wait for their reply. > >> > >> Best regards, Ilya Maximets. > > [Lance] > > > > Hi Ilya, > > > > It seems that travis CI has fixed the md5deep: command not found issue. You > > can refer > the link: > https://travis-ci.community/t/no-cache-support-on-arm64/5416/23?u=yzyuestc. > And if you check https://travis-ci.community/t/no-cache-support-on- > arm64/5416/26?u=yzyuestc, you will find Travis has deployed it to production. > > > > I triggered a build and found it works, the report on line 5093: > > https://travis- > ci.org/yzyuestc/ovs/jobs/616991450#L5093 It shows the correct directory has > been > uploaded successfully. > > Cool. Thank you. > Will you send a v2 of this series? > > Best regards, Ilya maximets. [Lance] Yes. Once we update for v2, we will send you the
[ovs-dev] Planificación estratégica para RRHH
17 de Enero | Horario de 10:00 a 17:00 hrs. | (hora del centro de México) - Planificación estratégica del departamento de Recursos Humanos. - ¿De qué hablaremos? A través de este webinar se revisarán todas aquellas funciones y responsabilidades del área de Recursos Humanos desde un enfoque estratégico, identificando claramente las prácticas que permiten impulsar a la organización a un nivel de desempeño superior, alineado en todo momento a los objetivos organizacionales y variables del entorno para hacer frente de manera proactiva y efectiva a los retos y oportunidades que pueda vivir la compañía. ¿Qué aprenderás?: - Retos de Recursos Humanos en la actualidad. - Planeación estratégica. - Selección y organización del talento. - Capacitación y desarrollo. - Evaluación del talento. - Motivación y compensaciones. - Relaciones laborales. Solicita información respondiendo a este correo con la palabra Planificación, junto con los siguientes datos: Nombre: Correo electrónico: Número telefónico: Dirigido a: Personal de Recursos Humanos, Administradores, Contadores o personal en general interesado en tópicos de Recursos Humanos. Números de Atención: (045) 55 15 54 66 30 - (045) 55 85567293 - (045) 5530167085 En caso de que haya recibido este correo sin haberlo solicitado o si desea dejar de recibir nuestra promoción favor de responder con la palabra baja o enviar un correo a bajas@ innovalearn.net ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Detección de Necesidades de Capacitación
16 de Enero | Horario de 10:00 a 17:00 hrs. | (hora del centro de México) - ¿Cómo realizar una Detección de Necesidades de Capacitación de manera efectiva? - El Diagnóstico de las Necesidades de Capacitación (DNC) es un proceso de suma importancia durante la planeación de la capacitación y formación continua de los colaboradores de las organizaciones que permite identificar a quienes requieren capacitación, en qué aspectos deben ser capacitados y en qué momento se les debe capacitar. Este curso le otorgará conceptos y herramientas para elaborar DNC efectivas que contribuyan con el logro de los objetivos de su organización o empresa. Objetivos específicos: - Comprenderá qué es un DNC y en qué momento debe elaborarlo. - Identificará los segmentos de tipos de capacitación a diagnosticar. - Conocerá los principales requisitos para el desarrollo de una DNC efectiva. - Será capaz de segmentar y ubicar al personal en la Matriz de Necesidades de Capacitación. - Podrá elaborar estrategias para monitorear el impacto de la capacitación en los objetivos del negocio. Solicita información respondiendo a este correo con la palabra DNC, junto con los siguientes datos: Nombre: Correo electrónico: Número telefónico: Números de Atención: (045) 55 15 54 66 30 - (045) 55 85567293 - (045) 5530167085 En caso de que haya recibido este correo sin haberlo solicitado o si desea dejar de recibir nuestra promoción favor de responder con la palabra baja o enviar un correo a bajas@ innovalearn.net ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI for arm
On 27.11.2019 8:11, Lance Yang (Arm Technology China) wrote: > >> -Original Message- >> From: Ilya Maximets >> Sent: Friday, November 22, 2019 6:36 PM >> To: Lance Yang (Arm Technology China) ; Ilya Maximets >> ; ovs-dev@openvswitch.org >> Cc: Jieqiang Wang (Arm Technology China) ; Gavin Hu >> (Arm >> Technology China) ; Jingzhao Ni (Arm Technology China) >> ; dwil...@us.ibm.com; nd ; Ruifeng Wang >> (Arm >> Technology China) ; Yanqin Wei (Arm Technology China) >> >> Subject: Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI for arm >> >> On 22.11.2019 10:35, Lance Yang (Arm Technology China) wrote: >>> Hi Ilya, >>> >>> Thanks for your reply. Please see the inline reply. >>> >>> Best regards, >>> Lance Yang >>> -Original Message- From: Ilya Maximets Sent: Friday, November 22, 2019 3:47 AM To: Lance Yang (Arm Technology China) ; ovs- d...@openvswitch.org Cc: Jieqiang Wang (Arm Technology China) ; Gavin Hu (Arm Technology China) ; Jingzhao Ni (Arm Technology China) ; dwil...@us.ibm.com; nd ; Ruifeng Wang (Arm Technology China) Subject: Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI for arm On 20.11.2019 9:15, Lance Yang wrote: > Enable part of travis jobs with gcc compiler for arm64 architecture > > 1. Add arm jobs into the matrix in .travis.yml and define dpdk cache > directory for arm64 architecture. > 2. Temporarily disable sparse checker because of static code > checking failure on arm64 Could you provide the sparse error messages? Maybe we could fix them instead of disabling. > > Successful travis build jobs report: > https://travis-ci.org/yzyuestc/ovs/builds/614299933 There are some issues in Travis in above build. It seems that Travis fails to upload the resulted cache directory due to missing md5deep: "" >>> [Lance] >>> The issue occurred because sparse checker does not recognize some arm neon >>> intrinsics: >>> >>> 1. Some components in Open vSwitch source code directly includes the header >>> file >> . >>> >>> 2. When compiling OvS with DPDK, OvS includes some DPDK headers, which >>> sometimes includes . You can see the details of the error >>> in the report at: https://travis-ci.org/yzyuestc/ovs/jobs/615414391 >>> after line 2693 >>> >>> For the first issue where OvS directly imported the arm_neon.h, I can fix >>> it in my patch set >> v2. However, for the second issue that DPDK project has imported the arm >> neon intrinsics, it >> seems that I am unable to fix this issue until DPDK solved it. >> >> Hi. >> >> Thanks for the information. >> Could, you, please, check if the following patch fixes the issue: >> https://patchwork.ozlabs.org/patch/1199398/ >> ? >> >>> store build cache 0.02s5.41sInstalling md5deep Reading package lists... Building dependency tree... Reading state information... md5deep is already the newest version (4.4-2). 0 upgraded, 0 newly installed, 0 to remove and 8 not upgraded. /home/travis/.casher/bin/casher: line 230: md5deep: command not found nothing changed "" >>> [Lance] >>> Thanks for pointing out the issue. The upload cache on arm is not >>> successful, that means arm jobs will always clone and build DPDK. I >>> just posted this issue to Travis CI community. You can see: >>> https://travis-ci.community/t/no-cache-support-on-arm64/5416/21 >> >> Thanks! Let's wait for their reply. >> >> Best regards, Ilya Maximets. > [Lance] > > Hi Ilya, > > It seems that travis CI has fixed the md5deep: command not found issue. You > can refer the link: > https://travis-ci.community/t/no-cache-support-on-arm64/5416/23?u=yzyuestc. > And if you check > https://travis-ci.community/t/no-cache-support-on-arm64/5416/26?u=yzyuestc, > you will find Travis has deployed it to production. > > I triggered a build and found it works, the report on line 5093: > https://travis-ci.org/yzyuestc/ovs/jobs/616991450#L5093 It shows the correct > directory has been uploaded successfully. Cool. Thank you. Will you send a v2 of this series? Best regards, Ilya maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 2/4] travis: Move x86-only addon packages
On 22.11.2019 10:23, Yanqin Wei (Arm Technology China) wrote:
> Hi Ilya,
>
> Reply inline.
>
> Best Regards,
> Wei Yanqin
>
>> -Original Message-
>> From: dev On Behalf Of Ilya Maximets
>> Sent: Friday, November 22, 2019 3:30 AM
>> To: Lance Yang (Arm Technology China) ;
>> d...@openvswitch.org; ovs-dev@openvswitch.org
>> Cc: Jieqiang Wang (Arm Technology China) ;
>> Ruifeng Wang (Arm Technology China) ; Gavin Hu
>> (Arm Technology China) ; Jingzhao Ni (Arm Technology
>> China) ; nd
>> Subject: Re: [ovs-dev] [PATCH v1 2/4] travis: Move x86-only addon packages
>>
>> On 20.11.2019 9:14, Lance Yang wrote:
>>> To enable multiple CPU architectures support, it is necessary to move
>>> the x86-only addon packages from .travis.yml file. Otherwise, the
>>> x86-only addon packages will break the builds on some other CPU
>> architectures.
>>>
>>> Reviewed-by: Yangqin Wei
>>> Reviewed-by: Malvika Gupta
>>> Reviewed-by: Gavin Hu
>>> Reviewed-by: Ruifeng Wang
>>> Signed-off-by: Lance Yang
>>> ---
>>> .travis.yml | 2 --
>>> .travis/linux-prepare.sh | 12
>>> 2 files changed, 8 insertions(+), 6 deletions(-)
>>
>> Common comment for all the patches in a series:
>> * It's better to add a period in the end of a subject line.
> [Yanqin] OK.
>>
>>>
>>> diff --git a/.travis.yml b/.travis.yml index 482efd2..2dc4d43 100644
>>> --- a/.travis.yml
>>> +++ b/.travis.yml
>>> @@ -14,7 +14,6 @@ addons:
>>>apt:
>>> packages:
>>>- bc
>>> - - gcc-multilib
>>>- libssl-dev
>>>- llvm-dev
>>>- libjemalloc1
>>> @@ -26,7 +25,6 @@ addons:
>>>- libelf-dev
>>>- selinux-policy-dev
>>>- libunbound-dev
>>> - - libunbound-dev:i386
>>>- libunwind-dev
>>>
>>> before_install: ./.travis/${TRAVIS_OS_NAME}-prepare.sh
>>> diff --git a/.travis/linux-prepare.sh b/.travis/linux-prepare.sh index
>>> 9e3ac0d..8096abe 100755
>>> --- a/.travis/linux-prepare.sh
>>> +++ b/.travis/linux-prepare.sh
>>> @@ -15,10 +15,14 @@ cd ..
>>> pip install --disable-pip-version-check --user six flake8 hacking
>>> pip install --user --upgrade docutils
>>>
>>> -if [ "$M32" ]; then
>>> -# 32-bit and 64-bit libunwind can not be installed at the same time.
>>> -# This will remove the 64-bit libunwind and install 32-bit version.
>>> -sudo apt-get install -y libunwind-dev:i386
>>> +if [[ "$TRAVIS_ARCH" == "amd64" ]] || [[ -z "$TRAVIS_ARCH" ]]; then
>>
>> The same comment here as for previous ppc64le patch.
>> Are you going to ever build 32bit binary on aarch64 on Travis?
>> Is it really possible to build 32bit binary on aarch64 with '-m32' flag?
> [Yanqin] Not yet. Gcc for aarch64 does not support -m32 flag. Cross compiler
> is required to build 32 bits binary on aarch64 machine.
In this case I don't think that we need to check for ARCH here.
It's enough to check for M32.
>
>>
>>> +if [ "$M32" ]; then
>>> +# 32-bit and 64-bit libunwind can not be installed at the same
>>> time.
>>> +# This will remove the 64-bit libunwind and install 32-bit version.
>>> +sudo apt-get install \
>>> +-y libunwind-dev:i386 libunbound-dev:i386 gcc-multilib
>>
>> Please, add additional indentation level for above line.
> [Yanqin] Thanks, will be updated in V2.
>>
>>> +fi
>>> +
>>> fi
>>>
>>> # IPv6 is supported by kernel but disabled in TravisCI images:
>>>
>> ___
>> dev mailing list
>> d...@openvswitch.org
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI for arm
On 27.11.2019 8:49, Lance Yang (Arm Technology China) wrote: > > >> -Original Message- >> From: Ilya Maximets >> Sent: Tuesday, November 26, 2019 8:48 PM >> To: Ilya Maximets ; Lance Yang (Arm Technology China) >> ; ovs-dev@openvswitch.org >> Cc: Jieqiang Wang (Arm Technology China) ; Gavin Hu >> (Arm >> Technology China) ; Jingzhao Ni (Arm Technology China) >> ; dwil...@us.ibm.com; nd ; Ruifeng Wang >> (Arm >> Technology China) ; Yanqin Wei (Arm Technology China) >> ; Ben Pfaff >> Subject: Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI for arm >> >> On 26.11.2019 13:37, Ilya Maximets wrote: >>> On 25.11.2019 7:28, Lance Yang (Arm Technology China) wrote: > -Original Message- > From: Ilya Maximets > Sent: Friday, November 22, 2019 6:36 PM > To: Lance Yang (Arm Technology China) ; Ilya > Maximets ; ovs-dev@openvswitch.org > Cc: Jieqiang Wang (Arm Technology China) ; > Gavin Hu (Arm Technology China) ; Jingzhao Ni (Arm > Technology China) ; dwil...@us.ibm.com; nd > ; Ruifeng Wang (Arm Technology China) > ; Yanqin Wei (Arm Technology China) > > Subject: Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI > for arm > > On 22.11.2019 10:35, Lance Yang (Arm Technology China) wrote: >> Hi Ilya, >> >> Thanks for your reply. Please see the inline reply. >> >> Best regards, >> Lance Yang >> >>> -Original Message- >>> From: Ilya Maximets >>> Sent: Friday, November 22, 2019 3:47 AM >>> To: Lance Yang (Arm Technology China) ; ovs- >>> d...@openvswitch.org >>> Cc: Jieqiang Wang (Arm Technology China) ; >>> Gavin Hu (Arm Technology China) ; Jingzhao Ni >>> (Arm Technology China) ; dwil...@us.ibm.com; >>> nd ; Ruifeng Wang (Arm Technology China) >>> >>> Subject: Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI >>> for arm >>> >>> On 20.11.2019 9:15, Lance Yang wrote: Enable part of travis jobs with gcc compiler for arm64 architecture 1. Add arm jobs into the matrix in .travis.yml and define dpdk cache directory for arm64 architecture. 2. Temporarily disable sparse checker because of static code checking failure on arm64 >>> >>> Could you provide the sparse error messages? >>> Maybe we could fix them instead of disabling. >>> Successful travis build jobs report: https://travis-ci.org/yzyuestc/ovs/builds/614299933 >>> >>> There are some issues in Travis in above build. It seems that >>> Travis fails to upload the resulted cache directory due to missing >>> md5deep: >>> >>> "" >> [Lance] >> The issue occurred because sparse checker does not recognize some arm >> neon >> intrinsics: >> >> 1. Some components in Open vSwitch source code directly includes >> the header file > . >> >> 2. When compiling OvS with DPDK, OvS includes some DPDK headers, >> which sometimes includes . You can see the details of >> the error in the report at: >> https://travis-ci.org/yzyuestc/ovs/jobs/615414391 >> after line 2693 >> >> For the first issue where OvS directly imported the arm_neon.h, I >> can fix it in my patch set > v2. However, for the second issue that DPDK project has imported the > arm neon intrinsics, it seems that I am unable to fix this issue until > DPDK solved it. > > Hi. > > Thanks for the information. > Could, you, please, check if the following patch fixes the issue: > https://patchwork.ozlabs.org/patch/1199398/ > ? [Lance] Thanks for your reply. I downloaded and applied the patch from patchwork. However, it seems that the patch >> does not work as expected. I attached the original travis report link: >> https://travis- >> ci.org/yzyuestc/ovs/jobs/616442657#L2692. You can check the error after line >> 2692. >>> >>> >>> Thanks for checking. I found the root cause. >>> The issue is that GCC has NEON vector types as compiler built-in types. >>> x86 vector types (e.g. __m128i) are typedefs of a normal types with a >>> special 'vector_size' attribute that sparse understands. But it can >>> not understand special built-in types. Note that clang defines NEON >>> vector types with 'vector_size' attribute inside arm_neon.h, so it's >>> unclear why GCC doesn't do the same. >>> >>> So, there are 3 options on how we can fix that: >>> >>> 1. Create special include/sparse/arm_neon.h header and mock all the >>>GCC built-ins for NEON support. This doesn't look very hard, but >>>could take some time. I tried to re-define all the base types this >>>way, but it requires something else and I need to look at exact >>>arm_neon.h that is in use to understand what is missing. We, probably, >>>will have to mock a bunch of NEON-specific built-in
Re: [ovs-dev] [PATCH] dpif-netdev-perf: aarch64 support for accurate timing update of TSC cycle counter
On 27.11.2019 8:38, Yanqin Wei (Arm Technology China) wrote:
> Hi Ilya,
>
> No, we didn't test this patch based on OVS-AF_XDP, but made a black build to
> enable this in OVS-DPDK and test it.
> Currently DPDK-AF_XDP has been tested in latest kernel (not released). So I
> think OVS-AF_XDP is close to be supported for aarch64.
>
> Furthermore, I found a document about userspace-only mode of Open vSwitch
> without DPDK.
> http://docs.openvswitch.org/en/latest/intro/install/userspace/#using-the-userspace-datapath-with-ovs-vswitchd
> So it seems userspace datapath should be decoupled with networking IO, users
> can even customize this. Does it means we need implement all used DPDK API
> inside OVS?
Userspace datapath in OVS doesn't depend on DPDK. DPDK only provides
a few port types (dpdk, dpdkvhostuser, etc.). It's fully functional
by itself. For example you may use it to forward packets with OVS-native
afxdp ports: http://docs.openvswitch.org/en/latest/intro/install/afxdp/
Best regards, Ilya Maximets.
>
> Best Regards,
> Wei Yanqin
>
>
>> -Original Message-
>> From: dev On Behalf Of Ilya Maximets
>> Sent: Tuesday, November 26, 2019 11:38 PM
>> To: Malvika Gupta ; d...@openvswitch.org
>> Cc: nd ; Honnappa Nagarahalli
>>
>> Subject: Re: [ovs-dev] [PATCH] dpif-netdev-perf: aarch64 support for accurate
>> timing update of TSC cycle counter
>>
>> On 13.11.2019 18:01, Malvika Gupta wrote:
>>> The accurate timing implementation in this patch gets the wall clock
>>> counter via
>>> cntvct_el0 register access. This call is portable to all aarch64
>>> architectures and has been verified on an 64-bit arm server.
>>>
>>> Suggested-by: Yanqin Wei
>>> Signed-off-by: Malvika Gupta
>>> ---
>>
>> Thanks for the patch!
>>
>> Are you trying to use AF_XDP on aarch64? Asking because it's the only real
>> scenario where this patch can be useful.
>>
>> For the patch subject, I'd suggest to shorten it a little.
>> 'timing', 'TSC' and 'cycle counter' are kind of synonyms here and doesn't
>> make
>> the sentence any clear. Suggesting something like this:
>> "dpif-netdev-perf: Accurate cycle counter update on aarch64."
>>
>> What do you think?
>>
>> One more comment inline.
>>
>>> lib/dpif-netdev-perf.h | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/lib/dpif-netdev-perf.h b/lib/dpif-netdev-perf.h index
>>> ce369375b..4ea7cc355 100644
>>> --- a/lib/dpif-netdev-perf.h
>>> +++ b/lib/dpif-netdev-perf.h
>>> @@ -220,6 +220,11 @@ cycles_counter_update(struct pmd_perf_stats *s)
>>> asm volatile("rdtsc" : "=a" (l), "=d" (h));
>>>
>>> return s->last_tsc = ((uint64_t) h << 32) | l;
>>> +#elif !defined(_MSC_VER) && defined(__aarch64__)
>>> +uint64_t tsc;
>>> +asm volatile("mrs %0, cntvct_el0" : "=r" (tsc));
>>> +
>>> +return s->last_tsc = tsc;
>>
>> I think we could drop the 'tsc' local variable here and write directly to s-
>>> last_tsc. Less number of variables and operations.
>>
>> 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
Re: [ovs-dev] [PATCH] dp-packet: Fix clearing/copying of memory layout flags.
On 28.11.2019 14:42, Kevin Traynor wrote: > On 27/11/2019 20:33, David Marchand wrote: >> On Thu, Nov 21, 2019 at 3:35 PM Ilya Maximets wrote: >>> >>> On 21.11.2019 14:58, Ilya Maximets wrote: 'ol_flags' of DPDK mbuf could contain bits responsible for external or indirect buffers which are not actually offload flags in a common sense. Clearing/copying of these flags could lead to memory leaks of external memory chunks and crashes due to access to wrong memory. OVS should not clear these flags while resetting offloads and also should not copy them to the newly allocated packets. This change is required to support DPDK 19.11, as some drivers may return mbufs with these flags set. However, it might be good to do the same for DPDK 18.11, because these flags are present and should be taken into account. Signed-off-by: Ilya Maximets >> >> As discussed during the OVS-DPDK public meeting earlier, I am ok with >> your suggestion of going with this patch as a first step. >> We will have to keep an eye on new flags on the dpdk side. >> >> Then once the dpdk ring ports have been dropped, we can revisit this. >> >> Reviewed-by: David Marchand >> > > +1 > > Acked-by: Kevin Traynor Thanks! Applied to master and branch-2.12. OVS 2.11 uses DPDK 18.11 too, but it seems that we're not clearing flags on that branch. Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] netdev-dpdk: Deprecate ring ports.
On 26.11.2019 12:31, Ilya Maximets wrote: > 'dpdkr' a.k.a. DPDK ring ports has really poor support in OVS and not > tested on a regular basis. These ports are intended to work via > shared memory with another DPDK secondary process, but there are lots > of limitations for using this functionality in practice. Most of them > connected with running secondary DPDK application and memory layout > issues. More details are available in DPDK guide: > https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html#multi-process-limitations > > Beside the functional limitations it's also hard to use this > functionality correctly. User must be sure that OVS and secondary DPDK > application are running on different CPU cores, which is hard because > non-PMD threads could float over available CPU cores. This or any > other misconfiguration will likely lead to crash of OVS. > > Another problem is that the user must actually build the secondary > application with the same version of DPDK that was used for OVS build. > > Above issues are same as we have while using DPDK pdump. > > Beside that, current implementation in OVS is not able to free > allocated rings that could lead to memory exhausting. > > Initially these ports was added to use with IVSHMEM for a fast > zero-copy HOST<-->VM communication. However, IVSHMEM is not used > anymore. IVSHMEM support was removed from DPDK in 16.11 relase and > the patch for QEMU for using regular files as a device backend is no > longer available. That makes DPDK ring ports barely useful in real > virtualization environment. > > This patch adds a deprecation warnings for run-time port creation > and documentation. Claiming to completely remove this functionality > from OVS in one of the next releases. > > Signed-off-by: Ilya Maximets > --- Thanks to all. I updated the commit-message with suggestions from David and Kevin and applied to master. Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ofproto-provider: Move datapath capabilities callback to correct section.
On 26.11.2019 21:35, William Tu wrote:
> On Tue, Nov 26, 2019 at 12:25 PM Ilya Maximets wrote:
>>
>> 'get_datapath_cap' callback was mistakenly placed in
>> 'Connection tracking' section of the 'struct dpif_class'
>> while belongs to the 'Datapath information'.
>>
>> CC: William Tu
>> Fixes: 27501802d09f ("ofproto-dpif: Expose datapath capability to ovsdb.")
>> Signed-off-by: Ilya Maximets
>
> LGTM, Thanks!
> Acked-by: William Tu
Thanks! Applied to master.
Best regards, Ilya Maximets.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2 ovn 0/2] Add support for PRF and Route Info Option in RA (RFC 4191)
On Thu, Nov 28, 2019 at 6:19 PM Lorenzo Bianconi wrote: > > Changes since v1: > - rename prf in router_preference in OVN NB DB > - allocate space for ovs_nd_route_info in ovs packet after data validation > > Lorenzo Bianconi (2): > Add support to Default Router Preference (PRF) - RFC 4191 > Add support for Route Info Option in RA - RFC 4191 Thanks Lorenzo. I applied this series to master. Thanks Numan > > controller/pinctrl.c | 100 +-- > lib/ovn-l7.h | 16 +++ > northd/ovn-northd.c | 14 ++ > ovn-nb.xml | 26 +++ > tests/ovn.at | 35 ++- > 5 files changed, 178 insertions(+), 13 deletions(-) > > -- > 2.21.0 > > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn] ovn-controller: Consider non-virtual ports first when updating bindings.
On Thu, Nov 28, 2019 at 2:36 PM Numan Siddique wrote:
>
> On Sat, Nov 23, 2019 at 3:51 AM Mark Michelson wrote:
> >
> > Acked-by: Mark Michelson
> >
> > On 11/22/19 9:22 AM, Dumitru Ceara wrote:
> > > There's no guarantee SBREC_PORT_BINDING_TABLE_FOR_EACH will first
> > > return the non-virtual ports and then virtual ports. In the case when a
> > > virtual port is processed before its virtual_parent,
> > > consider_local_datapath might not release it in the current
> > > ovn-controller iteration even though the virtual_parent gets released.
> > >
> > > Right now this doesn't trigger any functionality issue because releasing
> > > the virtual_parent triggers a change in the SB DB which will wake up
> > > ovn-controller and trigger a new computation which will also update the
> > > virtual port.
> > >
> > > However, this is suboptimal, and we can notice that often ovn-controller
> > > gets the SB update notification before the "transaction successful"
> > > notification. In such cases the incremental engine doesn't run
> > > (ovnsb_idl_txn == NULL) and a full recompute is scheduled for the next
> > > run. By batching the two SB updates in a single transaction we
> > > lower the risk of this situation happening.
> > >
> > > CC: Numan Siddique
> > > Fixes: 054f4c85c413 ("Add a new logical switch port type - 'virtual'")
> > > Signed-off-by: Dumitru Ceara
>
> Thanks. I applied this patch to master.
>
> Numan
Thanks Mark and Numan!
>
> > > ---
> > > controller/binding.c | 97
> > > +---
> > > 1 file changed, 69 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/controller/binding.c b/controller/binding.c
> > > index aad9d39..4c107c1 100644
> > > --- a/controller/binding.c
> > > +++ b/controller/binding.c
> > > @@ -472,7 +472,12 @@ is_our_chassis(const struct sbrec_chassis
> > > *chassis_rec,
> > > return our_chassis;
> > > }
> > >
> > > -static void
> > > +/* Updates 'binding_rec' and if the port binding is local also updates
> > > the
> > > + * local datapaths and ports.
> > > + * Updates and returns the array of local virtual ports that will require
> > > + * additional processing.
> > > + */
> > > +static const struct sbrec_port_binding **
> > > consider_local_datapath(struct ovsdb_idl_txn *ovnsb_idl_txn,
> > > struct ovsdb_idl_txn *ovs_idl_txn,
> > > struct ovsdb_idl_index
> > > *sbrec_datapath_binding_by_key,
> > > @@ -485,7 +490,9 @@ consider_local_datapath(struct ovsdb_idl_txn
> > > *ovnsb_idl_txn,
> > > struct hmap *local_datapaths,
> > > struct shash *lport_to_iface,
> > > struct sset *local_lports,
> > > -struct sset *local_lport_ids)
> > > +struct sset *local_lport_ids,
> > > +const struct sbrec_port_binding **vpbs,
> > > +size_t *n_vpbs, size_t *n_allocated_vpbs)
> > > {
> > > const struct ovsrec_interface *iface_rec
> > > = shash_find_data(lport_to_iface, binding_rec->logical_port);
> > > @@ -587,22 +594,11 @@ consider_local_datapath(struct ovsdb_idl_txn
> > > *ovnsb_idl_txn,
> > > }
> > > } else if (binding_rec->chassis == chassis_rec) {
> > > if (!strcmp(binding_rec->type, "virtual")) {
> > > -/* pinctrl module takes care of binding the ports
> > > - * of type 'virtual'.
> > > - * Release such ports if their virtual parents are no
> > > - * longer claimed by this chassis. */
> > > -const struct sbrec_port_binding *parent
> > > -= lport_lookup_by_name(sbrec_port_binding_by_name,
> > > -binding_rec->virtual_parent);
> > > -if (!parent || parent->chassis != chassis_rec) {
> > > -VLOG_INFO("Releasing lport %s from this chassis.",
> > > -binding_rec->logical_port);
> > > -if (binding_rec->encap) {
> > > -sbrec_port_binding_set_encap(binding_rec, NULL);
> > > -}
> > > -sbrec_port_binding_set_chassis(binding_rec, NULL);
> > > -sbrec_port_binding_set_virtual_parent(binding_rec,
> > > NULL);
> > > +if (*n_vpbs == *n_allocated_vpbs) {
> > > +vpbs = x2nrealloc(vpbs, n_allocated_vpbs, sizeof
> > > *vpbs);
> > > }
> > > +vpbs[(*n_vpbs)] = binding_rec;
> > > +(*n_vpbs)++;
> > > } else {
> > > VLOG_INFO("Releasing lport %s from this chassis.",
> > > binding_rec->logical_port);
> > > @@ -621,6 +617,30 @@ consider_local_datapath(struct ovsdb_idl_txn
> > > *ovnsb_idl_txn,
> > >
Re: [ovs-dev] [PATCH] dp-packet: Fix clearing/copying of memory layout flags.
On 27/11/2019 20:33, David Marchand wrote:
> On Thu, Nov 21, 2019 at 3:35 PM Ilya Maximets wrote:
>>
>> On 21.11.2019 14:58, Ilya Maximets wrote:
>>> 'ol_flags' of DPDK mbuf could contain bits responsible for external
>>> or indirect buffers which are not actually offload flags in a common
>>> sense. Clearing/copying of these flags could lead to memory leaks of
>>> external memory chunks and crashes due to access to wrong memory.
>>>
>>> OVS should not clear these flags while resetting offloads and also
>>> should not copy them to the newly allocated packets.
>>>
>>> This change is required to support DPDK 19.11, as some drivers may
>>> return mbufs with these flags set. However, it might be good to do
>>> the same for DPDK 18.11, because these flags are present and should
>>> be taken into account.
>>>
>>> Signed-off-by: Ilya Maximets
>
> As discussed during the OVS-DPDK public meeting earlier, I am ok with
> your suggestion of going with this patch as a first step.
> We will have to keep an eye on new flags on the dpdk side.
>
> Then once the dpdk ring ports have been dropped, we can revisit this.
>
> Reviewed-by: David Marchand
>
+1
Acked-by: Kevin Traynor
>
>> We could also add the following tag:
>> Fixes: 03f3f9c0faf8 ("dpdk: Update to use DPDK 18.11.")
>
> Yes.
>
> Thanks.
>
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn] ovn-controller: Consider non-virtual ports first when updating bindings.
On Sat, Nov 23, 2019 at 3:51 AM Mark Michelson wrote:
>
> Acked-by: Mark Michelson
>
> On 11/22/19 9:22 AM, Dumitru Ceara wrote:
> > There's no guarantee SBREC_PORT_BINDING_TABLE_FOR_EACH will first
> > return the non-virtual ports and then virtual ports. In the case when a
> > virtual port is processed before its virtual_parent,
> > consider_local_datapath might not release it in the current
> > ovn-controller iteration even though the virtual_parent gets released.
> >
> > Right now this doesn't trigger any functionality issue because releasing
> > the virtual_parent triggers a change in the SB DB which will wake up
> > ovn-controller and trigger a new computation which will also update the
> > virtual port.
> >
> > However, this is suboptimal, and we can notice that often ovn-controller
> > gets the SB update notification before the "transaction successful"
> > notification. In such cases the incremental engine doesn't run
> > (ovnsb_idl_txn == NULL) and a full recompute is scheduled for the next
> > run. By batching the two SB updates in a single transaction we
> > lower the risk of this situation happening.
> >
> > CC: Numan Siddique
> > Fixes: 054f4c85c413 ("Add a new logical switch port type - 'virtual'")
> > Signed-off-by: Dumitru Ceara
Thanks. I applied this patch to master.
Numan
> > ---
> > controller/binding.c | 97
> > +---
> > 1 file changed, 69 insertions(+), 28 deletions(-)
> >
> > diff --git a/controller/binding.c b/controller/binding.c
> > index aad9d39..4c107c1 100644
> > --- a/controller/binding.c
> > +++ b/controller/binding.c
> > @@ -472,7 +472,12 @@ is_our_chassis(const struct sbrec_chassis *chassis_rec,
> > return our_chassis;
> > }
> >
> > -static void
> > +/* Updates 'binding_rec' and if the port binding is local also updates the
> > + * local datapaths and ports.
> > + * Updates and returns the array of local virtual ports that will require
> > + * additional processing.
> > + */
> > +static const struct sbrec_port_binding **
> > consider_local_datapath(struct ovsdb_idl_txn *ovnsb_idl_txn,
> > struct ovsdb_idl_txn *ovs_idl_txn,
> > struct ovsdb_idl_index
> > *sbrec_datapath_binding_by_key,
> > @@ -485,7 +490,9 @@ consider_local_datapath(struct ovsdb_idl_txn
> > *ovnsb_idl_txn,
> > struct hmap *local_datapaths,
> > struct shash *lport_to_iface,
> > struct sset *local_lports,
> > -struct sset *local_lport_ids)
> > +struct sset *local_lport_ids,
> > +const struct sbrec_port_binding **vpbs,
> > +size_t *n_vpbs, size_t *n_allocated_vpbs)
> > {
> > const struct ovsrec_interface *iface_rec
> > = shash_find_data(lport_to_iface, binding_rec->logical_port);
> > @@ -587,22 +594,11 @@ consider_local_datapath(struct ovsdb_idl_txn
> > *ovnsb_idl_txn,
> > }
> > } else if (binding_rec->chassis == chassis_rec) {
> > if (!strcmp(binding_rec->type, "virtual")) {
> > -/* pinctrl module takes care of binding the ports
> > - * of type 'virtual'.
> > - * Release such ports if their virtual parents are no
> > - * longer claimed by this chassis. */
> > -const struct sbrec_port_binding *parent
> > -= lport_lookup_by_name(sbrec_port_binding_by_name,
> > -binding_rec->virtual_parent);
> > -if (!parent || parent->chassis != chassis_rec) {
> > -VLOG_INFO("Releasing lport %s from this chassis.",
> > -binding_rec->logical_port);
> > -if (binding_rec->encap) {
> > -sbrec_port_binding_set_encap(binding_rec, NULL);
> > -}
> > -sbrec_port_binding_set_chassis(binding_rec, NULL);
> > -sbrec_port_binding_set_virtual_parent(binding_rec,
> > NULL);
> > +if (*n_vpbs == *n_allocated_vpbs) {
> > +vpbs = x2nrealloc(vpbs, n_allocated_vpbs, sizeof
> > *vpbs);
> > }
> > +vpbs[(*n_vpbs)] = binding_rec;
> > +(*n_vpbs)++;
> > } else {
> > VLOG_INFO("Releasing lport %s from this chassis.",
> > binding_rec->logical_port);
> > @@ -621,6 +617,30 @@ consider_local_datapath(struct ovsdb_idl_txn
> > *ovnsb_idl_txn,
> >vif_chassis);
> > }
> > }
> > +return vpbs;
> > +}
> > +
> > +static void
> > +consider_local_virtual_port(struct ovsdb_idl_index
> > *sbrec_port_binding_by_name,
> > +const struct sbrec_chassis *chassis_rec,
> > +const
Re: [ovs-dev] [PATCH ovn 2/2] Add support for Route Info Option in RA - RFC 4191
> On Thu, Nov 14, 2019 at 5:10 PM Lorenzo Bianconi
> wrote:
> >
> > Introduce support for Route Info Option sent in Router
> > Advertisement according to RFC 4191. Route Info Option are
> > configured providing route_info in ipv6_ra_configs column of
> > Logical_Router_Port table. route_info is a comma separated string
> > where each field provides PRF and prefix for a given route
> > (e.g: HIGH-aef1::11/48,LOW-aef2::11/96)
> >
> > Signed-off-by: Lorenzo Bianconi
> > ---
> > controller/pinctrl.c | 80
> > lib/ovn-l7.h | 12 +++
> > northd/ovn-northd.c | 6
> > ovn-nb.xml | 14
> > tests/ovn.at | 32 --
> > 5 files changed, 133 insertions(+), 11 deletions(-)
> >
> > diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> > index b736b60ad..51c7f8a36 100644
> > --- a/controller/pinctrl.c
> > +++ b/controller/pinctrl.c
> > @@ -2195,6 +2195,7 @@ struct ipv6_ra_config {
> > struct in6_addr rdnss;
> > bool has_rdnss;
> > struct ds dnssl;
> > +struct ds route_info;
> > };
> >
> > struct ipv6_ra_state {
> > @@ -2217,6 +2218,7 @@ ipv6_ra_config_delete(struct ipv6_ra_config *config)
> > if (config) {
> > destroy_lport_addresses(>prefixes);
> > ds_destroy(>dnssl);
> > +ds_destroy(>route_info);
> > free(config);
> > }
> > }
> > @@ -2256,6 +2258,7 @@ ipv6_ra_update_config(const struct sbrec_port_binding
> > *pb)
> > config->mtu = smap_get_int(>options, "ipv6_ra_mtu",
> > ND_MTU_DEFAULT);
> > config->la_flags = IPV6_ND_RA_OPT_PREFIX_ON_LINK;
> > ds_init(>dnssl);
> > +ds_init(>route_info);
> >
> > const char *address_mode = smap_get(>options,
> > "ipv6_ra_address_mode");
> > if (!address_mode) {
> > @@ -2313,6 +2316,11 @@ ipv6_ra_update_config(const struct
> > sbrec_port_binding *pb)
> > ds_put_buffer(>dnssl, dnssl, strlen(dnssl));
> > }
> >
> > +const char *route_info = smap_get(>options, "ipv6_ra_route_info");
> > +if (route_info) {
> > +ds_put_buffer(>route_info, route_info, strlen(route_info));
> > +}
> > +
> > return config;
> >
> > fail:
> > @@ -2420,6 +2428,74 @@ packet_put_ra_dnssl_opt(struct dp_packet *b,
> > ovs_be32 lifetime,
> >prev_l4_size +
> > size));
> > }
> >
> > +static void
> > +packet_put_ra_route_info_opt(struct dp_packet *b, ovs_be32 lifetime,
> > + char *route_list)
> > +{
> > +size_t prev_l4_size = dp_packet_l4_size(b);
> > +struct ip6_hdr *nh = dp_packet_l3(b);
> > +char *t0, *r0 = NULL;
> > +size_t size = 0;
> > +
> > +for (t0 = strtok_r(route_list, ",", ); t0;
> > + t0 = strtok_r(NULL, ",", )) {
> > +struct ovs_nd_route_info *nd_rinfo =
> > +dp_packet_put_uninit(b, sizeof *nd_rinfo);
>
> Let's say user has configured this option as "HIGH-foo". In this case,
> dp_packet_put_uninit will reserve
> sizeof *nd_rinfo bytes in the packet, but since validation fails, this
> function returns without adding route info to
> the packet and the packet is sent with invalid data.
>
> I think it's better to call dp_packet_put after the validation.
Hi Numan,
thx for the review. Fixed in v2.
Regards,
Lorenzo
>
> Thanks
> Numan
>
> > +char *t1, *r1 = NULL;
> > +int index;
> > +
> > +for (t1 = strtok_r(t0, "-", ), index = 0; t1;
> > + t1 = strtok_r(NULL, "-", ), index++) {
> > +
> > +nd_rinfo->type = ND_OPT_ROUTE_INFO;
> > +nd_rinfo->route_lifetime = lifetime;
> > +
> > +switch (index) {
> > +case 0:
> > +if (!strcmp(t1, "HIGH")) {
> > +nd_rinfo->flags = IPV6_ND_RA_OPT_PRF_HIGH;
> > +} else if (!strcmp(t1, "LOW")) {
> > +nd_rinfo->flags = IPV6_ND_RA_OPT_PRF_LOW;
> > +} else {
> > +nd_rinfo->flags = IPV6_ND_RA_OPT_PRF_NORMAL;
> > +}
> > +break;
> > +case 1: {
> > +struct lport_addresses route;
> > +uint8_t plen;
> > +
> > +if (!extract_ip_addresses(t1, )) {
> > +return;
> > +}
> > +if (!route.n_ipv6_addrs) {
> > +destroy_lport_addresses();
> > +return;
> > +}
> > +
> > +nd_rinfo->prefix_len = route.ipv6_addrs->plen;
> > +plen = DIV_ROUND_UP(nd_rinfo->prefix_len, 64);
> > +nd_rinfo->len = 1 + plen;
> > +dp_packet_put(b, _addrs->network, plen * 8);
> > +size += sizeof *nd_rinfo + plen * 8;
> > +
> > +destroy_lport_addresses();
> > +index = 0;
> > +break;
> > +}
> > +default:
> > +
Re: [ovs-dev] [PATCH ovn 1/2] Add support to Default Router Preference (PRF) - RFC 4191
> On Thu, Nov 14, 2019 at 5:10 PM Lorenzo Bianconi
> wrote:
> >
> > Introduce support for Default Router Preference (PRF) in IPv6 Router
> > Advertisement according to RFC 4191
> >
> > Signed-off-by: Lorenzo Bianconi
>
> Thanks Lorenzo for the patches.
>
> The patch LGTM. Just one comment
>
> 1. Can you please change the option name in the OVN NB DB from "prf"
> to "router_preference"
> Using "ipv6_ra_prf" in south db is fine with me.
Hi Numan,
Thx for the review. Fixed in v2.
Regards,
Lorenzo
>
>
> Thanks
> Numan
> > ---
> > controller/pinctrl.c | 20 +---
> > lib/ovn-l7.h | 4
> > northd/ovn-northd.c | 7 +++
> > ovn-nb.xml | 12
> > tests/ovn.at | 13 +
> > 5 files changed, 49 insertions(+), 7 deletions(-)
> >
> > diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> > index a90ee73d6..b736b60ad 100644
> > --- a/controller/pinctrl.c
> > +++ b/controller/pinctrl.c
> > @@ -2263,10 +2263,10 @@ ipv6_ra_update_config(const struct
> > sbrec_port_binding *pb)
> > goto fail;
> > }
> > if (!strcmp(address_mode, "dhcpv6_stateless")) {
> > -config->mo_flags = IPV6_ND_RA_FLAG_OTHER_ADDR_CONFIG;
> > +config->mo_flags |= IPV6_ND_RA_FLAG_OTHER_ADDR_CONFIG;
> > config->la_flags |= IPV6_ND_RA_OPT_PREFIX_AUTONOMOUS;
> > } else if (!strcmp(address_mode, "dhcpv6_stateful")) {
> > -config->mo_flags = IPV6_ND_RA_FLAG_MANAGED_ADDR_CONFIG;
> > +config->mo_flags |= IPV6_ND_RA_FLAG_MANAGED_ADDR_CONFIG;
> > } else if (!strcmp(address_mode, "slaac")) {
> > config->la_flags |= IPV6_ND_RA_OPT_PREFIX_AUTONOMOUS;
> > } else {
> > @@ -2274,6 +2274,13 @@ ipv6_ra_update_config(const struct
> > sbrec_port_binding *pb)
> > goto fail;
> > }
> >
> > +const char *prf = smap_get(>options, "ipv6_ra_prf");
> > +if (!strcmp(prf, "HIGH")) {
> > +config->mo_flags |= IPV6_ND_RA_OPT_PRF_HIGH;
> > +} else if (!strcmp(prf, "LOW")) {
> > +config->mo_flags |= IPV6_ND_RA_OPT_PRF_LOW;
> > +}
> > +
> > const char *prefixes = smap_get(>options, "ipv6_ra_prefixes");
> > if (prefixes && !extract_ip_addresses(prefixes, >prefixes)) {
> > VLOG_WARN("Invalid IPv6 prefixes: %s", prefixes);
> > @@ -2423,10 +2430,17 @@ ipv6_ra_send(struct rconn *swconn, struct
> > ipv6_ra_state *ra)
> >
> > uint64_t packet_stub[128 / 8];
> > struct dp_packet packet;
> > +uint16_t router_lt = IPV6_ND_RA_LIFETIME;
> > +
> > +if (!router_lt) {
> > +/* Reset PRF to MEDIUM if router lifetime is not set */
> > +ra->config->mo_flags &= ~IPV6_ND_RA_OPT_PRF_LOW;
> > +}
> > +
> > dp_packet_use_stub(, packet_stub, sizeof packet_stub);
> > compose_nd_ra(, ra->config->eth_src, ra->config->eth_dst,
> > >config->ipv6_src, >config->ipv6_dst,
> > -255, ra->config->mo_flags, htons(IPV6_ND_RA_LIFETIME), 0, 0,
> > +255, ra->config->mo_flags, htons(router_lt), 0, 0,
> > ra->config->mtu);
> >
> > for (int i = 0; i < ra->config->prefixes.n_ipv6_addrs; i++) {
> > diff --git a/lib/ovn-l7.h b/lib/ovn-l7.h
> > index 5fc370bf5..fd898b0dc 100644
> > --- a/lib/ovn-l7.h
> > +++ b/lib/ovn-l7.h
> > @@ -287,6 +287,10 @@ nd_ra_opts_destroy(struct hmap *nd_ra_opts)
> > #define IPV6_ND_RA_OPT_PREFIX_VALID_LIFETIME0x
> > #define IPV6_ND_RA_OPT_PREFIX_PREFERRED_LIFETIME0x
> >
> > +#define IPV6_ND_RA_OPT_PRF_NORMAL 0x00
> > +#define IPV6_ND_RA_OPT_PRF_HIGH 0x08
> > +#define IPV6_ND_RA_OPT_PRF_LOW 0x18
> > +
> > static inline void
> > nd_ra_opts_init(struct hmap *nd_ra_opts)
> > {
> > diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> > index d6beb9768..a1eaa9071 100644
> > --- a/northd/ovn-northd.c
> > +++ b/northd/ovn-northd.c
> > @@ -6757,6 +6757,13 @@ copy_ra_to_sb(struct ovn_port *op, const char
> > *address_mode)
> >
> > smap_add(, "ipv6_ra_src_eth", op->lrp_networks.ea_s);
> >
> > +const char *prf = smap_get(>nbrp->ipv6_ra_configs, "prf");
> > +if (!prf || (strcmp(prf, "HIGH") && strcmp(prf, "LOW"))) {
> > +smap_add(, "ipv6_ra_prf", "MEDIUM");
> > +} else {
> > +smap_add(, "ipv6_ra_prf", prf);
> > +}
> > +
> > sbrec_port_binding_set_options(op->sb, );
> > smap_destroy();
> > }
> > diff --git a/ovn-nb.xml b/ovn-nb.xml
> > index d8f3237fc..89d23ad7b 100644
> > --- a/ovn-nb.xml
> > +++ b/ovn-nb.xml
> > @@ -1859,6 +1859,18 @@
> >
> >
> >
> > +
> > +Default Router Preference (PRF) indicates whether to prefer this
> > +router over other default routers (RFC 4191).
> > +Possible values are:
> > +
> > +
> > + HIGH: mapped to 0x01 in RA PRF field
> > + MEDIUM: mapped to 0x00 in RA PRF field
> > + LOW: mapped to 0x11 in RA PRF field
> > +
>
[ovs-dev] [PATCH v2 ovn 1/2] Add support to Default Router Preference (PRF) - RFC 4191
Introduce support for Default Router Preference (PRF) in IPv6 Router
Advertisement according to RFC 4191
Signed-off-by: Lorenzo Bianconi
---
controller/pinctrl.c | 20 +---
lib/ovn-l7.h | 4
northd/ovn-northd.c | 8
ovn-nb.xml | 12
tests/ovn.at | 13 +
5 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index 8fc31d38a..48a2baee7 100644
--- a/controller/pinctrl.c
+++ b/controller/pinctrl.c
@@ -2297,10 +2297,10 @@ ipv6_ra_update_config(const struct sbrec_port_binding
*pb)
goto fail;
}
if (!strcmp(address_mode, "dhcpv6_stateless")) {
-config->mo_flags = IPV6_ND_RA_FLAG_OTHER_ADDR_CONFIG;
+config->mo_flags |= IPV6_ND_RA_FLAG_OTHER_ADDR_CONFIG;
config->la_flags |= IPV6_ND_RA_OPT_PREFIX_AUTONOMOUS;
} else if (!strcmp(address_mode, "dhcpv6_stateful")) {
-config->mo_flags = IPV6_ND_RA_FLAG_MANAGED_ADDR_CONFIG;
+config->mo_flags |= IPV6_ND_RA_FLAG_MANAGED_ADDR_CONFIG;
} else if (!strcmp(address_mode, "slaac")) {
config->la_flags |= IPV6_ND_RA_OPT_PREFIX_AUTONOMOUS;
} else {
@@ -2308,6 +2308,13 @@ ipv6_ra_update_config(const struct sbrec_port_binding
*pb)
goto fail;
}
+const char *prf = smap_get(>options, "ipv6_ra_prf");
+if (!strcmp(prf, "HIGH")) {
+config->mo_flags |= IPV6_ND_RA_OPT_PRF_HIGH;
+} else if (!strcmp(prf, "LOW")) {
+config->mo_flags |= IPV6_ND_RA_OPT_PRF_LOW;
+}
+
const char *prefixes = smap_get(>options, "ipv6_ra_prefixes");
if (prefixes && !extract_ip_addresses(prefixes, >prefixes)) {
VLOG_WARN("Invalid IPv6 prefixes: %s", prefixes);
@@ -2457,10 +2464,17 @@ ipv6_ra_send(struct rconn *swconn, struct ipv6_ra_state
*ra)
uint64_t packet_stub[128 / 8];
struct dp_packet packet;
+uint16_t router_lt = IPV6_ND_RA_LIFETIME;
+
+if (!router_lt) {
+/* Reset PRF to MEDIUM if router lifetime is not set */
+ra->config->mo_flags &= ~IPV6_ND_RA_OPT_PRF_LOW;
+}
+
dp_packet_use_stub(, packet_stub, sizeof packet_stub);
compose_nd_ra(, ra->config->eth_src, ra->config->eth_dst,
>config->ipv6_src, >config->ipv6_dst,
-255, ra->config->mo_flags, htons(IPV6_ND_RA_LIFETIME), 0, 0,
+255, ra->config->mo_flags, htons(router_lt), 0, 0,
ra->config->mtu);
for (int i = 0; i < ra->config->prefixes.n_ipv6_addrs; i++) {
diff --git a/lib/ovn-l7.h b/lib/ovn-l7.h
index 5fc370bf5..fd898b0dc 100644
--- a/lib/ovn-l7.h
+++ b/lib/ovn-l7.h
@@ -287,6 +287,10 @@ nd_ra_opts_destroy(struct hmap *nd_ra_opts)
#define IPV6_ND_RA_OPT_PREFIX_VALID_LIFETIME0x
#define IPV6_ND_RA_OPT_PREFIX_PREFERRED_LIFETIME0x
+#define IPV6_ND_RA_OPT_PRF_NORMAL 0x00
+#define IPV6_ND_RA_OPT_PRF_HIGH 0x08
+#define IPV6_ND_RA_OPT_PRF_LOW 0x18
+
static inline void
nd_ra_opts_init(struct hmap *nd_ra_opts)
{
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index d58a59ffd..28628a574 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -7135,6 +7135,14 @@ copy_ra_to_sb(struct ovn_port *op, const char
*address_mode)
smap_add(, "ipv6_ra_src_eth", op->lrp_networks.ea_s);
+const char *prf = smap_get(>nbrp->ipv6_ra_configs,
+ "router_preference");
+if (!prf || (strcmp(prf, "HIGH") && strcmp(prf, "LOW"))) {
+smap_add(, "ipv6_ra_prf", "MEDIUM");
+} else {
+smap_add(, "ipv6_ra_prf", prf);
+}
+
sbrec_port_binding_set_options(op->sb, );
smap_destroy();
}
diff --git a/ovn-nb.xml b/ovn-nb.xml
index 4a93d2f4a..a297728bc 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -1927,6 +1927,18 @@
+
+Default Router Preference (PRF) indicates whether to prefer this
+router over other default routers (RFC 4191).
+Possible values are:
+
+
+ HIGH: mapped to 0x01 in RA PRF field
+ MEDIUM: mapped to 0x00 in RA PRF field
+ LOW: mapped to 0x11 in RA PRF field
+
+
+
The recommended MTU for the link. Default is 0, which means no MTU
Option will be included in RA packet replied by ovn-controller.
diff --git a/tests/ovn.at b/tests/ovn.at
index f54823b5d..d36a7a699 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -11470,23 +11470,28 @@ ra_test 05dc 00 0 0 c0 40
aef0
ovn-nbctl --wait=hv set Logical_Router_port ro-sw networks='aef0\:\:1/64
fd0f\:\:1/48'
ra_test 05dc 00 0 0 c0 40 aef0 30
fd0f
+# Test PRF for default gw
+ovn-nbctl --wait=hv set Logical_Router_port ro-sw
ipv6_ra_configs:router_preference="LOW"
+ra_test 05dc 18 0 0 c0 40 aef0 30
fd0f
+
# Now
[ovs-dev] [PATCH v2 ovn 2/2] Add support for Route Info Option in RA - RFC 4191
Introduce support for Route Info Option sent in Router
Advertisement according to RFC 4191. Route Info Option are
configured providing route_info in ipv6_ra_configs column of
Logical_Router_Port table. route_info is a comma separated string
where each field provides PRF and prefix for a given route
(e.g: HIGH-aef1::11/48,LOW-aef2::11/96)
Signed-off-by: Lorenzo Bianconi
---
controller/pinctrl.c | 80
lib/ovn-l7.h | 12 +++
northd/ovn-northd.c | 6
ovn-nb.xml | 14
tests/ovn.at | 32 --
5 files changed, 133 insertions(+), 11 deletions(-)
diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index 48a2baee7..c886b21d9 100644
--- a/controller/pinctrl.c
+++ b/controller/pinctrl.c
@@ -2229,6 +2229,7 @@ struct ipv6_ra_config {
struct in6_addr rdnss;
bool has_rdnss;
struct ds dnssl;
+struct ds route_info;
};
struct ipv6_ra_state {
@@ -2251,6 +2252,7 @@ ipv6_ra_config_delete(struct ipv6_ra_config *config)
if (config) {
destroy_lport_addresses(>prefixes);
ds_destroy(>dnssl);
+ds_destroy(>route_info);
free(config);
}
}
@@ -2290,6 +2292,7 @@ ipv6_ra_update_config(const struct sbrec_port_binding *pb)
config->mtu = smap_get_int(>options, "ipv6_ra_mtu", ND_MTU_DEFAULT);
config->la_flags = IPV6_ND_RA_OPT_PREFIX_ON_LINK;
ds_init(>dnssl);
+ds_init(>route_info);
const char *address_mode = smap_get(>options, "ipv6_ra_address_mode");
if (!address_mode) {
@@ -2347,6 +2350,11 @@ ipv6_ra_update_config(const struct sbrec_port_binding
*pb)
ds_put_buffer(>dnssl, dnssl, strlen(dnssl));
}
+const char *route_info = smap_get(>options, "ipv6_ra_route_info");
+if (route_info) {
+ds_put_buffer(>route_info, route_info, strlen(route_info));
+}
+
return config;
fail:
@@ -2454,6 +2462,74 @@ packet_put_ra_dnssl_opt(struct dp_packet *b, ovs_be32
lifetime,
prev_l4_size + size));
}
+static void
+packet_put_ra_route_info_opt(struct dp_packet *b, ovs_be32 lifetime,
+ char *route_list)
+{
+size_t prev_l4_size = dp_packet_l4_size(b);
+struct ip6_hdr *nh = dp_packet_l3(b);
+char *t0, *r0 = NULL;
+size_t size = 0;
+
+for (t0 = strtok_r(route_list, ",", ); t0;
+ t0 = strtok_r(NULL, ",", )) {
+struct ovs_nd_route_info nd_rinfo;
+char *t1, *r1 = NULL;
+int index;
+
+for (t1 = strtok_r(t0, "-", ), index = 0; t1;
+ t1 = strtok_r(NULL, "-", ), index++) {
+
+nd_rinfo.type = ND_OPT_ROUTE_INFO;
+nd_rinfo.route_lifetime = lifetime;
+
+switch (index) {
+case 0:
+if (!strcmp(t1, "HIGH")) {
+nd_rinfo.flags = IPV6_ND_RA_OPT_PRF_HIGH;
+} else if (!strcmp(t1, "LOW")) {
+nd_rinfo.flags = IPV6_ND_RA_OPT_PRF_LOW;
+} else {
+nd_rinfo.flags = IPV6_ND_RA_OPT_PRF_NORMAL;
+}
+break;
+case 1: {
+struct lport_addresses route;
+uint8_t plen;
+
+if (!extract_ip_addresses(t1, )) {
+return;
+}
+if (!route.n_ipv6_addrs) {
+destroy_lport_addresses();
+return;
+}
+
+nd_rinfo.prefix_len = route.ipv6_addrs->plen;
+plen = DIV_ROUND_UP(nd_rinfo.prefix_len, 64);
+nd_rinfo.len = 1 + plen;
+dp_packet_put(b, _rinfo, sizeof(struct ovs_nd_route_info));
+dp_packet_put(b, _addrs->network, plen * 8);
+size += sizeof(struct ovs_nd_route_info) + plen * 8;
+
+destroy_lport_addresses();
+index = 0;
+break;
+}
+default:
+return;
+}
+}
+}
+
+nh->ip6_plen = htons(prev_l4_size + size);
+struct ovs_ra_msg *ra = dp_packet_l4(b);
+ra->icmph.icmp6_cksum = 0;
+uint32_t icmp_csum = packet_csum_pseudoheader6(dp_packet_l3(b));
+ra->icmph.icmp6_cksum = csum_finish(csum_continue(icmp_csum, ra,
+ prev_l4_size + size));
+}
+
/* Called with in the pinctrl_handler thread context. */
static long long int
ipv6_ra_send(struct rconn *swconn, struct ipv6_ra_state *ra)
@@ -2493,6 +2569,10 @@ ipv6_ra_send(struct rconn *swconn, struct ipv6_ra_state
*ra)
packet_put_ra_dnssl_opt(, htonl(0x),
ra->config->dnssl.string);
}
+if (ra->config->route_info.length) {
+packet_put_ra_route_info_opt(, htonl(0x),
+ ra->config->route_info.string);
+}
uint64_t ofpacts_stub[4096 / 8];
[ovs-dev] [PATCH v2 ovn 0/2] Add support for PRF and Route Info Option in RA (RFC 4191)
Changes since v1: - rename prf in router_preference in OVN NB DB - allocate space for ovs_nd_route_info in ovs packet after data validation Lorenzo Bianconi (2): Add support to Default Router Preference (PRF) - RFC 4191 Add support for Route Info Option in RA - RFC 4191 controller/pinctrl.c | 100 +-- lib/ovn-l7.h | 16 +++ northd/ovn-northd.c | 14 ++ ovn-nb.xml | 26 +++ tests/ovn.at | 35 ++- 5 files changed, 178 insertions(+), 13 deletions(-) -- 2.21.0 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Weekly build of dpdk-latest branch on TravisCI.
Hi. As discussed on OVS-DPDK public meeting I enabled weekly cron job on TravisCI for a dpdk-latest branch. For now it will happen on Thursdays since I enabled it today, but we could change the day if needed. Suggestions are welcome. I'm personally thinking about moving it to Saturdays to avoid stealing resources from the regular push-triggered builds that are unlikely on weekends. Small rationale: * These weekly builds should allow us to catch incompatibilities with new DPDK patches since dpdk-latest always uses the most recent DPDK sources. * Might allow DPDK community to run their CI using this branch since it should be in a better shape. Today's build: https://travis-ci.org/openvswitch/ovs/builds/618137712 Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] OVS-DPDK public meeting
Next meeting Jan 8th 1700 UTC November 27th minutes Attendees: Aaron, David, Oz, Ilya, Johann, Simon, Roni, Ian, Thomas, Kevin. - DPDK 19.11 Release -- OVS validation complete to date -- Ian presented tests performed with OVS and Intel NICs -- Summary was sent to dpdk-dev http://inbox.dpdk.org/dev/3b7e3b9b-117c-d23a-c8e3-43b94eb87...@intel.com/ -- Request from Ian for other device vendors test with dpdk-latest branch, or when patch for master branch ready -- Known Issues --- Clear Memory Layout Flags Ilya submitted a fix for this There is some further discussion about the offload flags but it can happen later in the context of dpdkr deprecation --- Hotplug support for IGB_UIO The scheme for picking PA/VA mode in DPDK has evolved since 18.11 The change in behavior (19.08): https://git.dpdk.org/dpdk/commit?id=bbe29a9bd7ab6feab9a52051c32092a94ee886eb The selection process is explained here http://doc.dpdk.org/guides/prog_guide/env_abstraction_layer.html#iova-mode-detection There can be a pattern now where adding an igb_uio bound device with hotplug will require '--iova-mode=pa' eal param to work as before dpdk-extra ovsdb entry can be used for this with OVS General discussion was that vfio is preferred option and that igb_uio is not suitable/supported in some environments Will need some addition documentation in OVS - DPDK Stable Releases -- 18.11.5 --- There is patches to update master/2.12/2.11 branches --- 18.11.5 addresses https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14818 --- OVS using dpdk vhost and untrusted guest should update --- Updates for 17.11 on older branches will come later - OVS Con 2019 -- Full house! hopefully live streaming will be available -- Videos will be recorded - rte_flow full hw offload through DPDK (Oz) -- Patches are submitted for initial features -- Some feedbacks from Ilya to address -- Hoping they can be merged in time for 2.13 -- Later features can be vxlan, connection tracking etc. -- Will present on this in ovs conf dpdk-master branch - Small discussion on effectiveness of it - Some suggestions -- Enable periodic travis build from it -- More regular rebases from OVS master -- Some earlier usage testing (e.g. with DPDK .08 release) Next meeting date - Was scheduled for 25th December - Pushing to Jan 8th On 25/07/2017 14:25, Kevin Traynor wrote: > Hi All, > > The OVS-DPDK public meetings have moved to Wednesday's at the same time. > Everyone is welcome, it's a chance to share status/plans etc. > > It's scheduled for every 2 weeks starting 26th July. Meeting time is > currently @ 4pm UTC. > > You can connect through Bluejeans or through dial in: > > https://bluejeans.com/139318596 > > US: +1.408.740.7256 > UK: +44.203.608.5256 > Germany: +49.32.221.091256 > Ireland: +353.1.697.1256 > Other numbers at https://www.bluejeans.com/numbers > Meeting ID: 139318596 > > thanks, > Kevin. > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn 2/2] Add support for Route Info Option in RA - RFC 4191
On Thu, Nov 14, 2019 at 5:10 PM Lorenzo Bianconi
wrote:
>
> Introduce support for Route Info Option sent in Router
> Advertisement according to RFC 4191. Route Info Option are
> configured providing route_info in ipv6_ra_configs column of
> Logical_Router_Port table. route_info is a comma separated string
> where each field provides PRF and prefix for a given route
> (e.g: HIGH-aef1::11/48,LOW-aef2::11/96)
>
> Signed-off-by: Lorenzo Bianconi
> ---
> controller/pinctrl.c | 80
> lib/ovn-l7.h | 12 +++
> northd/ovn-northd.c | 6
> ovn-nb.xml | 14
> tests/ovn.at | 32 --
> 5 files changed, 133 insertions(+), 11 deletions(-)
>
> diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> index b736b60ad..51c7f8a36 100644
> --- a/controller/pinctrl.c
> +++ b/controller/pinctrl.c
> @@ -2195,6 +2195,7 @@ struct ipv6_ra_config {
> struct in6_addr rdnss;
> bool has_rdnss;
> struct ds dnssl;
> +struct ds route_info;
> };
>
> struct ipv6_ra_state {
> @@ -2217,6 +2218,7 @@ ipv6_ra_config_delete(struct ipv6_ra_config *config)
> if (config) {
> destroy_lport_addresses(>prefixes);
> ds_destroy(>dnssl);
> +ds_destroy(>route_info);
> free(config);
> }
> }
> @@ -2256,6 +2258,7 @@ ipv6_ra_update_config(const struct sbrec_port_binding
> *pb)
> config->mtu = smap_get_int(>options, "ipv6_ra_mtu", ND_MTU_DEFAULT);
> config->la_flags = IPV6_ND_RA_OPT_PREFIX_ON_LINK;
> ds_init(>dnssl);
> +ds_init(>route_info);
>
> const char *address_mode = smap_get(>options,
> "ipv6_ra_address_mode");
> if (!address_mode) {
> @@ -2313,6 +2316,11 @@ ipv6_ra_update_config(const struct sbrec_port_binding
> *pb)
> ds_put_buffer(>dnssl, dnssl, strlen(dnssl));
> }
>
> +const char *route_info = smap_get(>options, "ipv6_ra_route_info");
> +if (route_info) {
> +ds_put_buffer(>route_info, route_info, strlen(route_info));
> +}
> +
> return config;
>
> fail:
> @@ -2420,6 +2428,74 @@ packet_put_ra_dnssl_opt(struct dp_packet *b, ovs_be32
> lifetime,
>prev_l4_size + size));
> }
>
> +static void
> +packet_put_ra_route_info_opt(struct dp_packet *b, ovs_be32 lifetime,
> + char *route_list)
> +{
> +size_t prev_l4_size = dp_packet_l4_size(b);
> +struct ip6_hdr *nh = dp_packet_l3(b);
> +char *t0, *r0 = NULL;
> +size_t size = 0;
> +
> +for (t0 = strtok_r(route_list, ",", ); t0;
> + t0 = strtok_r(NULL, ",", )) {
> +struct ovs_nd_route_info *nd_rinfo =
> +dp_packet_put_uninit(b, sizeof *nd_rinfo);
Let's say user has configured this option as "HIGH-foo". In this case,
dp_packet_put_uninit will reserve
sizeof *nd_rinfo bytes in the packet, but since validation fails, this
function returns without adding route info to
the packet and the packet is sent with invalid data.
I think it's better to call dp_packet_put after the validation.
Thanks
Numan
> +char *t1, *r1 = NULL;
> +int index;
> +
> +for (t1 = strtok_r(t0, "-", ), index = 0; t1;
> + t1 = strtok_r(NULL, "-", ), index++) {
> +
> +nd_rinfo->type = ND_OPT_ROUTE_INFO;
> +nd_rinfo->route_lifetime = lifetime;
> +
> +switch (index) {
> +case 0:
> +if (!strcmp(t1, "HIGH")) {
> +nd_rinfo->flags = IPV6_ND_RA_OPT_PRF_HIGH;
> +} else if (!strcmp(t1, "LOW")) {
> +nd_rinfo->flags = IPV6_ND_RA_OPT_PRF_LOW;
> +} else {
> +nd_rinfo->flags = IPV6_ND_RA_OPT_PRF_NORMAL;
> +}
> +break;
> +case 1: {
> +struct lport_addresses route;
> +uint8_t plen;
> +
> +if (!extract_ip_addresses(t1, )) {
> +return;
> +}
> +if (!route.n_ipv6_addrs) {
> +destroy_lport_addresses();
> +return;
> +}
> +
> +nd_rinfo->prefix_len = route.ipv6_addrs->plen;
> +plen = DIV_ROUND_UP(nd_rinfo->prefix_len, 64);
> +nd_rinfo->len = 1 + plen;
> +dp_packet_put(b, _addrs->network, plen * 8);
> +size += sizeof *nd_rinfo + plen * 8;
> +
> +destroy_lport_addresses();
> +index = 0;
> +break;
> +}
> +default:
> +return;
> +}
> +}
> +}
> +
> +nh->ip6_plen = htons(prev_l4_size + size);
> +struct ovs_ra_msg *ra = dp_packet_l4(b);
> +ra->icmph.icmp6_cksum = 0;
> +uint32_t icmp_csum = packet_csum_pseudoheader6(dp_packet_l3(b));
> +ra->icmph.icmp6_cksum = csum_finish(csum_continue(icmp_csum, ra,
> +
Re: [ovs-dev] [PATCH ovn 1/2] Add support to Default Router Preference (PRF) - RFC 4191
On Thu, Nov 14, 2019 at 5:10 PM Lorenzo Bianconi
wrote:
>
> Introduce support for Default Router Preference (PRF) in IPv6 Router
> Advertisement according to RFC 4191
>
> Signed-off-by: Lorenzo Bianconi
Thanks Lorenzo for the patches.
The patch LGTM. Just one comment
1. Can you please change the option name in the OVN NB DB from "prf"
to "router_preference"
Using "ipv6_ra_prf" in south db is fine with me.
Thanks
Numan
> ---
> controller/pinctrl.c | 20 +---
> lib/ovn-l7.h | 4
> northd/ovn-northd.c | 7 +++
> ovn-nb.xml | 12
> tests/ovn.at | 13 +
> 5 files changed, 49 insertions(+), 7 deletions(-)
>
> diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> index a90ee73d6..b736b60ad 100644
> --- a/controller/pinctrl.c
> +++ b/controller/pinctrl.c
> @@ -2263,10 +2263,10 @@ ipv6_ra_update_config(const struct sbrec_port_binding
> *pb)
> goto fail;
> }
> if (!strcmp(address_mode, "dhcpv6_stateless")) {
> -config->mo_flags = IPV6_ND_RA_FLAG_OTHER_ADDR_CONFIG;
> +config->mo_flags |= IPV6_ND_RA_FLAG_OTHER_ADDR_CONFIG;
> config->la_flags |= IPV6_ND_RA_OPT_PREFIX_AUTONOMOUS;
> } else if (!strcmp(address_mode, "dhcpv6_stateful")) {
> -config->mo_flags = IPV6_ND_RA_FLAG_MANAGED_ADDR_CONFIG;
> +config->mo_flags |= IPV6_ND_RA_FLAG_MANAGED_ADDR_CONFIG;
> } else if (!strcmp(address_mode, "slaac")) {
> config->la_flags |= IPV6_ND_RA_OPT_PREFIX_AUTONOMOUS;
> } else {
> @@ -2274,6 +2274,13 @@ ipv6_ra_update_config(const struct sbrec_port_binding
> *pb)
> goto fail;
> }
>
> +const char *prf = smap_get(>options, "ipv6_ra_prf");
> +if (!strcmp(prf, "HIGH")) {
> +config->mo_flags |= IPV6_ND_RA_OPT_PRF_HIGH;
> +} else if (!strcmp(prf, "LOW")) {
> +config->mo_flags |= IPV6_ND_RA_OPT_PRF_LOW;
> +}
> +
> const char *prefixes = smap_get(>options, "ipv6_ra_prefixes");
> if (prefixes && !extract_ip_addresses(prefixes, >prefixes)) {
> VLOG_WARN("Invalid IPv6 prefixes: %s", prefixes);
> @@ -2423,10 +2430,17 @@ ipv6_ra_send(struct rconn *swconn, struct
> ipv6_ra_state *ra)
>
> uint64_t packet_stub[128 / 8];
> struct dp_packet packet;
> +uint16_t router_lt = IPV6_ND_RA_LIFETIME;
> +
> +if (!router_lt) {
> +/* Reset PRF to MEDIUM if router lifetime is not set */
> +ra->config->mo_flags &= ~IPV6_ND_RA_OPT_PRF_LOW;
> +}
> +
> dp_packet_use_stub(, packet_stub, sizeof packet_stub);
> compose_nd_ra(, ra->config->eth_src, ra->config->eth_dst,
> >config->ipv6_src, >config->ipv6_dst,
> -255, ra->config->mo_flags, htons(IPV6_ND_RA_LIFETIME), 0, 0,
> +255, ra->config->mo_flags, htons(router_lt), 0, 0,
> ra->config->mtu);
>
> for (int i = 0; i < ra->config->prefixes.n_ipv6_addrs; i++) {
> diff --git a/lib/ovn-l7.h b/lib/ovn-l7.h
> index 5fc370bf5..fd898b0dc 100644
> --- a/lib/ovn-l7.h
> +++ b/lib/ovn-l7.h
> @@ -287,6 +287,10 @@ nd_ra_opts_destroy(struct hmap *nd_ra_opts)
> #define IPV6_ND_RA_OPT_PREFIX_VALID_LIFETIME0x
> #define IPV6_ND_RA_OPT_PREFIX_PREFERRED_LIFETIME0x
>
> +#define IPV6_ND_RA_OPT_PRF_NORMAL 0x00
> +#define IPV6_ND_RA_OPT_PRF_HIGH 0x08
> +#define IPV6_ND_RA_OPT_PRF_LOW 0x18
> +
> static inline void
> nd_ra_opts_init(struct hmap *nd_ra_opts)
> {
> diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> index d6beb9768..a1eaa9071 100644
> --- a/northd/ovn-northd.c
> +++ b/northd/ovn-northd.c
> @@ -6757,6 +6757,13 @@ copy_ra_to_sb(struct ovn_port *op, const char
> *address_mode)
>
> smap_add(, "ipv6_ra_src_eth", op->lrp_networks.ea_s);
>
> +const char *prf = smap_get(>nbrp->ipv6_ra_configs, "prf");
> +if (!prf || (strcmp(prf, "HIGH") && strcmp(prf, "LOW"))) {
> +smap_add(, "ipv6_ra_prf", "MEDIUM");
> +} else {
> +smap_add(, "ipv6_ra_prf", prf);
> +}
> +
> sbrec_port_binding_set_options(op->sb, );
> smap_destroy();
> }
> diff --git a/ovn-nb.xml b/ovn-nb.xml
> index d8f3237fc..89d23ad7b 100644
> --- a/ovn-nb.xml
> +++ b/ovn-nb.xml
> @@ -1859,6 +1859,18 @@
>
>
>
> +
> +Default Router Preference (PRF) indicates whether to prefer this
> +router over other default routers (RFC 4191).
> +Possible values are:
> +
> +
> + HIGH: mapped to 0x01 in RA PRF field
> + MEDIUM: mapped to 0x00 in RA PRF field
> + LOW: mapped to 0x11 in RA PRF field
> +
> +
> +
>
> The recommended MTU for the link. Default is 0, which means no MTU
> Option will be included in RA packet replied by ovn-controller.
> diff --git a/tests/ovn.at b/tests/ovn.at
> index 4a10a11e9..85d539c78 100644
> --- a/tests/ovn.at
> +++ b/tests/ovn.at
> @@ -11504,23 +11504,28 @@
Re: [ovs-dev] [PATCH v2 ovn 1/2] controller: add ipv6 prefix delegation state machine
On Thu, Nov 28, 2019 at 3:53 PM Numan Siddique wrote:
>
> On Tue, Nov 26, 2019 at 5:21 PM Lorenzo Bianconi
> wrote:
> >
> > Introduce IPv6 Prefix delegation state machine according to RFC 3633
> > https://tools.ietf.org/html/rfc3633.
> > Add handle_dhcpv6_reply controller action to parse advertise/reply from
> > IPv6 delegation server. Advertise/reply are parsed running respectively:
> > - pinctrl_parse_dhcv6_advt
> > - pinctrl_parse_dhcv6_reply
> > The IPv6 requesting router starts sending dhcpv6 solicit through the logical
> > router port marked with ipv6_prefix_delegation set to true.
> > An IPv6 prefix will be requested for each logical router port marked
> > with "prefix" set to true in option column of logical router port table.
> > Save IPv6 prefix received by IPv6 delegation router in the options column of
> > SB port binding table in order to be reused by Router Advertisement
> > framework
> > run by ovn logical router pipeline.
> > IPv6 Prefix delegation state machine is enabled on Gateway Router or on
> > a Gateway Router Port
> >
> > Signed-off-by: Lorenzo Bianconi
>
> Thanks Lorenzo for the patches.
>
> The patch LGTM. A couple of comments
>
> 1. Can you please change the option name in the OVN NB DB from "prf"
> to "router_preference"
> Using "ipv6_ra_prf" in south db is fine with me.
>
> 2. Can you please enhance the IPv6 RA test case and this option as well.
>
> Thanks
> Numan
Oops. Please ignore this. I meant to reply to your patches related to RFC 4191.
Thanks
Numan
>
> > ---
> > controller/pinctrl.c | 607 ++
> > include/ovn/actions.h | 8 +-
> > lib/actions.c | 22 ++
> > lib/ovn-l7.h | 19 ++
> > ovn-sb.xml| 8 +
> > tests/ovn.at | 6 +
> > utilities/ovn-trace.c | 3 +
> > 7 files changed, 672 insertions(+), 1 deletion(-)
> >
> > diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> > index 8fc31d38a..a51fdaaca 100644
> > --- a/controller/pinctrl.c
> > +++ b/controller/pinctrl.c
> > @@ -270,6 +270,19 @@ static void pinctrl_ip_mcast_handle_igmp(
> > const struct match *md,
> > struct ofpbuf *userdata);
> >
> > +static void init_ipv6_prefixd(void);
> > +static void destroy_ipv6_prefixd(void);
> > +static void ipv6_prefixd_wait(long long int timeout);
> > +static void
> > +prepare_ipv6_prefix_req(struct ovsdb_idl_index
> > *sbrec_port_binding_by_datapath,
> > +struct ovsdb_idl_index *sbrec_port_binding_by_name,
> > +const struct hmap *local_datapaths,
> > +const struct sbrec_chassis *chassis,
> > +const struct sset *active_tunnels)
> > +OVS_REQUIRES(pinctrl_mutex);
> > +static void
> > +send_ipv6_prefix_msg(struct rconn *swconn, long long int
> > *send_prefixd_time)
> > +OVS_REQUIRES(pinctrl_mutex);
> > static bool may_inject_pkts(void);
> >
> > static void init_put_vport_bindings(void);
> > @@ -457,6 +470,7 @@ pinctrl_init(void)
> > init_put_mac_bindings();
> > init_send_garps_rarps();
> > init_ipv6_ras();
> > +init_ipv6_prefixd();
> > init_buffered_packets_map();
> > init_event_table();
> > ip_mcast_snoop_init();
> > @@ -544,6 +558,57 @@ set_actions_and_enqueue_msg(struct rconn *swconn,
> > ofpbuf_uninit();
> > }
> >
> > +static struct shash ipv6_prefixd;
> > +
> > +enum {
> > +PREFIX_SOLICIT,
> > +PREFIX_PENDING,
> > +PREFIX_DONE,
> > +};
> > +
> > +struct ipv6_prefixd_state {
> > +long long int next_announce;
> > +struct in6_addr ipv6_addr;
> > +struct eth_addr ea;
> > +struct eth_addr cmac;
> > +int64_t port_key;
> > +int64_t metadata;
> > +struct in6_addr prefix;
> > +unsigned plife_time;
> > +unsigned vlife_time;
> > +unsigned aid;
> > +unsigned t1;
> > +unsigned t2;
> > +int8_t plen;
> > +int state;
> > +};
> > +
> > +static void
> > +init_ipv6_prefixd(void)
> > +{
> > +shash_init(_prefixd);
> > +}
> > +
> > +static void
> > +ipv6_prefixd_delete(struct ipv6_prefixd_state *pfd)
> > +{
> > +if (pfd) {
> > +free(pfd);
> > +}
> > +}
> > +
> > +static void
> > +destroy_ipv6_prefixd(void)
> > +{
> > +struct shash_node *iter, *next;
> > +SHASH_FOR_EACH_SAFE (iter, next, _prefixd) {
> > +struct ipv6_prefixd_state *pfd = iter->data;
> > +ipv6_prefixd_delete(pfd);
> > +shash_delete(_prefixd, iter);
> > +}
> > +shash_destroy(_prefixd);
> > +}
> > +
> > struct buffer_info {
> > struct ofpbuf ofpacts;
> > struct dp_packet *p;
> > @@ -967,6 +1032,254 @@ pinctrl_handle_tcp_reset(struct rconn *swconn, const
> > struct flow *ip_flow,
> > dp_packet_uninit();
> > }
> >
> > +static void
> > +pinctrl_parse_dhcv6_advt(struct rconn *swconn, const struct flow *ip_flow,
> > + struct dp_packet *pkt_in, const struct match *md,
> > + struct ofpbuf
Re: [ovs-dev] [PATCH v2 ovn 1/2] controller: add ipv6 prefix delegation state machine
On Tue, Nov 26, 2019 at 5:21 PM Lorenzo Bianconi
wrote:
>
> Introduce IPv6 Prefix delegation state machine according to RFC 3633
> https://tools.ietf.org/html/rfc3633.
> Add handle_dhcpv6_reply controller action to parse advertise/reply from
> IPv6 delegation server. Advertise/reply are parsed running respectively:
> - pinctrl_parse_dhcv6_advt
> - pinctrl_parse_dhcv6_reply
> The IPv6 requesting router starts sending dhcpv6 solicit through the logical
> router port marked with ipv6_prefix_delegation set to true.
> An IPv6 prefix will be requested for each logical router port marked
> with "prefix" set to true in option column of logical router port table.
> Save IPv6 prefix received by IPv6 delegation router in the options column of
> SB port binding table in order to be reused by Router Advertisement framework
> run by ovn logical router pipeline.
> IPv6 Prefix delegation state machine is enabled on Gateway Router or on
> a Gateway Router Port
>
> Signed-off-by: Lorenzo Bianconi
Thanks Lorenzo for the patches.
The patch LGTM. A couple of comments
1. Can you please change the option name in the OVN NB DB from "prf"
to "router_preference"
Using "ipv6_ra_prf" in south db is fine with me.
2. Can you please enhance the IPv6 RA test case and this option as well.
Thanks
Numan
> ---
> controller/pinctrl.c | 607 ++
> include/ovn/actions.h | 8 +-
> lib/actions.c | 22 ++
> lib/ovn-l7.h | 19 ++
> ovn-sb.xml| 8 +
> tests/ovn.at | 6 +
> utilities/ovn-trace.c | 3 +
> 7 files changed, 672 insertions(+), 1 deletion(-)
>
> diff --git a/controller/pinctrl.c b/controller/pinctrl.c
> index 8fc31d38a..a51fdaaca 100644
> --- a/controller/pinctrl.c
> +++ b/controller/pinctrl.c
> @@ -270,6 +270,19 @@ static void pinctrl_ip_mcast_handle_igmp(
> const struct match *md,
> struct ofpbuf *userdata);
>
> +static void init_ipv6_prefixd(void);
> +static void destroy_ipv6_prefixd(void);
> +static void ipv6_prefixd_wait(long long int timeout);
> +static void
> +prepare_ipv6_prefix_req(struct ovsdb_idl_index
> *sbrec_port_binding_by_datapath,
> +struct ovsdb_idl_index *sbrec_port_binding_by_name,
> +const struct hmap *local_datapaths,
> +const struct sbrec_chassis *chassis,
> +const struct sset *active_tunnels)
> +OVS_REQUIRES(pinctrl_mutex);
> +static void
> +send_ipv6_prefix_msg(struct rconn *swconn, long long int *send_prefixd_time)
> +OVS_REQUIRES(pinctrl_mutex);
> static bool may_inject_pkts(void);
>
> static void init_put_vport_bindings(void);
> @@ -457,6 +470,7 @@ pinctrl_init(void)
> init_put_mac_bindings();
> init_send_garps_rarps();
> init_ipv6_ras();
> +init_ipv6_prefixd();
> init_buffered_packets_map();
> init_event_table();
> ip_mcast_snoop_init();
> @@ -544,6 +558,57 @@ set_actions_and_enqueue_msg(struct rconn *swconn,
> ofpbuf_uninit();
> }
>
> +static struct shash ipv6_prefixd;
> +
> +enum {
> +PREFIX_SOLICIT,
> +PREFIX_PENDING,
> +PREFIX_DONE,
> +};
> +
> +struct ipv6_prefixd_state {
> +long long int next_announce;
> +struct in6_addr ipv6_addr;
> +struct eth_addr ea;
> +struct eth_addr cmac;
> +int64_t port_key;
> +int64_t metadata;
> +struct in6_addr prefix;
> +unsigned plife_time;
> +unsigned vlife_time;
> +unsigned aid;
> +unsigned t1;
> +unsigned t2;
> +int8_t plen;
> +int state;
> +};
> +
> +static void
> +init_ipv6_prefixd(void)
> +{
> +shash_init(_prefixd);
> +}
> +
> +static void
> +ipv6_prefixd_delete(struct ipv6_prefixd_state *pfd)
> +{
> +if (pfd) {
> +free(pfd);
> +}
> +}
> +
> +static void
> +destroy_ipv6_prefixd(void)
> +{
> +struct shash_node *iter, *next;
> +SHASH_FOR_EACH_SAFE (iter, next, _prefixd) {
> +struct ipv6_prefixd_state *pfd = iter->data;
> +ipv6_prefixd_delete(pfd);
> +shash_delete(_prefixd, iter);
> +}
> +shash_destroy(_prefixd);
> +}
> +
> struct buffer_info {
> struct ofpbuf ofpacts;
> struct dp_packet *p;
> @@ -967,6 +1032,254 @@ pinctrl_handle_tcp_reset(struct rconn *swconn, const
> struct flow *ip_flow,
> dp_packet_uninit();
> }
>
> +static void
> +pinctrl_parse_dhcv6_advt(struct rconn *swconn, const struct flow *ip_flow,
> + struct dp_packet *pkt_in, const struct match *md,
> + struct ofpbuf *userdata)
> +{
> +struct udp_header *udp_in = dp_packet_l4(pkt_in);
> +unsigned char *in_dhcpv6_data = (unsigned char *)(udp_in + 1);
> +size_t dlen = MIN(ntohs(udp_in->udp_len), dp_packet_l4_size(pkt_in));
> +uint8_t *data, *end = (uint8_t *)udp_in + dlen;
> +int len = 0;
> +
> +data = xmalloc(dlen);
> +if (!data) {
> +return;
> +}
> +
> +in_dhcpv6_data += 4;
> +
> +while (in_dhcpv6_data < end) {
> +
Re: [ovs-dev] [PATCH net 1/2] openvswitch: support asymmetric conntrack
Le 18/11/2019 à 22:19, Aaron Conole a écrit :
> Nicolas Dichtel writes:
>
>> Le 08/11/2019 à 22:07, Aaron Conole a écrit :
>>> The openvswitch module shares a common conntrack and NAT infrastructure
>>> exposed via netfilter. It's possible that a packet needs both SNAT and
>>> DNAT manipulation, due to e.g. tuple collision. Netfilter can support
>>> this because it runs through the NAT table twice - once on ingress and
>>> again after egress. The openvswitch module doesn't have such capability.
>>>
>>> Like netfilter hook infrastructure, we should run through NAT twice to
>>> keep the symmetry.
>>>
>>> Fixes: 05752523e565 ("openvswitch: Interface with NAT.")
>>> Signed-off-by: Aaron Conole
>> In this case, ovs_ct_find_existing() won't be able to find the
>> conntrack, right?
>
> vswitchd normally won't allow both actions to get programmed. Even the
> kernel module won't allow it, so this really will only happen when the
> connection gets established via the nf_hook path, and then needs to be
> processed via openvswitch. In those cases, the tuple lookup should be
> correct, because the nf_nat table should contain the correct tuple data,
> and the skbuff should have the correct tuples in the packet data to
> begin with.
>
>> Inverting the tuple to find the conntrack doesn't work anymore with double
>> NAT.
>> Am I wrong?
>
> I think since the packet was double-NAT on the way out (via nf_hook
> path), then the incoming reply will have the correct NAT tuples and the
> lookup will happen just fine. Just that during processing, both
> transformations aren't applied.
Ok, I didn't look deeply, thank you for the explanation.
Regards,
Nicolas
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [OVN][RAFT] Follower refusing new entries from leader
Hi,Han Another question. NO COMPACT. If restart a follower , leader sender some entries during the break time, when it has started, if it also happend to this problem? What is the difference between simply restart and COMPACT with restart ? Thanks, Yun 在 2019-11-28 13:58:36，"taoyunupt" 写道： Hi,Han Thanks for your reply. I think maybe we can disconnect the failed follower from the Haproxy then synchronize the date, after all completed, reconnect it to Haproxy again. But I do not know how to synchronize actually. It is just my naive idea. Do you have some suggestion about how to fix this problem. If not very completed, I wii have a try. Thanks Yun 在 2019-11-28 11:47:55，"Han Zhou" 写道： On Wed, Nov 27, 2019 at 7:22 PM taoyunupt wrote: > > Hi, > My OVN cluster has 3 OVN-northd nodes, They are proxied by Haproxy with a > VIP. Recently, I restart OVN cluster frequently. One of the members report > the logs below. > After read the code and paper of RAFT, it seems normal process ,If the > follower does not find an entry in its log with the same index and term, then > it refuses the new entries. > I think it's reasonable to refuse. But, as we could not control Haproxy > or some proxy maybe, so it will happen error when an session assignate to the > failed follower. > > Does have some means or ways to solve this problem. Maybe we can kick off > the failed follower or disconnect it from the haproxy then synchronize the > date ? Hope to hear your suggestion. > > > 2019-11-27T14:22:17.060Z|00240|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > 2019-11-27T14:22:17.064Z|00241|raft|ERR|Dropped 34 log messages in last 12 > seconds (most recently, 0 seconds ago) due to excessive rate > 2019-11-27T14:22:17.064Z|00242|raft|ERR|internal error: deferred append_reply > message completed but not ready to send because message index 14890 is past > last synced index 0: a2b2 append_reply "mismatch past end of log": term=1103 > log_end=14891 result="inconsistency" > 2019-11-27T14:22:17.402Z|00243|raft|INFO|rejecting append_request because > previous entry 1103,50975 not in local log (mismatch past end of log) > > > [root@ovn1 ~]# ovs-appctl -t /var/run/openvswitch/ovnsb_db.ctl > cluster/status OVN_Southbound > a2b2 > Name: OVN_Southbound > Cluster ID: 4c54 (4c546513-77e3-4602-b211-2e200014ad79) > Server ID: a2b2 (a2b2a9c5-cf58-4724-8421-88fd5ca5d94d) > Address: tcp:10.254.8.209:6644 > Status: cluster member > Role: leader > Term: 1103 > Leader: self > Vote: self > > Log: [42052, 51009] > Entries not yet committed: 0 > Entries not yet applied: 0 > Connections: ->beaf ->9a33 <-9a33 <-beaf > Servers: > a2b2 (a2b2 at tcp:10.254.8.209:6644) (self) next_index=15199 > match_index=51008 > beaf (beaf at tcp:10.254.8.208:6644) next_index=51009 match_index=0 > 9a33 (9a33 at tcp:10.254.8.210:6644) next_index=51009 match_index=51008 > I think it is a bug. I noticed that this problem happens when the cluster is restarted after DB compaction. I mentioned it in one of the test cases: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L252 I also mentioned another problem related to compaction: https://github.com/openvswitch/ovs/blob/master/tests/ovsdb-cluster.at#L239 I was planning to debug these but didn't get the time yet. I will try to find some time next week (it would be great if you could figure it out and submit patches). Thanks, Han ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
