Re: [vpp-dev] subunit requirement
Hi Tom, I assume you are talking about the rpm packaging, and not the RPM_DEPENDS from the root Makefile, right ? If so then feel free to remove it, as I believe it is only needed to run the tests. Otherwise I still believe it should be part of the "make install-dep" target. Best regards, On 5 March 2018 at 18:05, Thomas F Herbert wrote: > Garbriel and all, > > I am working on the release packaging for 18.01.1 for Centos. > > I want to discuss the subunit requirement in deps and in the spec file > originally introduced in this patch. > > https://gerrit.fd.io/r/gitweb?p=vpp.git;a=commitdiff;h= > d3e671e0dbb879d90f00bdee608ee0bb5f6357ae > > Although subunit is in Fedora (and EPEL), it is not available in Centos so > the subunit requirement breaks release builds for Centos. > > The following patch was merged in October and cherry-picked into 1710 > which made this requirement Fedora only. > > e41289115ffb24d95a5d0bc2ef33001d06a28688 > > Subsequently in this commit > > b8bbd6521fbab6579e4c571f61489f995f56bc78, it was made a requirement for > Centos as well. > > I want to propose an upstream patch to remove the subunit requirement for > Centos but I should check with everyone as to the implications. > > --Tom > -- > *Thomas F Herbert* > NFV and Fast Data Planes > Networking Group Office of the CTO > *Red Hat* > > > -- Gabriel Ganne
Re: [vpp-dev] Build failed on latest vpp code on ARM VM.
I do not see this second issue. This might be specific to the deb packaging. Please try build or build-release targets first. -- Gabriel Ganne From: adarsh m Sent: Tuesday, February 27, 2018 6:02:57 AM To: vpp-dev@lists.fd.io; Gabriel Ganne Cc: lukai (D); Appana Prasad Subject: Re: [vpp-dev] Build failed on latest vpp code on ARM VM. Hi, This Fix didn't seem to work, Code path : Gerrit Code Review<https://url10.mailanyone.net/v1/?m=1eqXQ3-mv-43&i=57e1b682&c=kCNzemvV_MAIFcurjf5gb3nBM4AjQcUKkyHQt9gadjFJe7ogC9PSipzP_qHUnl0iBMlud6_T6du1Lj1YkfRDzy4Dh-a6IhybR9a_aJR9MabUnyebae41yMPzaI6hKlJKyAF94JIrul5hLbXSGH8cQIYc1GDAAoPICvobPbSWQu-qPoto61SbXc-UFFUj026NKUrDaYvrLzdhCs2ubleJy64qyWJnx_voP_QbA14JAhc> <https://url10.mailanyone.net/v1/?m=1eqXQ3-mv-43&i=57e1b682&c=kCNzemvV_MAIFcurjf5gb3nBM4AjQcUKkyHQt9gadjFJe7ogC9PSipzP_qHUnl0iBMlud6_T6du1Lj1YkfRDzy4Dh-a6IhybR9a_aJR9MabUnyebae41yMPzaI6hKlJKyAF94JIrul5hLbXSGH8cQIYc1GDAAoPICvobPbSWQu-qPoto61SbXc-UFFUj026NKUrDaYvrLzdhCs2ubleJy64qyWJnx_voP_QbA14JAhc> Gerrit Code Review Logs : /home/csit/vpp/build-data/../src/vpp/vnet/main.c:21:29: fatal error: vpp/app/version.h: No such file or directory compilation terminated. Makefile:6946: recipe for target 'vpp/vnet/bin_vpp-main.o' failed make[5]: *** [vpp/vnet/bin_vpp-main.o] Error 1 make[5]: *** Waiting for unfinished jobs make[5]: Leaving directory '/home/csit/vpp/build-root/build-vpp-native/vpp' Makefile:7927: recipe for target 'all-recursive' failed make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory '/home/csit/vpp/build-root/build-vpp-native/vpp' Makefile:4054: recipe for target 'all' failed make[3]: *** [all] Error 2 make[3]: Leaving directory '/home/csit/vpp/build-root/build-vpp-native/vpp' Makefile:686: recipe for target 'vpp-build' failed make[2]: *** [vpp-build] Error 2 make[2]: Leaving directory '/home/csit/vpp/build-root' /home/csit/vpp/build-data/platforms.mk:20: recipe for target 'install-deb' failed make[1]: *** [install-deb] Error 1 make[1]: Leaving directory '/home/csit/vpp/build-root' Makefile:462: recipe for target 'pkg-deb' failed make: *** [pkg-deb] Error 2 csit@dut1:~/vpp$ cd build-root/ csit@dut1:~/vpp/build-root$ ll On Monday 26 February 2018, 10:36:52 PM IST, Gabriel Ganne wrote: See: https://gerrit.fd.io/r/c/10788/<https://url10.mailanyone.net/v1/?m=1eqXQ3-mv-43&i=57e1b682&c=GT4PJAILB7Jy09KnjlR8aKYzqPQtrWtbt82giM4xIDv_u6fW7LyTpTQS9yw4LuhqikhhFu1UuonSdr4aJ1Kpj-RyX9glmXpvj_l6YmWzu8URIZRJ0bSiuxg7Mj96RGwEHBiSWS2n9cwbZQl6rzeB8zzocr0-2yxKYzbPLCL-ALG-lYO1nTHJosXZtbGHFME-QaODkNTPRxzHbcF8iJiRwiel3wtl7D-Zw7ay1bhLRYc> -- Gabriel Ganne From: vpp-dev@lists.fd.io on behalf of via Lists.Fd.Io Sent: Monday, February 26, 2018 11:00:36 AM To: vpp-dev@lists.fd.io Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Build failed on latest vpp code on ARM VM. The same is Passing on x86 Env. On Monday 26 February 2018, 2:46:28 PM IST, adarsh m wrote: Hi, Building latest VPP code is failing, Logs: WARNING:vppapigen:oam_event missing reply message (oam_event_reply) make all-recursive make[4]: Entering directory '/home/csit/vpp/build-root/build-vpp-native/vpp' Making all in . make[5]: Entering directory '/home/csit/vpp/build-root/build-vpp-native/vpp' CC vppinfra/maplog.lo CC vppinfra/socket.lo CC vppinfra/timer.lo CC vppinfra/unix-formats.lo CC vppinfra/unix-misc.lo CC vlib/main.lo CC vlib/mc.lo CC vlib/node.lo CC vlib/node_cli.lo CC vlib/node_format.lo CC vlib/threads.lo CC vlib/threads_cli.lo CC vlib/trace.lo CC vnet/handoff.lo CC vnet/interface.lo CC vnet/interface_api.lo In file included from /home/csit/vpp/build-data/../src/vnet/ip/ip.h:66:0, from /home/csit/vpp/build-data/../src/vnet/fib/fib_entry.h:22, from /home/csit/vpp/build-data/../src/vnet/fib/ip6_fib.h:21, from /home/csit/vpp/build-data/../src/vnet/interface.c:42: /home/csit/vpp/build-data/../src/vnet/classify/vnet_classify.h: In function ‘vnet_classify_find_entry_inline’: /home/csit/vpp/build-data/../src/vnet/classify/vnet_classify.h:442:8: error: implicit declaration of function ‘u32x4_zero_byte_mask’ [-Werror=implicit-function-declaration] if (u32x4_zero_byte_mask (result.as_u32x4) == 0x) ^ cc1: all warnings being treated as errors Makefile:6931: recipe for target 'vnet/interface.lo' failed make[5]: *** [vnet/interface.lo] Error 1 make[5]: *** Waiting for unfinished jobs In file included from /home/csit/vpp/build-data/../src/vnet/ip/ip.h:66:0, from /home/csit/vpp/build-data/../src/vnet/interface_api.c:26: /home/csit/vpp/build-data/
Re: [vpp-dev] Build failed on latest vpp code on ARM VM.
See: https://gerrit.fd.io/r/c/10788/ -- Gabriel Ganne From: vpp-dev@lists.fd.io on behalf of via Lists.Fd.Io Sent: Monday, February 26, 2018 11:00:36 AM To: vpp-dev@lists.fd.io Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Build failed on latest vpp code on ARM VM. The same is Passing on x86 Env. On Monday 26 February 2018, 2:46:28 PM IST, adarsh m wrote: Hi, Building latest VPP code is failing, Logs: WARNING:vppapigen:oam_event missing reply message (oam_event_reply) make all-recursive make[4]: Entering directory '/home/csit/vpp/build-root/build-vpp-native/vpp' Making all in . make[5]: Entering directory '/home/csit/vpp/build-root/build-vpp-native/vpp' CC vppinfra/maplog.lo CC vppinfra/socket.lo CC vppinfra/timer.lo CC vppinfra/unix-formats.lo CC vppinfra/unix-misc.lo CC vlib/main.lo CC vlib/mc.lo CC vlib/node.lo CC vlib/node_cli.lo CC vlib/node_format.lo CC vlib/threads.lo CC vlib/threads_cli.lo CC vlib/trace.lo CC vnet/handoff.lo CC vnet/interface.lo CC vnet/interface_api.lo In file included from /home/csit/vpp/build-data/../src/vnet/ip/ip.h:66:0, from /home/csit/vpp/build-data/../src/vnet/fib/fib_entry.h:22, from /home/csit/vpp/build-data/../src/vnet/fib/ip6_fib.h:21, from /home/csit/vpp/build-data/../src/vnet/interface.c:42: /home/csit/vpp/build-data/../src/vnet/classify/vnet_classify.h: In function ‘vnet_classify_find_entry_inline’: /home/csit/vpp/build-data/../src/vnet/classify/vnet_classify.h:442:8: error: implicit declaration of function ‘u32x4_zero_byte_mask’ [-Werror=implicit-function-declaration] if (u32x4_zero_byte_mask (result.as_u32x4) == 0x) ^ cc1: all warnings being treated as errors Makefile:6931: recipe for target 'vnet/interface.lo' failed make[5]: *** [vnet/interface.lo] Error 1 make[5]: *** Waiting for unfinished jobs In file included from /home/csit/vpp/build-data/../src/vnet/ip/ip.h:66:0, from /home/csit/vpp/build-data/../src/vnet/interface_api.c:26: /home/csit/vpp/build-data/../src/vnet/classify/vnet_classify.h: In function ‘vnet_classify_find_entry_inline’: /home/csit/vpp/build-data/../src/vnet/classify/vnet_classify.h:442:8: error: implicit declaration of function ‘u32x4_zero_byte_mask’ [-Werror=implicit-function-declaration] if (u32x4_zero_byte_mask (result.as_u32x4) == 0x) ^ cc1: all warnings being treated as errors Makefile:6931: recipe for target 'vnet/interface_api.lo' failed make[5]: *** [vnet/interface_api.lo] Error 1 make[5]: Leaving directory '/home/csit/vpp/build-root/build-vpp-native/vpp' Makefile:7927: recipe for target 'all-recursive' failed make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory '/home/csit/vpp/build-root/build-vpp-native/vpp' Makefile:4054: recipe for target 'all' failed make[3]: *** [all] Error 2 make[3]: Leaving directory '/home/csit/vpp/build-root/build-vpp-native/vpp' Makefile:686: recipe for target 'vpp-build' failed make[2]: *** [vpp-build] Error 2 make[2]: Leaving directory '/home/csit/vpp/build-root' /home/csit/vpp/build-data/platforms.mk:20: recipe for target 'install-deb' failed make[1]: *** [install-deb] Error 1 make[1]: Leaving directory '/home/csit/vpp/build-root' Makefile:462: recipe for target 'pkg-deb' failed make: *** [pkg-deb] Error 2 csit@dut1:~/vpp$ cd build-root/
[vpp-dev] aarch64 compilation break
Hi Damjan, Brian, Damjan, your commit https://gerrit.fd.io/r/c/10670 has an impact in vnet_classify that overlaps with what I had written in https://gerrit.fd.io/r/c/10476/ However, without some changes in vector_neon.h it has the side effect to break aarch64 compilation. I've updated mine above yours. If you have the time, could you have a look at it please ? Thanks. Brian, since this is a compilation issue, let's not wait for all the performance tests results to come back before merging. We'll fix things later if need be, right ? (the performances are most probably better anyway) I've remove the -2 I set after last meeting. Best regards, -- Gabriel Ganne
[vpp-dev] GBP plugin warning - feature node not found
Hi Neale, Following your GBP plugin commit (gerrit 10465<https://gerrit.fd.io/r/#/c/10465>) there is an error message when starting vpp: vnet_feature_arc_init:205: feature node 'acl-plugin-out-ip6-fa' not found vnet_feature_arc_init:205: feature node 'acl-plugin-out-ip4-fa' not found I think you forgot to FEATURE_INIT() those two. Best regards, -- Gabriel Ganne
Re: [vpp-dev] [csit-dev] adding interface to vpp
I'm forwarding this to vpp-dev as I think this is a vpp/dpdk question more than a csit one. -- Gabriel Ganne From: csit-dev-boun...@lists.fd.io on behalf of adarsh m via csit-dev Sent: Tuesday, January 30, 2018 2:42:46 PM To: csit-...@lists.fd.io Subject: Re: [csit-dev] adding interface to vpp Hi, I fixed the issue of adding the vendor_id and device_id in the init.c but still the interface is not showing in VPP. Error after fixing : --- root1@root1-CN21UPSA:~$ sudo service vpp status ● vpp.service - vector packet processing engine Loaded: loaded (/lib/systemd/system/vpp.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2018-01-30 15:18:18 IST; 1min 34s ago Process: 12206 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited, status=0/SUCCESS) Process: 12202 ExecStartPre=/bin/rm -f /dev/shm/db /dev/shm/global_vm /dev/shm/vpe-api (code=exited, status=0/SUCCESS) Main PID: 12210 (vpp_main) CGroup: /system.slice/vpp.service └─12210 /usr/bin/vpp -c /etc/vpp/startup.conf Jan 30 15:18:18 root1-CN21UPSA /usr/bin/vpp[12210]: load_one_plugin:63: Loaded plugin: /usr/lib/vpp_api_test_plugins/gtpu_test_plugin.so Jan 30 15:18:18 root1-CN21UPSA /usr/bin/vpp[12210]: load_one_plugin:63: Loaded plugin: /usr/lib/vpp_api_test_plugins/ioam_pot_test_plugin.so Jan 30 15:18:18 root1-CN21UPSA vpp[12210]: /usr/bin/vpp[12210]: dpdk_config:1243: EAL init args: -c 1 -n 4 --huge-dir /run/vpp/hugepages --file-prefix vpp -w :0b:00.1 --master-lcore 0 --socket-mem 102 Jan 30 15:18:18 root1-CN21UPSA /usr/bin/vpp[12210]: dpdk_config:1243: EAL init args: -c 1 -n 4 --huge-dir /run/vpp/hugepages --file-prefix vpp -w :0b:00.1 --master-lcore 0 --socket-mem 1024 Jan 30 15:18:18 root1-CN21UPSA vpp[12210]: EAL: No free hugepages reported in hugepages-1048576kB Jan 30 15:18:18 root1-CN21UPSA vpp[12210]: EAL: VFIO support initialized Jan 30 15:18:18 root1-CN21UPSA vnet[12210]: EAL: VFIO support initialized Jan 30 15:18:18 root1-CN21UPSA vnet[12210]: unix_physmem_region_iommu_register: ioctl (VFIO_IOMMU_MAP_DMA): Invalid argument Jan 30 15:18:18 root1-CN21UPSA vnet[12210]: dpdk_ipsec_process:1011: not enough DPDK crypto resources, default to OpenSSL Jan 30 15:18:18 root1-CN21UPSA vnet[12210]: dpdk_lib_init:221: DPDK drivers found no ports... root1@root1-CN21UPSA:~$ sudo vppctl show interface Name Idx State Counter Count local00down root1@root1-CN21UPSA:~$ --- As per http://dpdk.org/doc/quick-start<https://url10.mailanyone.net/v1/?m=1egWLQ-000701-48&i=57e1b682&c=cckSGLX9KmlphpV41DeLDjX2V8iiFwMWxZm8jQW1OEfJB-YViEknutg81oP5YjkH5Tho1sO1iW9NLaJwmNimgJTyvQ7E-qP_XVDEgWsbyAGHOVxtNp1tBh18c37C14WgdPchsg5ZZ9Y8PBrHTjzgfmsH82c1ApaUHbK6cls2chPYGG-_0SnTwcw4Gwyxndp-ax9pu4cpUXbEp8W9Ir7DtnSS1eWT8dPP0FNytNBxrpE> 1> I Extracted the dpdk 2> Enabled pcap (libpcap headers are required). 3> Built libraries and test application (Linux headers may be needed with default config). 4> Reserved huge pages memory. but since the hardware isnt accessible to me i wasn't able to test by running poll-mode driver But after doing this when i start the vpp it'll stay active for a moment and stop immediately. Log : -- root1@root1-CN21UPSA:~$ sudo service vpp start root1@root1-CN21UPSA:~$ sudo service vpp status ● vpp.service - vector packet processing engine Loaded: loaded (/lib/systemd/system/vpp.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2018-01-30 19:10:09 IST; 6ms ago Process: 22689 ExecStopPost=/bin/rm -f /dev/shm/db /dev/shm/global_vm /dev/shm/vpe-api (code=exited, status=0/SUCCESS) Process: 22704 ExecStartPre=/sbin/modprobe uio_pci_generic (code=exited, status=0/SUCCESS) Process: 22701 ExecStartPre=/bin/rm -f /dev/shm/db /dev/shm/global_vm /dev/shm/vpe-api (code=exited, status=0/SUCCESS) Main PID: 22708 (vpp) CGroup: /system.slice/vpp.service └─22708 /usr/bin/vpp -c /etc/vpp/startup.conf Jan 30 19:10:09 root1-CN21UPSA systemd[1]: Starting vector packet processing engine... Jan 30 19:10:09 root1-CN21UPSA systemd[1]: Started vector packet processing engine. Jan 30 19:10:09 root1-CN21UPSA vpp[22708]: vlib_plugin_early_init:356: plugin path /usr/lib/vpp_plugins Jan 30 19:10:09 root1-CN21UPSA vpp[22708]: load_one_plugin:184: Loaded plugin: acl_plugin.so (Access Control Lists) root1@root1-CN21UPSA:~$ root1@root1-CN21UPSA:~$ sudo service vpp status ● vpp.service - vector packet processing engine Loaded: loaded (/lib/systemd/system/vpp.service; enabled; vendor preset: enabled) Active: inactive
Re: [vpp-dev] VPP/AArch64 - fd.io
Hi Maciek, Yes, this is the one. Same on both x86 and aarch64. I sent a mail to Hongjun, who told me that those two functionalities were yet to be implemented. See: https://lists.fd.io/pipermail/vpp-dev/2017-December/007708.html The extended tests are not part of any continuous tests, so I don't think this should be an issue. All the other tests pass, including the extended ones. Best regards, -- Gabriel Ganne From: Maciek Konstantynowicz (mkonstan) Sent: Friday, January 26, 2018 6:49:50 PM To: Tina Tsou; Gabriel Ganne; Ni, Hongjun Cc: vpp-dev@lists.fd.io Subject: Re: VPP/AArch64 - fd.io Thanks Tina! Gabriel, Hongjun, Tina reported on the last VPP call the kubeproxy tests are failing in vpp make test on Aarch64. I just checked on x86, and kubeproxy NAT44 and NAT66 tests pass, but NAT46 and NAT64 fail. Is this the issue that you’re hitting on Aarch64, or something else? -Maciek On 23 Jan 2018, at 16:23, Tina Tsou mailto:tina.t...@arm.com>> wrote: Dear Maciek, As discussed at today’s VPP call, you may want to look into here. https://wiki.fd.io/view/VPP/AArch64<https://url10.mailanyone.net/v1/?m=1ef88V-000jj9-56&i=57e1b682&c=EIGFuYigQNy8L8zlDx2XaNWFmvldyD2hV54DiQesN4CRW1uvhiCTNdGmN_KevQlYOy-DfRRQ0wYHA4cg57C8FvcT0ctAruvI7Us8iGKd4e0CnD5gJ0x0aQdw23nr3jJop5vsSpDy4imolzbV-vJVHVFxPF0ZEK5F8fKJPz3o4q8a-byjXSz7m7wfBMIERwhifziHZWlRT6VLvzwIuqp1xWLxN-R81TKdJljM8n-FloY> Build, unit test, packaging The following is tracked manually until hardware is integrated into upstream FD.io<https://url10.mailanyone.net/v1/?m=1ef88V-000jj9-56&i=57e1b682&c=JknkL1B1npFXD7FVSNKLIL3juuYTSjdYebfUwKjRD_hKY53qyXCby0RlQpzXjozTw3PTVCNL-P020n-sGhbmov42JY1zej24IGIccvc7-fwpfIDDct9o2bFpVsihLYfconvh5qkCtV2HBMkL81fSbmfJwVQeUm1GtsEyDkX2k5Ux4lKw7HEBYMk-uIy1ADBhZctdZz1eiVIY7lQfROEG_A> CI Cmd Status timing make bootstrap OK 0m45 make build OK 11m45 make build-release OK 14m56 make test OK 26m7 make test-all KO (kubeproxy) 36m15 make test-debug OK 22m32 make test-all-debug KO (kubeproxy) 33m29 Status on commit: 9cfb11787f24e90ad14697afefbb2dd5969b2951 (Mon Jan 8 01:29:34 2018) kubeproxy tests are broken on purpose: corresponding features are not fully implemented Timing consideration on platform: Hierofalcon with Cortex-A57 & Fedora 26 * Might want to have a look at this patch which adds make config: https://gerrit.fd.io/r/#/c/9200/<https://url10.mailanyone.net/v1/?m=1ef88V-000jj9-56&i=57e1b682&c=4bmDXnSE_jQSU1kS-tyZS8m3sSpGnW6xUwOM2mTdB46DZCQgoT7gy1xMPnX0YFRcKNTyvOCBzcFrg7J6q2CIB0xFny0HwD7sP55QOSusso3m-AyOPHw-ObMwzOwEgP7AKZ3nt_gdSzGDl-cDTd_3TpMb4SwdMfhtvdy_SbL4HGtcNqbZOOqOHnSO_1Xk96xm7VaTDikA1q7G1gOJ9XyXdggql8Tym4gtHPW4VkBn6cc> Distro Cmd Status Fedora 26 (Server Edition) make pkg-rpmOK Ubuntu 17.10make pkg-debOK Ubuntu 16.04.3 LTS make pkg-debOK Thank you, Tina IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] crash in bfd api
It does work. Thanks! -- Gabriel Ganne From: Florin Coras Sent: Monday, January 15, 2018 6:21:14 PM To: Gabriel Ganne Cc: fco...@cisco.com; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] crash in bfd api Hi Gabriel, Apologies about that! It’s just a tricky one line. I missed the & in front of rmp :( You have the patch here [1]. Just let me know if it solves the issue and thanks for testing! Cheers, Florin [1] https://gerrit.fd.io/r/#/c/10108/<https://url10.mailanyone.net/v1/?m=1eb8Rs-0001uv-5a&i=57e1b682&c=C7bgU2QT8AV7mcThGfZflgzpfL8ao4jiJMeQ92w-SbbXGEu7h85SUln1wxXleU3wEX8hAJrkIr3Jog79-6qr-sEQLJ3BbzTBYeK1CSjek64WFK6GzBKtgf3IXxHAiSfuWqQ734fwG5HFtAuy4AXNmACAhUJQcOoVEVvoE0lwW00aRXnVKqVmuFdyXWJ_8Xro2bFlxtgKXKGX7a-fwxGynC8As6FbSS8hPmCMdYNJkUc> On Jan 15, 2018, at 1:40 AM, Gabriel Ganne mailto:gabriel.ga...@enea.com>> wrote: Hi Florin, Following commit: 6c4dae27e75fc668f86c9cca0f3f58273b680621 I encounter a crash in BFD when running the extended test. (The standard test set passes) Attached is the log to the command (fastest way to crash): # make test-all-debug V=0 TEST=*.BFDAPITestCase.test_activate_auth Do you have an idea as to what's happening ? I'm ready to help fixing this if you give me some pointers, I'm afraid I could not see anything obvious (to me) reading your commit. Best regards, -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev<https://url10.mailanyone.net/v1/?m=1eb8Rs-0001uv-5a&i=57e1b682&c=7dGppsUpjERBoyePrF9NEW-S_V_bPFEcvGVi0cCsuu_g0ZR7jr-dwSBiUWPP6WFGXXV5FUHQqQtlhguZ9YDTmR1GtpYHAKo9FwQXwwxcZRHI6AiGX7Blago4ydO1ooG8eLn_JDLoEOpvHuLF_QdOEjMxksmBvtbcRvAY_mA6a6HAEMJUKUiS2l6qUX1pv9g7R3IJW27txdJBIvukhlB6xvmpLIu0gRSK_5hmRBTKDpeyehQnFouUMJ5dqP1W6YJX> ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] crash in bfd api
Hi Florin,
Following commit: 6c4dae27e75fc668f86c9cca0f3f58273b680621
I encounter a crash in BFD when running the extended test.
(The standard test set passes)
Attached is the log to the command (fastest way to crash):
# make test-all-debug V=0 TEST=*.BFDAPITestCase.test_activate_auth
Do you have an idea as to what's happening ?
I'm ready to help fixing this if you give me some pointers, I'm afraid I could
not see anything obvious (to me) reading your commit.
Best regards,
--
Gabriel Ganne
make -C /home/sources/vpp/build-root PLATFORM=vpp TAG=vpp_debug vpp-install
make[1]: Entering directory `/home/sources/vpp/build-root'
Arch for platform 'vpp' is native
Finding source for dpdk
Makefile fragment found in /home/sources/vpp/build-data/packages/dpdk.mk
Source found in /home/sources/vpp/dpdk
Arch for platform 'vpp' is native
Finding source for vpp
Makefile fragment found in /home/sources/vpp/build-data/packages/vpp.mk
Source found in /home/sources/vpp/src
Configuring dpdk: nothing to do
Building dpdk: nothing to do
Installing dpdk: nothing to do
Configuring vpp: nothing to do
Building vpp: nothing to do
Installing vpp: nothing to do
make[1]: Leaving directory `/home/sources/vpp/build-root'
make -C test TEST_DIR=/home/sources/vpp/test VPP_TEST_BUILD_DIR=/home/sources/vpp/build-root/build-vpp_debug-native VPP_TEST_BIN=/home/sources/vpp/build-root/install-vpp_debug-native/vpp/bin/vpp VPP_TEST_PLUGIN_PATH=/home/sources/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins:/home/sources/vpp/build-root/install-vpp_debug-native/vpp/lib64/vpp_plugins VPP_TEST_INSTALL_PATH=/home/sources/vpp/build-root/install-vpp_debug-native/ LD_LIBRARY_PATH=/home/sources/vpp/build-root/install-vpp_debug-native/vpp/lib/:/home/sources/vpp/build-root/install-vpp_debug-native/vpp/lib64/ EXTENDED_TESTS=yes PYTHON= OS_ID=rhel CACHE_OUTPUT= test
make[1]: Entering directory `/home/sources/vpp/test'
make -C ext
make[2]: Entering directory `/home/sources/vpp/test/ext'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/sources/vpp/test/ext'
10:19:21,006 Temporary dir is /tmp/vpp-unittest-SanityTestCase-KyhvkF, shm prefix is vpp-unittest-SanityTestCase-KyhvkF
10:19:21,006 vpp_cmdline: ['/home/sources/vpp/build-root/install-vpp_debug-native/vpp/bin/vpp', 'unix', '{', 'nodaemon', '', 'full-coredump', 'coredump-size unlimited', '}', 'api-trace', '{', 'on', '}', 'api-segment', '{', 'prefix', 'vpp-unittest-SanityTestCase-KyhvkF', '}', 'plugins', '{', 'plugin', 'dpdk_plugin.so', '{', 'disable', '}', '}', 'plugin_path', '/home/sources/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins:/home/sources/vpp/build-root/install-vpp_debug-native/vpp/lib64/vpp_plugins']
10:19:21,008 Spawned VPP with PID: 7434
10:19:21,409 Starting sleep for 0.1s (after vpp startup, before initial poll)
10:19:21,509 Finished sleep (after vpp startup, before initial poll) - slept 0.100106954575s (wanted 0.1s)
10:19:21,521 No such message type or failed CRC checksum: sw_interface_set_dpdk_hqos_tctbl_reply_4e2f524d
10:19:21,524 No such message type or failed CRC checksum: sw_interface_set_dpdk_hqos_subport_reply_147f258a
10:19:21,524 No such message type or failed CRC checksum: sw_interface_set_dpdk_hqos_tctbl_f9d98f13
10:19:21,525 No such message type or failed CRC checksum: sw_interface_set_dpdk_hqos_pipe_be9b2181
10:19:21,528 No such message type or failed CRC checksum: sw_interface_set_dpdk_hqos_pipe_reply_1222fa49
10:19:21,532 No such message type or failed CRC checksum: sw_interface_set_dpdk_hqos_subport_05a9fa2c
10:19:21,534 Waiting for pump thread to stop
10:19:21,536 Sending TERM to vpp
10:19:21,536 Waiting for vpp to die
10:19:21,540 --
10:19:21,540 VPP output to stdout while running SanityTestCase:
10:19:21,540 --
10:19:21,540
10:19:21,540 --
10:19:21,540 --
10:19:21,540 VPP output to stderr while running SanityTestCase:
10:19:21,540 --
10:19:21,540
vlib_plugin_early_init:356: plugin path /home/sources/vpp/build-root/install-vpp_debug-native/vpp/lib/vpp_plugins:/home/sources/vpp/build-root/install-vpp_debug-native/vpp/lib64/vpp_plugins
load_one_plugin:184: Loaded plugin:
Re: [vpp-dev] kube-proxy test fail
Oh, I understand. Sorry. Well, since I had a look, I came up with a few small modifications to make the tests pass but fail instead of getting stuck in the lock. It's all here: https://gerrit.fd.io/r/c/9880/ if you don't mind having a look. It also seems to make the NAT66 tests fall into place somehow. Best regards, -- Gabriel Ganne From: Ni, Hongjun Sent: Wednesday, December 20, 2017 9:49:15 AM To: Gabriel Ganne; vpp-dev@lists.fd.io Subject: RE: kube-proxy test fail Hi Gabriel, Currently, kube-proxy plugin only supports NAT44, so skip other test cases. NAT66, NAT46 and NAT64 will be added later. Thanks, Hongjun From: Gabriel Ganne [mailto:gabriel.ga...@enea.com] Sent: Wednesday, December 20, 2017 4:03 PM To: Ni, Hongjun ; vpp-dev@lists.fd.io Subject: Re: kube-proxy test fail I believe this does not run the extended tests, and therefore not the kubeproxy tests. I mean, this runs NAT44, but skips NAT46, NAT64, and NAT66. You need to add EXTENDED_TESTS=yes, or use the test-all target to run the other three : make test TEST=test_kubeproxy EXTENDED_TESTS=yes make test-all TEST=test_kubeproxy Best regards, -- Gabriel Ganne From: Ni, Hongjun mailto:hongjun...@intel.com>> Sent: Wednesday, December 20, 2017 4:52:39 AM To: Gabriel Ganne; vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: RE: kube-proxy test fail Hi Gabriel, I used below command and it works well: make test TEST=test_kubeproxy Could you give it a try? Thanks, Hongjun From: Gabriel Ganne [mailto:gabriel.ga...@enea.com] Sent: Tuesday, December 19, 2017 8:54 PM To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Ni, Hongjun mailto:hongjun...@intel.com>> Subject: kube-proxy test fail Hi Hongjun, I just ran the kube-proxy tests and I end up stuck in kp_vip_find_index() while processing a cli command. Below is the command I used and the backtrace I get. make test-all V=2 TEST=*.TestKP.* ... 0x7eaa9c04 in kp_vip_find_index (prefix=prefix@entry=0x7ec3dbe8, plen=104 'h', vip_index=vip_index@entry=0x7ec3dbbc) at /home/gannega/vpp/build-data/../src/plugins/kubeproxy/kp.c:457 457 kp_get_writer_lock(); (gdb) bt #0 0x7eaa9c04 in kp_vip_find_index (prefix=prefix@entry=0x7ec3dbe8, plen=104 'h', vip_index=vip_index@entry=0x7ec3dbbc) at /home/gannega/vpp/build-data/../src/plugins/kubeproxy/kp.c:457 #1 0x7eaaeacc in kp_pod_command_fn (vm=, input=, cmd=) at /home/gannega/vpp/build-data/../src/plugins/kubeproxy/kp_cli.c:132 #2 0xbf62cfd0 in vlib_cli_dispatch_sub_commands ( vm=vm@entry=0xbf68cfd0 , cm=cm@entry=0xbf68d220 , input=input@entry=0x7ec3ddf8, parent_command_index=) at /home/gannega/vpp/build-data/../src/vlib/cli.c:588 #3 0xbf62d618 in vlib_cli_dispatch_sub_commands ( vm=vm@entry=0xbf68cfd0 , cm=cm@entry=0xbf68d220 , input=input@entry=0x7ec3ddf8, parent_command_index=parent_command_index@entry=0) at /home/gannega/vpp/build-data/../src/vlib/cli.c:566 #4 0xbf62d764 in vlib_cli_input (vm=vm@entry=0xbf68cfd0 , input=input@entry=0x7ec3ddf8, function=function@entry=0x411b78 , function_arg=function_arg@entry=281472808508960) at /home/gannega/vpp/build-data/../src/vlib/cli.c:662 #5 0x00411e78 in vl_api_cli_inband_t_handler (mp=0x3809c4ec) at /home/gannega/vpp/build-data/../src/vpp/api/api.c:219 #6 0xbf6941ec in vl_msg_api_handler_with_vm_node (am=0xbf6be430 , the_msg=0x3809c4ec, vm=0xbf68cfd0 , node=0x7ec35000) at /home/gannega/vpp/build-data/../src/vlibapi/api_shared.c:508 #7 0xbf69d544 in memclnt_process (vm=, node=0x139013a, f=) at /home/gannega/vpp/build-data/../src/vlibmemory/memory_vlib.c:970 #8 0xbf635410 in vlib_process_bootstrap (_a=) at /home/gannega/vpp/build-data/../src/vlib/main.c:1231 #9 0xbef127a8 in clib_calljmp () at /home/gannega/vpp/build-data/../src/vppinfra/longjmp.S:676 Best regards, -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] kube-proxy test fail
I believe this does not run the extended tests, and therefore not the kubeproxy tests. I mean, this runs NAT44, but skips NAT46, NAT64, and NAT66. You need to add EXTENDED_TESTS=yes, or use the test-all target to run the other three : make test TEST=test_kubeproxy EXTENDED_TESTS=yes make test-all TEST=test_kubeproxy Best regards, -- Gabriel Ganne From: Ni, Hongjun Sent: Wednesday, December 20, 2017 4:52:39 AM To: Gabriel Ganne; vpp-dev@lists.fd.io Subject: RE: kube-proxy test fail Hi Gabriel, I used below command and it works well: make test TEST=test_kubeproxy Could you give it a try? Thanks, Hongjun From: Gabriel Ganne [mailto:gabriel.ga...@enea.com] Sent: Tuesday, December 19, 2017 8:54 PM To: vpp-dev@lists.fd.io; Ni, Hongjun Subject: kube-proxy test fail Hi Hongjun, I just ran the kube-proxy tests and I end up stuck in kp_vip_find_index() while processing a cli command. Below is the command I used and the backtrace I get. make test-all V=2 TEST=*.TestKP.* ... 0x7eaa9c04 in kp_vip_find_index (prefix=prefix@entry=0x7ec3dbe8, plen=104 'h', vip_index=vip_index@entry=0x7ec3dbbc) at /home/gannega/vpp/build-data/../src/plugins/kubeproxy/kp.c:457 457 kp_get_writer_lock(); (gdb) bt #0 0x7eaa9c04 in kp_vip_find_index (prefix=prefix@entry=0x7ec3dbe8, plen=104 'h', vip_index=vip_index@entry=0x7ec3dbbc) at /home/gannega/vpp/build-data/../src/plugins/kubeproxy/kp.c:457 #1 0x7eaaeacc in kp_pod_command_fn (vm=, input=, cmd=) at /home/gannega/vpp/build-data/../src/plugins/kubeproxy/kp_cli.c:132 #2 0xbf62cfd0 in vlib_cli_dispatch_sub_commands ( vm=vm@entry=0xbf68cfd0 , cm=cm@entry=0xbf68d220 , input=input@entry=0x7ec3ddf8, parent_command_index=) at /home/gannega/vpp/build-data/../src/vlib/cli.c:588 #3 0xbf62d618 in vlib_cli_dispatch_sub_commands ( vm=vm@entry=0xbf68cfd0 , cm=cm@entry=0xbf68d220 , input=input@entry=0x7ec3ddf8, parent_command_index=parent_command_index@entry=0) at /home/gannega/vpp/build-data/../src/vlib/cli.c:566 #4 0xbf62d764 in vlib_cli_input (vm=vm@entry=0xbf68cfd0 , input=input@entry=0x7ec3ddf8, function=function@entry=0x411b78 , function_arg=function_arg@entry=281472808508960) at /home/gannega/vpp/build-data/../src/vlib/cli.c:662 #5 0x00411e78 in vl_api_cli_inband_t_handler (mp=0x3809c4ec) at /home/gannega/vpp/build-data/../src/vpp/api/api.c:219 #6 0xbf6941ec in vl_msg_api_handler_with_vm_node (am=0xbf6be430 , the_msg=0x3809c4ec, vm=0xbf68cfd0 , node=0x7ec35000) at /home/gannega/vpp/build-data/../src/vlibapi/api_shared.c:508 #7 0xbf69d544 in memclnt_process (vm=, node=0x139013a, f=) at /home/gannega/vpp/build-data/../src/vlibmemory/memory_vlib.c:970 #8 0xbf635410 in vlib_process_bootstrap (_a=) at /home/gannega/vpp/build-data/../src/vlib/main.c:1231 #9 0xbef127a8 in clib_calljmp () at /home/gannega/vpp/build-data/../src/vppinfra/longjmp.S:676 Best regards, -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] kube-proxy test fail
Hi Hongjun, I just ran the kube-proxy tests and I end up stuck in kp_vip_find_index() while processing a cli command. Below is the command I used and the backtrace I get. make test-all V=2 TEST=*.TestKP.* ... 0x7eaa9c04 in kp_vip_find_index (prefix=prefix@entry=0x7ec3dbe8, plen=104 'h', vip_index=vip_index@entry=0x7ec3dbbc) at /home/gannega/vpp/build-data/../src/plugins/kubeproxy/kp.c:457 457 kp_get_writer_lock(); (gdb) bt #0 0x7eaa9c04 in kp_vip_find_index (prefix=prefix@entry=0x7ec3dbe8, plen=104 'h', vip_index=vip_index@entry=0x7ec3dbbc) at /home/gannega/vpp/build-data/../src/plugins/kubeproxy/kp.c:457 #1 0x7eaaeacc in kp_pod_command_fn (vm=, input=, cmd=) at /home/gannega/vpp/build-data/../src/plugins/kubeproxy/kp_cli.c:132 #2 0xbf62cfd0 in vlib_cli_dispatch_sub_commands ( vm=vm@entry=0xbf68cfd0 , cm=cm@entry=0xbf68d220 , input=input@entry=0x7ec3ddf8, parent_command_index=) at /home/gannega/vpp/build-data/../src/vlib/cli.c:588 #3 0xbf62d618 in vlib_cli_dispatch_sub_commands ( vm=vm@entry=0xbf68cfd0 , cm=cm@entry=0xbf68d220 , input=input@entry=0x7ec3ddf8, parent_command_index=parent_command_index@entry=0) at /home/gannega/vpp/build-data/../src/vlib/cli.c:566 #4 0xbf62d764 in vlib_cli_input (vm=vm@entry=0xbf68cfd0 , input=input@entry=0x7ec3ddf8, function=function@entry=0x411b78 , function_arg=function_arg@entry=281472808508960) at /home/gannega/vpp/build-data/../src/vlib/cli.c:662 #5 0x00411e78 in vl_api_cli_inband_t_handler (mp=0x3809c4ec) at /home/gannega/vpp/build-data/../src/vpp/api/api.c:219 #6 0xbf6941ec in vl_msg_api_handler_with_vm_node (am=0xbf6be430 , the_msg=0x3809c4ec, vm=0xbf68cfd0 , node=0x7ec35000) at /home/gannega/vpp/build-data/../src/vlibapi/api_shared.c:508 #7 0xbf69d544 in memclnt_process (vm=, node=0x139013a, f=) at /home/gannega/vpp/build-data/../src/vlibmemory/memory_vlib.c:970 #8 0xbf635410 in vlib_process_bootstrap (_a=) at /home/gannega/vpp/build-data/../src/vlib/main.c:1231 #9 0xbef127a8 in clib_calljmp () at /home/gannega/vpp/build-data/../src/vppinfra/longjmp.S:676 Best regards, -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] openSUSE build fails
Hi, If you browse the source http://hg.savannah.gnu.org/hgweb/indent/<http://hg.savannah.gnu.org/hgweb/indent> The tag 2.2.11 is there, the source seems updated regularly. Best regards, -- Gabriel Ganne From: vpp-dev-boun...@lists.fd.io on behalf of Billy McFall Sent: Friday, December 15, 2017 2:26:42 PM To: Marco Varlese Cc: Damjan Marion (damarion); vpp-dev Subject: Re: [vpp-dev] openSUSE build fails On Fri, Dec 15, 2017 at 5:15 AM, Marco Varlese mailto:mvarl...@suse.de>> wrote: Hi Damjan, On Fri, 2017-12-15 at 09:06 +, Damjan Marion (damarion) wrote: On 15 Dec 2017, at 08:52, Marco Varlese mailto:mvarl...@suse.de>> wrote: Damjan, On Thu, 2017-12-14 at 16:04 +, Damjan Marion (damarion) wrote: Folks, I'm hearing from multiple people that OpenSUSE verify job is failing (again). I haven't heard (or read) anything over the mailing list otherwise I would have looked into it. Also, if you hear anything like that you can always ping me directly and I will look into it... yes, people pinging me... See https://gerrit.fd.io/r/#/c/9440/<https://url10.mailanyone.net/v1/?m=1ePq0t-0001Fl-6M&i=57e1b682&c=68TFeWozfVWr0cOeQcoSLfj_6UOcLVL45-kDlIThNR_ycQZG5LOgi7NnZMJtDMUAmhIPtu-lSoEuMy-6KVT4RlufdWPa2MdfXzb_ObzIVcMVqAGqH7isJhFQHsNuaRick9gGwiEgwUQHltVsqpH-j4MwmcVniuBLxSiCuh2d9gPyZ9J_DeIXB9ebiI349MT3YFcKCmnf4x6PSEKrRYEoXYvyBIR1brcxBEL7qox2rRo> also: https://gerrit.fd.io/r/#/c/9813/<https://url10.mailanyone.net/v1/?m=1ePq0t-0001Fl-6M&i=57e1b682&c=CrMjX_E-jo7WRmm-sopHZy5U_DhywlV7a5A369OJyOow2Mnl2gcRxDLpcasYhpTRR5BtPvolweaLRScakJLx-NDgwKa8ITMZEpYTSnZ33x76qqlb_GnK382fDZNMYQn6KPDthHl7JZPOslzVKjUVDmvIaFaOxiQgDYkMHw02f9pC0xMMRtuuURi0fwbx8lfGUi64rlyZBA0T4tJOBYSPjVrm_yF86cI4X2Cc5I7XB8s> - abandoned but it shows that something was wrong Ok, so just summarizing our conversation on IRC for others too. That issue is connected to the different versions of INDENT (C checkstyle) installed on the different distros. openSUSE runs 2.2.10 whilst CentOS and Ubuntu run 2.2.11 What strikes me is that the upstream repo https://ftp.gnu.org/gnu/indent/<https://url10.mailanyone.net/v1/?m=1ePq0t-0001Fl-6M&i=57e1b682&c=SSiBFtZ5JbQhgjd9dEVXNEBYOdVo_Zo1ALr23wlHN44ValS-HDgjsawWJnWi-UHq0Pe9bgVnD5fLzJs6yISu-7ZkpGlAUgLW-IeDY4i6dsSzbSrCQ97iLT5lh93ItR7CCJtRvXBazqKbU6mxvPD_UTUCxm8qPdLPUdki9viMke3Q_tIJAReRf4KOT37lCP3T5tgGg3r1OT86tvKq2dovxDIjSQuPwKrDpiZ8AsSTB5w> has 2.2.10 as last revision. Our indent package maintainer is looking at possible other sources where Indent could "live" these days and will let me know as soon as she finds out. @Thomas Herbert, would you know the source where the Indent package on CentOS come from? Maybe that could help... Marco, I can't find the source. I'll look around a little more. From CentoOS 7.4: $ sudo yum provides indent : indent-2.2.11-13.el7.x86_64 : A GNU program for formatting C code Repo: base : $ sudo repoquery -i indent Name: indent Version : 2.2.11 Release : 13.el7 Architecture: x86_64 Size: 359131 Packager: CentOS BuildSystem <http://bugs.centos.org<https://url10.mailanyone.net/v1/?m=1ePq0t-0001Fl-6M&i=57e1b682&c=Oxgo1-3NKrvdr09W1lYMqTengBfLr3NBV2FFVNtp8fYGuDtJWoThOJlSD8GJqvFV073z9nD7sN8CIc6cGMY5Ktf0s2dmicXgEpxSpJ-1vWF3HJzKuKhaong1C79JraHgpv_RMkyn1Ti3ea_6V8IRf2brmeHyPuhEYTWSI_QG6AqFtjvX0aPRaSumejPxEeXCAykFMtWiapGJkmDmUsNaddheKgKeaLKrV5Dta5pVn40>> Group : Applications/Text URL : http://indent.isidore-it.eu/beautify.html<https://url10.mailanyone.net/v1/?m=1ePq0t-0001Fl-6M&i=57e1b682&c=ZsJ-B8LyIX_mcc1NX7wX4Kz57W648StYyqnjXbWD3QB20zhg9sd-OE6uScITWGKPDbg3FdfOIcmaGdewo2XSUck4otKAX5pyaWrAGli_LgaJNiL2fVH3-_g_lpB-3bQcL8W1ZlpPrbqD68TvAI6C6z7tcNwHg0U_FIw8kpDJOMSsgSyNZUCsqnzwkIgeZe790v-TLfFaLYfMKISLfgPJ1n3pylMyG4MyoPbPaxa7ujz76HRn4NLQhDlQ-T3OQMlI> <-- BUSTED LINK Repository : base Summary : A GNU program for formatting C code Source : indent-2.2.11-13.el7.src.rpm Description : Indent is a GNU program for beautifying C code, so that it is easier to read. Indent can also convert from one C writing style to a different one. Indent understands correct C syntax and tries to handle incorrect C syntax. Install the indent package if you are developing applications in C and you want a program to format your code. So generally speaking i would like to question having verify jobs for multiple distros. Is there really a value in compiling same code on different distros. Yes I know gcc version can be different, but that can be addressed in simpler way, if it needs to be addressed at all. More distros means more moving parts and bigger chance that something will fail. Well, I am not sure how to interpret this but (in theory) a build should be reproducible in the first place and I should not worry about problems with build outcomes. It doesn't only affect op
Re: [vpp-dev] some files are never compiled
Thanks Dave, I had submitted a pull-request for the smp files here : https://gerrit.fd.io/r/#/c/9730/ Please tell me if I should abandon it and let you do a more complete patch (I don't think I can judge for all the mentioned files by myself). Best regards, -- Gabriel Ganne From: Dave Barach (dbarach) Sent: Tuesday, December 5, 2017 4:06:09 PM To: Gabriel Ganne; vpp-dev@lists.fd.io Subject: RE: some files are never compiled Dear Gabriel, The files mentioned below fall into several buckets: * Code samples which might reasonably move to .../extras * Things we’re not using at the moment, but which would take someone a good long time to build from scratch. * The simulated annealing driver in vppinfra/anneal.c is a good example. * Debris which should be removed I’ll push a change-set to remove debris. Most of it is mine anyhow... (😉)... Thanks… Dave From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Gabriel Ganne Sent: Tuesday, December 5, 2017 9:52 AM To: vpp-dev@lists.fd.io Subject: [vpp-dev] some files are never compiled Hi, Following a question by Kevin Wang in VPP-1066<https://url10.mailanyone.net/v1/?m=1eMEna-0004JB-5d&i=57e1b682&c=dWeAA22ZVlhnZRfz-i1puxFN8Tk-2rBFyied8Gs8zXDL3Q9k6F90-z0RmbwFTcDpe1fhM2I86d0RWNBHd8VwdvEr6xIUAJFUUGBWtqrQ4SAz6poJV5MSO5svULzjhQ09dOY07pPOvLkZGm5vbduTTwLjeubkD5dEcO6oGql-Kl4gxIbNQD7liXGVkfS6NbeQtSvyOOWcF5cpIdRE6a-t4A_GyvHqKgofPuOcGu8KcWc>, I saw that some files are actually never compiled. Could some external plugin be using them ? Can (Should) they be removed ? As an example, I followed the smp.c, and smp_fido.[ch] files. They have been disabled by commit 01d86c7f6f05938c7d3fe181bd0aa2f75ccdd1df (reviewed here: https://gerrit.fd.io/r/#/c/2273/)<https://url10.mailanyone.net/v1/?m=1eMEna-0004JB-5d&i=57e1b682&c=l-t4hbRfiNUIHcmfdMfBceTCPh9V9nacm3ht2BtvZJdfe6BafPT4y2sAiyKxs3ILFgcCRQf4GEWgCXLfyWhmeR4XvUzjyzRejSl7yqU8A1qfnylWZBISY7Qk5IIaPgwqRx_qTYRI06Y-7wYuAuDsQp_sSnrtQM4oPijSLDSwlaTL_grLpgRDWHWS2iS38TfgV7brBJ9vX20IUGojBeO5oCpxWXrFWkWwLJi4wNGoN5I> almost 1.5 year ago. Here is how I listed them : for file in $(git find "\.c$"); do f=`basename $file .c` ; git grep -q "$f\.c"; if [ $? -eq 1 ] ; then echo $file ; fi ; done src/examples/vlib/plex_test.c src/tools/g2/mkversion.c src/vlib/elog_samples.c src/vlib/parse.c src/vlib/parse_builtin.c src/vnet/ethernet/mac_swap.c src/vnet/fib/fib_entry_src_default.c src/vnet/ip/ip4_test.c src/vnet/map/examples/health_check.c src/vpp/app/sticky_hash.c src/vppinfra/anneal.c src/vppinfra/mod_test_hash.c src/vppinfra/pfhash.c src/vppinfra/phash.c src/vppinfra/qhash.c src/vppinfra/smp.c src/vppinfra/smp_fifo.c src/vppinfra/test_pfhash.c src/vppinfra/test_phash.c src/vppinfra/test_pool.c src/vppinfra/test_qhash.c src/vppinfra/tw_timer_4t_3w_4sl_ov.c src/vppinfra/unix-kelog.c -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] some files are never compiled
Hi, Following a question by Kevin Wang in VPP-1066<https://jira.fd.io/browse/VPP-1066>, I saw that some files are actually never compiled. Could some external plugin be using them ? Can (Should) they be removed ? As an example, I followed the smp.c, and smp_fido.[ch] files. They have been disabled by commit 01d86c7f6f05938c7d3fe181bd0aa2f75ccdd1df (reviewed here: https://gerrit.fd.io/r/#/c/2273/) almost 1.5 year ago. Here is how I listed them : for file in $(git find "\.c$"); do f=`basename $file .c` ; git grep -q "$f\.c"; if [ $? -eq 1 ] ; then echo $file ; fi ; done src/examples/vlib/plex_test.c src/tools/g2/mkversion.c src/vlib/elog_samples.c src/vlib/parse.c src/vlib/parse_builtin.c src/vnet/ethernet/mac_swap.c src/vnet/fib/fib_entry_src_default.c src/vnet/ip/ip4_test.c src/vnet/map/examples/health_check.c src/vpp/app/sticky_hash.c src/vppinfra/anneal.c src/vppinfra/mod_test_hash.c src/vppinfra/pfhash.c src/vppinfra/phash.c src/vppinfra/qhash.c src/vppinfra/smp.c src/vppinfra/smp_fifo.c src/vppinfra/test_pfhash.c src/vppinfra/test_phash.c src/vppinfra/test_pool.c src/vppinfra/test_qhash.c src/vppinfra/tw_timer_4t_3w_4sl_ov.c src/vppinfra/unix-kelog.c -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] api functions using shared memory
I'm afraid I haven't followed csit work for long enough to be sure what to add. The current VppCounters class summarizes the stats though show_vpp_statistics(), which contains the results from "show run" "show hard", and "show error". I'm adding the csit-dev ML in CC. -- Gabriel Ganne From: Luke, Chris Sent: Thursday, November 30, 2017 3:15:14 PM To: Gabriel Ganne; Ole Troan Cc: vpp-dev@lists.fd.io Subject: RE: [vpp-dev] api functions using shared memory Which “show run” info? The stats in the header are calculated and some of the base values needed for it are missing in the current API; I intend to fix precisely that with this work since they are ideal summary lines for ‘vpptop’. Chris. From: Gabriel Ganne [mailto:gabriel.ga...@enea.com] Sent: Thursday, November 30, 2017 9:02 AM To: Luke, Chris ; Ole Troan Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] api functions using shared memory Chris, It seems your work in https://gerrit.fd.io/r/#/c/9483/<https://url10.mailanyone.net/v1/?m=1eKPcZ-0005hB-6I&i=57e1b682&c=OPVeSkSZbu6FrA_cqIP51kXlokjkwQcvZ6SXnb1T-zgPtrH3rrAEhijck0LRxx2R7QmWbujY6B2UVpc1CjKTp1NIG3fzxovrTFSp0bNaSpLV0G8g0dC-HquhtbveN7QYIZs16f_GWl6pusWOsiAZP8XZXmNIAw92LbH59L-Y6qsH2netX5aOtgMnK3JXxybL8ysUS01MNIiPyI4R2oJ6jHer9f1rFeadDy5SoWJJRZo> does all what Maciek and Dave discussed in VPP-55. Thanks again ! -- Gabriel Ganne From: Gabriel Ganne Sent: Thursday, November 30, 2017 2:52:06 PM To: Luke, Chris; Ole Troan Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] api functions using shared memory Actually, during the CSIT weekly call yesterday there was mentioned a missing VPP api for "show run". I think I even found a jira for it : https://jira.fd.io/browse/VPP-55<https://url10.mailanyone.net/v1/?m=1eKPcZ-0005hB-6I&i=57e1b682&c=i2TeK65kyGImFLnAmwROIqfk5Wn1GwMVGKnzalYLmorPV0yDwKCTHM3qCiET5OakZMfA1Uw6PeQG7vuOgUtlng4vZluRjCXMmhaug7upbu_Jbo1gsvc-o15TTCgIvsrQLj_m_hgKYy_CwtZCqCFzkvC_Fa-K2Leu9-5dM5lNa5rGJ0V8ZdcGi9wlxsJ7HiaauvUzgKdO54gnJ7DHX7z7oIxFFmmW-6pIGmWrWmCxy3g> It seemed like no one was working on it, and so I had a look. In the ticket, Dave Barach suggested to add this to the get_node_graph api function which is why I went there. If you could add the infos from "show run" into your dev, this would be great. Otherwise I can work on it after you've finished. There's no rush. Regards, -- Gabriel Ganne ____ From: Luke, Chris mailto:chris_l...@comcast.com>> Sent: Thursday, November 30, 2017 2:39:02 PM To: Gabriel Ganne; Ole Troan Subject: RE: [vpp-dev] api functions using shared memory What data for each node are you looking for? So I can make sure it ends up included. The existing get_node_graph is fairly limited in what it retrieves aside from the adjacencies and a handful of stats. My approach right now, to keep it simple, is to use the _dump/_details mechanism to return a list of items that encode the thread index and node index with the other details in a pretty flat structure; this should then be easily consumed by any binding. For Python I’ll also provide a way to reanimate the data into a fairly simple object model. You can see the first pass of my work at https://gerrit.fd.io/r/#/c/9222/<https://url10.mailanyone.net/v1/?m=1eKP3X-0004K2-4e&i=57e1b682&c=xpknLc81XbQlb0xvMXmP6LdQAhC9C-WkmvMZX_MyITOJvHIiAsAxybY7ldR6DsgpJ5FCoNL3Jo2iG9YbBigZEerbiFmF2qB-jovMxvNhAjOt69WE34BtnoQEXB6493yuyST9yzhnu_Z63w0ImBcsUPpNN_mdDmLi0RcARoD6KR9aixyc9umJ7hxu3Q6Y-EsWzzp2V9LnUIzwkWhK1lR6fEK1F0gwkYO9hqjl_PyjipY> and the two patches leading up to it which exposed a mechanism to interpret the result_in_shmem from Python and dezerialize into an object model. Ole rightly objects to using shmem, though I think there is still merit in merging the basic shmem reader since, while the mechanism exists in the API, we should support it where we can. Otherwise we should remove it from the API altogether. My current work on this I expect to have cleaned up and usable in a few days, though I’m travelling next week (Kubecon) which may interrupt things if I don’t make enough progress this week. Chris. From: Gabriel Ganne [mailto:gabriel.ga...@enea.com] Sent: Thursday, November 30, 2017 7:47 AM To: Ole Troan mailto:otr...@employees.org>>; Luke, Chris mailto:chris_l...@cable.comcast.com>> Subject: Re: [vpp-dev] api functions using shared memory Great ! Thanks. -- Gabriel Ganne From: Ole Troan mailto:otr...@employees.org>> Sent: Thursday, November 30, 2017 12:50 To: Gabriel Ganne Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] api functions using shared memory Gabriel, > I am looking at the g
Re: [vpp-dev] api functions using shared memory
Chris, It seems your work in https://gerrit.fd.io/r/#/c/9483/ does all what Maciek and Dave discussed in VPP-55. Thanks again ! -- Gabriel Ganne From: Gabriel Ganne Sent: Thursday, November 30, 2017 2:52:06 PM To: Luke, Chris; Ole Troan Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] api functions using shared memory Actually, during the CSIT weekly call yesterday there was mentioned a missing VPP api for "show run". I think I even found a jira for it : https://jira.fd.io/browse/VPP-55 <https://jira.fd.io/browse/VPP-55> It seemed like no one was working on it, and so I had a look. In the ticket, Dave Barach suggested to add this to the get_node_graph api function which is why I went there. If you could add the infos from "show run" into your dev, this would be great. Otherwise I can work on it after you've finished. There's no rush. Regards, -- Gabriel Ganne From: Luke, Chris Sent: Thursday, November 30, 2017 2:39:02 PM To: Gabriel Ganne; Ole Troan Subject: RE: [vpp-dev] api functions using shared memory What data for each node are you looking for? So I can make sure it ends up included. The existing get_node_graph is fairly limited in what it retrieves aside from the adjacencies and a handful of stats. My approach right now, to keep it simple, is to use the _dump/_details mechanism to return a list of items that encode the thread index and node index with the other details in a pretty flat structure; this should then be easily consumed by any binding. For Python I’ll also provide a way to reanimate the data into a fairly simple object model. You can see the first pass of my work at https://gerrit.fd.io/r/#/c/9222/<https://url10.mailanyone.net/v1/?m=1eKP3X-0004K2-4e&i=57e1b682&c=xpknLc81XbQlb0xvMXmP6LdQAhC9C-WkmvMZX_MyITOJvHIiAsAxybY7ldR6DsgpJ5FCoNL3Jo2iG9YbBigZEerbiFmF2qB-jovMxvNhAjOt69WE34BtnoQEXB6493yuyST9yzhnu_Z63w0ImBcsUPpNN_mdDmLi0RcARoD6KR9aixyc9umJ7hxu3Q6Y-EsWzzp2V9LnUIzwkWhK1lR6fEK1F0gwkYO9hqjl_PyjipY> and the two patches leading up to it which exposed a mechanism to interpret the result_in_shmem from Python and dezerialize into an object model. Ole rightly objects to using shmem, though I think there is still merit in merging the basic shmem reader since, while the mechanism exists in the API, we should support it where we can. Otherwise we should remove it from the API altogether. My current work on this I expect to have cleaned up and usable in a few days, though I’m travelling next week (Kubecon) which may interrupt things if I don’t make enough progress this week. Chris. From: Gabriel Ganne [mailto:gabriel.ga...@enea.com] Sent: Thursday, November 30, 2017 7:47 AM To: Ole Troan ; Luke, Chris Subject: Re: [vpp-dev] api functions using shared memory Great ! Thanks. -- Gabriel Ganne From: Ole Troan mailto:otr...@employees.org>> Sent: Thursday, November 30, 2017 12:50 To: Gabriel Ganne Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] api functions using shared memory Gabriel, > I am looking at the get_node_graph() api function, for use in python. > It returns a u64 reply_in_shmem value which points to the shared memory and > must then be processed by vlib_node_unserialize() (as is done in vat) but I > only saw such a function in C. > Is there any way to do this in python ? (other languages should have the same > issue). > > Also, I had a look at the the cli api function (which works the same way) and > saw that it had an cli_inband version which apparently was designed to > replace the cli api function because it was using shared memory > (https://gerrit.fd.io/r/#/c/2575/<https://url10.mailanyone.net/v1/?m=1eKP3X-0004K2-4e&i=57e1b682&c=9lLDLNFIPw66omxD7Xax5tRUJNBd1qBZ0kxnVJ1-awHNTm2422SYts4YSy-uiYv-sIkxnmVM_AUhU5ffVfWJwXzdtn-FQcePME2XF4G4td9Ry9_yZTXJOVLj-uUyvUQJOFHEKDnb-QuZgYoYAo5qN0hHRrE03NUG8B-FccnprFXO-5lHSBuhJXFJS2Burywj_iD1TCOzaF0ybCtKzKgSDgOjtP9XhQ51M3FpinXrAHg>) > Should the get_node_graph api function also get an *_inband version ? Yes. That's also a prerequisite for alternate transports like the socket API. I think Chris is working on it. Cheers, Ole ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] api functions using shared memory
Actually, during the CSIT weekly call yesterday there was mentioned a missing VPP api for "show run". I think I even found a jira for it : https://jira.fd.io/browse/VPP-55 <https://jira.fd.io/browse/VPP-55> It seemed like no one was working on it, and so I had a look. In the ticket, Dave Barach suggested to add this to the get_node_graph api function which is why I went there. If you could add the infos from "show run" into your dev, this would be great. Otherwise I can work on it after you've finished. There's no rush. Regards, -- Gabriel Ganne From: Luke, Chris Sent: Thursday, November 30, 2017 2:39:02 PM To: Gabriel Ganne; Ole Troan Subject: RE: [vpp-dev] api functions using shared memory What data for each node are you looking for? So I can make sure it ends up included. The existing get_node_graph is fairly limited in what it retrieves aside from the adjacencies and a handful of stats. My approach right now, to keep it simple, is to use the _dump/_details mechanism to return a list of items that encode the thread index and node index with the other details in a pretty flat structure; this should then be easily consumed by any binding. For Python I’ll also provide a way to reanimate the data into a fairly simple object model. You can see the first pass of my work at https://gerrit.fd.io/r/#/c/9222/<https://url10.mailanyone.net/v1/?m=1eKP3X-0004K2-4e&i=57e1b682&c=xpknLc81XbQlb0xvMXmP6LdQAhC9C-WkmvMZX_MyITOJvHIiAsAxybY7ldR6DsgpJ5FCoNL3Jo2iG9YbBigZEerbiFmF2qB-jovMxvNhAjOt69WE34BtnoQEXB6493yuyST9yzhnu_Z63w0ImBcsUPpNN_mdDmLi0RcARoD6KR9aixyc9umJ7hxu3Q6Y-EsWzzp2V9LnUIzwkWhK1lR6fEK1F0gwkYO9hqjl_PyjipY> and the two patches leading up to it which exposed a mechanism to interpret the result_in_shmem from Python and dezerialize into an object model. Ole rightly objects to using shmem, though I think there is still merit in merging the basic shmem reader since, while the mechanism exists in the API, we should support it where we can. Otherwise we should remove it from the API altogether. My current work on this I expect to have cleaned up and usable in a few days, though I’m travelling next week (Kubecon) which may interrupt things if I don’t make enough progress this week. Chris. From: Gabriel Ganne [mailto:gabriel.ga...@enea.com] Sent: Thursday, November 30, 2017 7:47 AM To: Ole Troan ; Luke, Chris Subject: Re: [vpp-dev] api functions using shared memory Great ! Thanks. -- Gabriel Ganne From: Ole Troan mailto:otr...@employees.org>> Sent: Thursday, November 30, 2017 12:50 To: Gabriel Ganne Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> Subject: Re: [vpp-dev] api functions using shared memory Gabriel, > I am looking at the get_node_graph() api function, for use in python. > It returns a u64 reply_in_shmem value which points to the shared memory and > must then be processed by vlib_node_unserialize() (as is done in vat) but I > only saw such a function in C. > Is there any way to do this in python ? (other languages should have the same > issue). > > Also, I had a look at the the cli api function (which works the same way) and > saw that it had an cli_inband version which apparently was designed to > replace the cli api function because it was using shared memory > (https://gerrit.fd.io/r/#/c/2575/<https://url10.mailanyone.net/v1/?m=1eKP3X-0004K2-4e&i=57e1b682&c=9lLDLNFIPw66omxD7Xax5tRUJNBd1qBZ0kxnVJ1-awHNTm2422SYts4YSy-uiYv-sIkxnmVM_AUhU5ffVfWJwXzdtn-FQcePME2XF4G4td9Ry9_yZTXJOVLj-uUyvUQJOFHEKDnb-QuZgYoYAo5qN0hHRrE03NUG8B-FccnprFXO-5lHSBuhJXFJS2Burywj_iD1TCOzaF0ybCtKzKgSDgOjtP9XhQ51M3FpinXrAHg>) > Should the get_node_graph api function also get an *_inband version ? Yes. That's also a prerequisite for alternate transports like the socket API. I think Chris is working on it. Cheers, Ole ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] api functions using shared memory
Hi, I am looking at the get_node_graph() api function, for use in python. It returns a u64 reply_in_shmem value which points to the shared memory and must then be processed by vlib_node_unserialize() (as is done in vat) but I only saw such a function in C. Is there any way to do this in python ? (other languages should have the same issue). Also, I had a look at the the cli api function (which works the same way) and saw that it had an cli_inband version which apparently was designed to replace the cli api function because it was using shared memory (https://gerrit.fd.io/r/#/c/2575/) Should the get_node_graph api function also get an *_inband version ? Best regards, -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] vpp-verify-master-opensuse build failure triage
Adding dpdk-user ML. I had a look with an older dpdk archive I found. The folder archived has been renamed from *dpdk-17.08* to *dpdk-stable-17.08* This is the only difference, but it is enough to make the md5sum fail. -- Gabriel Ganne From: Gabriel Ganne Sent: Tuesday, November 28, 2017 11:13:23 AM To: Marco Varlese; Dave Wallace; Gonzalez Monroy, Sergio Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage Hi Marco, I believe http://fast.dpdk.org/rel redirects to http://static.dpdk.org/rel/ I disagree on the md5 hashs. I have the following (NOK on 17.08, and OK on 17.11) : $ wget http://static.dpdk.org/rel/dpdk-17.08.tar.xz $ openssl md5 dpdk-17.08.tar.xz # is 0641f59ea8ea98afefa7cfa2699f6241 in dpdk/Makefile MD5(dpdk-17.08.tar.xz)= 537ff038915fefd0f210905fafcadb4b $ wget http://static.dpdk.org/rel/dpdk-17.11.tar.xz $ openssl md5 dpdk-17.11.tar.xz MD5(dpdk-17.11.tar.xz)= 53ee9e054a8797c9e67ffa0eb5d0c701 Though I agree that if the "recheck" button made the build pass, there must be something wrong on my side. ... what did I miss ? -- Gabriel Ganne From: Marco Varlese Sent: Tuesday, November 28, 2017 10:55:49 AM To: Gabriel Ganne; Dave Wallace; Gonzalez Monroy, Sergio Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage Hi Gabriel, On Tue, 2017-11-28 at 09:19 +0000, Gabriel Ganne wrote: Hi, I also have this issue on my machine, and I see on http://static.dpdk.org/rel/<https://url10.mailanyone.net/v1/?m=1eJccQ-Nh-40&i=57e1b682&c=YXtwE6d2zZdJXheJMCdO_SuDEoEQrdHCdgK6mO-4uDZ2Bj4ObdPrE5Fn6cirFxtZy34K57yMEhszksJbrY2fvTBetWB77s_CJWkpQyyah6_rFbLQmG-dY-qWniIVsFMMRdRMvyqh0lqUak-Q_B9fQ1OiLTvnngJ7HyAk1jgaPeLkV0WU1HDSfBiGhal1ybeY3rdJxuTArJeYn2n4LUfPpkcz-j2_0PTyMVbDfGIpu8o> that dpdk-17.08.tar.xz was written yesterday (27-Nov-2017 13:00) Wouldn't it be possible that the archive was overwritten ? The DPDK tarball in VPP is downloaded from http://fast.dpdk.org/rel<https://url10.mailanyone.net/v1/?m=1eJccQ-Nh-40&i=57e1b682&c=sI-Qn1OsaRXnxl6lIQOxUZGRD-xaVnPckQwB6CApx-aEpU2UjOwTOfDJA0lq7_Gt1VGQkE6h9MX8Bk9XrgJVo3hCjx0joHpm7zsqXSWsSRqfNFPpowBhGN6XywZqIk3LQZuUWd8ZzZ4GB3xv9bDSmK_j0r1RjBHuNRKrWVhBBEd_Ex_JIhXR3UfOngNNGAe6XmP6AtdokoxpJhyUHUq1pw> According to http://dpdk.org/rel<https://url10.mailanyone.net/v1/?m=1eJccQ-Nh-40&i=57e1b682&c=sI-Qn1OsaRXnxl6lIQOxUZGRD-xaVnPckQwB6CApx-aEpU2UjOwTOfDJA0lq7_Gt1VGQkE6h9MX8Bk9XrgJVo3hCjx0joHpm7zsqXSWsSRqfNFPpowBhGN6XywZqIk3LQZuUWd8ZzZ4GB3xv9bDSmK_j0r1RjBHuNRKrWVhBBEd_Ex_JIhXR3UfOngNNGAe6XmP6AtdokoxpJhyUHUq1pw> the MD5 used in VPP for the DPDK 17.08 release is correct. In which case, the hash would need to be updated. Right, if the tarball was a newer and different one then the MD5 hash should be updated in VPP for the the checksum performed... However, in the case described by Dave below, a simple 'recheck' which triggers a new build (with the same code/scripts/etc. hence the same MD5 hash) solved it. Also, this would probably not be seen by people who had the dpdk-install-dev package already installed. Who should I ask to check this ? I've added Sergio who might have further thoughts on this one. Best regards -- Gabriel Ganne From: vpp-dev-boun...@lists.fd.io on behalf of Marco Varlese Sent: Tuesday, November 28, 2017 9:19:37 AM To: Dave Wallace Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage Dear Dave, By the look of it is seemed to have been an hiccup with the download or that something spurious was left on the filesystem... === 12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master- opensuse/dpdk/dpdk-17.08.tar.xz and retry 12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify- master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed 12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build- root/build-vpp-native/dpdk/.download.ok] Error 1 12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master- opensuse/dpdk' 12:08:13 Makefile:460: recipe for target 'ebuild-build' failed 12:08:13 make[2]: *** [ebuild-build] Error 2 12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master- opensuse/dpdk' 12:08:13 Makefile:682: recipe for target 'dpdk-build' failed 12:08:13 make[1]: *** [dpdk-build] Error 2 12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master- opensuse/build-root' 12:08:13 Makefile:333: recipe for target 'build-release' failed 12:08:13 make: *** [build-release] Error 2 12:08:13 Build step 'Execute shell' marked build as failure === Since the MD5 checksum on the DPDK tarball fails; to answer your question, no, it has never happened to me to see this specific issue before. I don
Re: [vpp-dev] vpp-verify-master-opensuse build failure triage
Hi Marco, I believe http://fast.dpdk.org/rel redirects to http://static.dpdk.org/rel/ I disagree on the md5 hashs. I have the following (NOK on 17.08, and OK on 17.11) : $ wget http://static.dpdk.org/rel/dpdk-17.08.tar.xz $ openssl md5 dpdk-17.08.tar.xz # is 0641f59ea8ea98afefa7cfa2699f6241 in dpdk/Makefile MD5(dpdk-17.08.tar.xz)= 537ff038915fefd0f210905fafcadb4b $ wget http://static.dpdk.org/rel/dpdk-17.11.tar.xz $ openssl md5 dpdk-17.11.tar.xz MD5(dpdk-17.11.tar.xz)= 53ee9e054a8797c9e67ffa0eb5d0c701 Though I agree that if the "recheck" button made the build pass, there must be something wrong on my side. ... what did I miss ? -- Gabriel Ganne From: Marco Varlese Sent: Tuesday, November 28, 2017 10:55:49 AM To: Gabriel Ganne; Dave Wallace; Gonzalez Monroy, Sergio Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage Hi Gabriel, On Tue, 2017-11-28 at 09:19 +0000, Gabriel Ganne wrote: Hi, I also have this issue on my machine, and I see on http://static.dpdk.org/rel/<https://url10.mailanyone.net/v1/?m=1eJccQ-Nh-40&i=57e1b682&c=YXtwE6d2zZdJXheJMCdO_SuDEoEQrdHCdgK6mO-4uDZ2Bj4ObdPrE5Fn6cirFxtZy34K57yMEhszksJbrY2fvTBetWB77s_CJWkpQyyah6_rFbLQmG-dY-qWniIVsFMMRdRMvyqh0lqUak-Q_B9fQ1OiLTvnngJ7HyAk1jgaPeLkV0WU1HDSfBiGhal1ybeY3rdJxuTArJeYn2n4LUfPpkcz-j2_0PTyMVbDfGIpu8o> that dpdk-17.08.tar.xz was written yesterday (27-Nov-2017 13:00) Wouldn't it be possible that the archive was overwritten ? The DPDK tarball in VPP is downloaded from http://fast.dpdk.org/rel<https://url10.mailanyone.net/v1/?m=1eJccQ-Nh-40&i=57e1b682&c=sI-Qn1OsaRXnxl6lIQOxUZGRD-xaVnPckQwB6CApx-aEpU2UjOwTOfDJA0lq7_Gt1VGQkE6h9MX8Bk9XrgJVo3hCjx0joHpm7zsqXSWsSRqfNFPpowBhGN6XywZqIk3LQZuUWd8ZzZ4GB3xv9bDSmK_j0r1RjBHuNRKrWVhBBEd_Ex_JIhXR3UfOngNNGAe6XmP6AtdokoxpJhyUHUq1pw> According to http://dpdk.org/rel<https://url10.mailanyone.net/v1/?m=1eJccQ-Nh-40&i=57e1b682&c=sI-Qn1OsaRXnxl6lIQOxUZGRD-xaVnPckQwB6CApx-aEpU2UjOwTOfDJA0lq7_Gt1VGQkE6h9MX8Bk9XrgJVo3hCjx0joHpm7zsqXSWsSRqfNFPpowBhGN6XywZqIk3LQZuUWd8ZzZ4GB3xv9bDSmK_j0r1RjBHuNRKrWVhBBEd_Ex_JIhXR3UfOngNNGAe6XmP6AtdokoxpJhyUHUq1pw> the MD5 used in VPP for the DPDK 17.08 release is correct. In which case, the hash would need to be updated. Right, if the tarball was a newer and different one then the MD5 hash should be updated in VPP for the the checksum performed... However, in the case described by Dave below, a simple 'recheck' which triggers a new build (with the same code/scripts/etc. hence the same MD5 hash) solved it. Also, this would probably not be seen by people who had the dpdk-install-dev package already installed. Who should I ask to check this ? I've added Sergio who might have further thoughts on this one. Best regards -- Gabriel Ganne From: vpp-dev-boun...@lists.fd.io on behalf of Marco Varlese Sent: Tuesday, November 28, 2017 9:19:37 AM To: Dave Wallace Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage Dear Dave, By the look of it is seemed to have been an hiccup with the download or that something spurious was left on the filesystem... === 12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master- opensuse/dpdk/dpdk-17.08.tar.xz and retry 12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify- master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed 12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build- root/build-vpp-native/dpdk/.download.ok] Error 1 12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master- opensuse/dpdk' 12:08:13 Makefile:460: recipe for target 'ebuild-build' failed 12:08:13 make[2]: *** [ebuild-build] Error 2 12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master- opensuse/dpdk' 12:08:13 Makefile:682: recipe for target 'dpdk-build' failed 12:08:13 make[1]: *** [dpdk-build] Error 2 12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master- opensuse/build-root' 12:08:13 Makefile:333: recipe for target 'build-release' failed 12:08:13 make: *** [build-release] Error 2 12:08:13 Build step 'Execute shell' marked build as failure === Since the MD5 checksum on the DPDK tarball fails; to answer your question, no, it has never happened to me to see this specific issue before. I don't think there's anything specific to the openSUSE setup and/or scripts being executed. I'd rather feel is - as I said earlier - something to do with an hiccup on the infrastructure side. The fact that a 'recheck' made it passing I suppose it confirms my current theory. An idea: maybe, if it happens again, we might want to ask Vanessa to see what's the status on the slave-node? Not sure if that could give us some more insight of what's going on. Cheers,
Re: [vpp-dev] vpp-verify-master-opensuse build failure triage
Hi, I also have this issue on my machine, and I see on http://static.dpdk.org/rel/ that dpdk-17.08.tar.xz was written yesterday (27-Nov-2017 13:00) Wouldn't it be possible that the archive was overwritten ? In which case, the hash would need to be updated. Also, this would probably not be seen by people who had the dpdk-install-dev package already installed. Who should I ask to check this ? Best regards -- Gabriel Ganne From: vpp-dev-boun...@lists.fd.io on behalf of Marco Varlese Sent: Tuesday, November 28, 2017 9:19:37 AM To: Dave Wallace Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] vpp-verify-master-opensuse build failure triage Dear Dave, By the look of it is seemed to have been an hiccup with the download or that something spurious was left on the filesystem... === 12:08:13 Bad Checksum! Please remove /w/workspace/vpp-verify-master- opensuse/dpdk/dpdk-17.08.tar.xz and retry 12:08:13 Makefile:267: recipe for target '/w/workspace/vpp-verify- master-opensuse/build-root/build-vpp-native/dpdk/.download.ok' failed 12:08:13 make[3]: *** [/w/workspace/vpp-verify-master-opensuse/build- root/build-vpp-native/dpdk/.download.ok] Error 1 12:08:13 make[3]: Leaving directory '/w/workspace/vpp-verify-master- opensuse/dpdk' 12:08:13 Makefile:460: recipe for target 'ebuild-build' failed 12:08:13 make[2]: *** [ebuild-build] Error 2 12:08:13 make[2]: Leaving directory '/w/workspace/vpp-verify-master- opensuse/dpdk' 12:08:13 Makefile:682: recipe for target 'dpdk-build' failed 12:08:13 make[1]: *** [dpdk-build] Error 2 12:08:13 make[1]: Leaving directory '/w/workspace/vpp-verify-master- opensuse/build-root' 12:08:13 Makefile:333: recipe for target 'build-release' failed 12:08:13 make: *** [build-release] Error 2 12:08:13 Build step 'Execute shell' marked build as failure === Since the MD5 checksum on the DPDK tarball fails; to answer your question, no, it has never happened to me to see this specific issue before. I don't think there's anything specific to the openSUSE setup and/or scripts being executed. I'd rather feel is - as I said earlier - something to do with an hiccup on the infrastructure side. The fact that a 'recheck' made it passing I suppose it confirms my current theory. An idea: maybe, if it happens again, we might want to ask Vanessa to see what's the status on the slave-node? Not sure if that could give us some more insight of what's going on. Cheers, Marco On Mon, 2017-11-27 at 11:04 -0500, Dave Wallace wrote: > Marco, > > Can you please take a look at the build failure encountered with http > s://gerrit.fd.io/r/#/c/9582/ on the vpp-verify-master-opensuse > jenkins job: > > - %< - > fd.io JJB 7:56 AM > Patch Set 2: Verified-1 > Build Failed > https://jenkins.fd.io/job/vpp-verify-master-opensuse/459/ : FAILURE > No problems were identified. If you know why this problem occurred, > please add a suitable Cause for it. ( https://jenkins.fd.io/job/vpp-v > erify-master-opensuse/459/ ) > Logs: https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify- > master-opensuse/459 > - %< -- > > From the logs, it appears that there is an issue related to building > dpdk. Have you seen this issue before? If so, it this an > infrastructure issue or something else? > > Thanks, > -daw- > ___ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] vpp api test
Hi Holoo, There are two great pages explaining how to use the vpp C and python APIs: C: https://wiki.fd.io/view/VPP/How_To_Use_The_C_API python: https://wiki.fd.io/view/VPP/Python_API I believe you can also use java or lua if you wish. Regards, -- Gabriel Ganne From: vpp-dev-boun...@lists.fd.io on behalf of Holoo Gulakh Sent: Monday, November 27, 2017 8:55:43 AM To: vpp-dev@lists.fd.io Subject: [vpp-dev] vpp api test Hello I am working on VPP and now need to use its API to communicate with it. I want to know how I can use its API?? Is there any example in source code or any where else? (if yes, how should I use it?) thanks in advance ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] vpp continuous integration on armv8
Yes, they are. I estimate it should take about 40 minutes to build and test with 8 cores in release mode, therefore I do not think that using all 3 ThunderX is necessary. I do not have access to a ThunderX platform on my side (I ran my tests on NXP and Hierofalcon platforms), if needed please see with Tina Tsou (in CC) for the specifics of ThunderX. I was thinking about duplicating the *vpp-verify-master-ubuntu1604* target as a first step. Ubuntu 16.04 is a LTS for armv8 and is one of the distributions already used for vpp x86 continuous testing. If all goes well, I was thinking about using fedora-26 (or above) as rhel-based distribution, since it also has aarch64 official support. But since it's not one of the distros already used in ci, let's keep it for later. Regards, -- Gabriel Ganne From: Ed Warnicke Sent: Thursday, November 16, 2017 4:47:14 PM To: Gabriel Ganne Cc: vpp-dev; Dave Barach (dbarach); Nicolas Bouthors; csit-...@lists.fd.io; Vanessa Valderrama Subject: Re: [vpp-dev] vpp continuous integration on armv8 Gabriel, This is awesome news! Do I understand correctly that these ThunderX boards are intended to be used for build/make test/packaging? If so, I've cced in Vanessa, our fearless sysadmin to help in figuring these things out :) Do you have opinions about which Linux distributions you want to package for (Ubuntu?, Centos?) and versions? Ed On Thu, Nov 16, 2017 at 5:27 AM Gabriel Ganne mailto:gabriel.ga...@enea.com>> wrote: Hi, We've been working on preparing vpp for armv8 continuous testing (See https://wiki.fd.io/view/VPP/AArch64<https://url10.mailanyone.net/v1/?m=1eFMO4-0003qy-3d&i=57e1b682&c=-ZITzwi6PGNT2EzKomkJRJ6M-7hD63QeHKT6tMIqMLSnlkmDUD9MfhdhuIw6iWayvj9HXr-SEr3zZlMt-TaTcUZhFRPyigiDDt7sfjQQxA8ESJIAyB06-QLH18FYzLWPwjJl8nmFi7D4ZD-9MfHHGQSEhj7_dqJNULEmezdjyETUcv28RNlzXlyC41ndbFhGIHD4TronLGLM7RL1QTG-dT2eyoBI4hyNrzA8GVmPHHM>), and we think that we now have everything which is required to add arm as ci platform in the vpp review process (build, test and packaging). All the test have been done on "native". Also 3 thunderX platforms sent by ARM should have arrived yesterday in the fdio lab. I *think* that all that is required should be to set the platforms with VMs on it, and add them as build slaves. How should we proceed from here ? -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev<https://url10.mailanyone.net/v1/?m=1eFMO4-0003qy-3d&i=57e1b682&c=O-sOs62iGkWatuIJLF4pSNDFFDG_8um2QvdTETSQnD4jA_r85x5l3Bf9qR7RJOonGi8xR9maOtNIkz_rsQpdGbKdnto4CMf5I6HVz8Fuvf8O0wwee8-H8NvmJBdthBWC63GiIordZqRTRpRonu_3HYVrEaz6pXyeEfp8SJT-AIJcmOBjMOnpVKHsnhio6kL9OijBIEROG5XpLW17H5dWsTPN_m3L28C7CUR0SBZauSoF89B0-0AT5GkPjJWEt4UQ> ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] vpp continuous integration on armv8
Hi, We've been working on preparing vpp for armv8 continuous testing (See https://wiki.fd.io/view/VPP/AArch64), and we think that we now have everything which is required to add arm as ci platform in the vpp review process (build, test and packaging). All the test have been done on "native". Also 3 thunderX platforms sent by ARM should have arrived yesterday in the fdio lab. I *think* that all that is required should be to set the platforms with VMs on it, and add them as build slaves. How should we proceed from here ? -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] make test-all
Aside from this p2p_ethernet load test, the only failing extended test is the
whole TestVxlanGpe class.
The reason is that scapy 2.3.3 does not know of layer VXLAN, and there is no
scapy patch within vpp to address this.
How do you want to handle this ?
--
Gabriel Ganne
From: vpp-dev-boun...@lists.fd.io on behalf of
Brian Brooks
Sent: Tuesday, November 14, 2017 1:27:47 PM
To: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco); Ole Troan
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] make test-all
It does not complete within 20 minutes on other machines.
> I don't think we should do scale tests as part of verification tests.
Agree
-Original Message-
From: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)
[mailto:ksek...@cisco.com]
Sent: Tuesday, November 14, 2017 2:47 AM
To: Ole Troan
Cc: Dave Barach (dbarach) ; John Lo (loj) ;
Pavel Kotucek -X (pkotucek - PANTHEON TECHNOLOGIES at Cisco)
; vpp-dev@lists.fd.io; Brian Brooks
Subject: Re: [vpp-dev] make test-all
It is ...
it takes ~10 seconds to create 1000 subifs on a beefy UCS and the case tries to
create 10, so that would indicate a runtime of ~16minutes...
Quoting Ole Troan (2017-11-14 03:53:28)
> Klement,
>
> > I don't know what to tell you ... I was never a fan of getting the
> > API trace post test run and putting it into test log (which is the
> > cause of 25MB allocation in this case - it's the CLI output) - from
> > my POV this is duplicate information as every API call is already
> > logged in-place when it's executed... BUT I didn't saw any harm in
> > doing so (besides clutter) and since the "create bazillion
> > subinterfaces" test went in without me being part of review process, I
> > wasn't aware of it...
>
> If this is in test_p2p_ethernet, let me take that out.
> I don't think we should do scale tests as part of verification tests.
> I do not like the path we're on with regards to test run time.
>
> Cheers,
> Ole
>
> > Quoting Dave Barach (dbarach) (2017-11-13 13:33:41)
> >> Try increasing the size of the shared-memory API segment. An allocation of
> >> 25mb is failing. You might ask yourself how sane it is to generate that
> >> much output.
> >>
> >> Thanks… Dave
> >>
> >> -Original Message-
> >> From: vpp-dev-boun...@lists.fd.io
> >> [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Klement Sekera -X
> >> (ksekera - PANTHEON TECHNOLOGIES at Cisco)
> >> Sent: Monday, November 13, 2017 5:27 AM
> >> To: John Lo (loj) ; Pavel Kotucek -X (pkotucek -
> >> PANTHEON TECHNOLOGIES at Cisco) ;
> >> vpp-dev@lists.fd.io; Brian Brooks
> >> Subject: Re: [vpp-dev] make test-all
> >>
> >> So it seems that vpp coredumps while dumping the API trace after
> >> creating all the interfaces...
> >>
> >> (gdb) bt
> >> #0 0x7f14f4b1e428 in __GI_raise (sig=sig@entry=6) at
> >> ../sysdeps/unix/sysv/linux/raise.c:54
> >> #1 0x7f14f4b2002a in __GI_abort () at abort.c:89
> >> #2 0x00405d83 in os_panic () at
> >> /home/ksekera/vpp/build-data/../src/vpp/vnet/main.c:268
> >> #3 0x7f14f5fe5f86 in clib_mem_alloc_aligned_at_offset
> >> (os_out_of_memory_on_failure=1, align_offset=0, align=1, size=25282098)
> >>at /home/ksekera/vpp/build-data/../src/vppinfra/mem.h:105
> >> #4 clib_mem_alloc (size=25282098) at
> >> /home/ksekera/vpp/build-data/../src/vppinfra/mem.h:114
> >> #5 vl_msg_api_alloc_internal (may_return_null=0, pool=,
> >> nbytes=25282098)
> >>at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_shared.c:176
> >> #6 vl_msg_api_alloc (nbytes=nbytes@entry=25282082) at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_shared.c:207
> >> #7 0x00411392 in vl_api_cli_inband_t_handler
> >> (mp=0x300e2a0c) at
> >> /home/ksekera/vpp/build-data/../src/vpp/api/api.c:223
> >> #8 0x7f14f5fdfa23 in vl_msg_api_handler_with_vm_node
> >> (am=am@entry=0x7f14f620d460 , the_msg=the_msg@entry=0x300e2a0c,
> >>vm=vm@entry=0x7f14f5fd6260 ,
> >> node=node@entry=0x7f14b410e000) at
> >> /home/ksekera/vpp/build-data/../src/vlibapi/api_shared.c:508
> >> #9 0x7f14f5fef35f in memclnt_process (vm=0x7f14f5fd6260
> >> , node=0x7f14b410e000, f=)
> >>at
> >> /home/ksekera/vpp/build-data/../src/vlibmemory/memory_vlib.c:970
> >>
> >> (gdb) p input
> >> $5 = {buffer = 0x7f14b56f6558 "dump
> >> /tmp/vpp-unittest
Re: [vpp-dev] make test-all
Hi Klement, Are those extended tests run on a regular basis anywhere ? I do not see them called within any of the the continuous integration tests. Regards, -- Gabriel Ganne From: vpp-dev-boun...@lists.fd.io on behalf of Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) Sent: Saturday, November 11, 2017 10:12:55 PM To: vpp-dev@lists.fd.io; Brian Brooks; Pavel Kotucek -X (pkotucek - PANTHEON TECHNOLOGIES at Cisco); John Lo (loj) Subject: Re: [vpp-dev] make test-all Hi Brian, it should. Though I just tried running it on latest master and got a timeout in test_p2p_ethernet, which shouldn't happen. I see the test was trying to create tens of thousands of interfaces... maybe something is slower than usual? Thanks, Klement Quoting Brian Brooks (2017-11-11 01:11:47) >Should “make test-all” pass? > > > >Thanks, > >Brian > > > >IMPORTANT NOTICE: The contents of this email and any attachments are >confidential and may also be privileged. If you are not the intended >recipient, please notify the sender immediately and do not disclose the >contents to any other person, use it for any purpose, or store or copy the >information in any medium. Thank you. ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] scapy enable_geneve.patch fail to apply
Hi, I notice that the enable_geneve patch fails to apply to scapy. However, the Geneve tests pass successfully. For example : https://jenkins.fd.io/job/vpp-verify-master-ubuntu1604/7705/console 16:57:46 Applying patch: enable_geneve.patch 16:57:46 patching file scapy/config.py 16:57:46 Hunk #1 FAILED at 439. 16:57:46 1 out of 1 hunk FAILED -- saving rejects to file scapy/config.py.rej Best regards, -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] gerrit http authentication
Yes, I do. Pulling works fine, only the review action is an issue. This is what shoud correspond to (previously) "HTTP Password" in the gerrit settings menu. The gerrit link seems to be still active : https://gerrit.fd.io/r/#/settings/http-password However, the functionnality itself is deactivated -- Gabriel Ganne From: Luke, Chris Sent: Thursday, October 19, 2017 1:50:30 PM To: Gabriel Ganne; vpp-dev@lists.fd.io Subject: RE: gerrit http authentication Just to be unambiguous for the archives, you mean HTTP authentication when pushing patches to Gerrit with Git, and not interactive browsing of the UI? Chris. From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Gabriel Ganne Sent: Thursday, October 19, 2017 4:13 To: vpp-dev@lists.fd.io Subject: [vpp-dev] gerrit http authentication Hi, Unless I'm mistaken, it seems http authentication has been removed from gerrit. It was useful to me, as I work in a company where any non-http traffic is blocked. Do you think it's possible to restore it ? Best regards, -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] gerrit http authentication
Hi, Unless I'm mistaken, it seems http authentication has been removed from gerrit. It was useful to me, as I work in a company where any non-http traffic is blocked. Do you think it's possible to restore it ? Best regards, -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] vpp deadlock - syslog in signal handler
Hi, I have encountered a deadlock in vpp on the raising of a memory alloc exception. The signal is caught by unix_signal_handler(), which determines this is a fatal error and then syslogs the error message. The problem is that syslog() then tries to allocate a scratchpad memory, and deadlocks since allocation is the reason why I'm here in the first place. clib_warning() functions should be safe because all the memory needed is alloc'ed at init, but I don't see how this syslog() call can succeed. Should I just remove it ? Or is there a way I don't know about to still make this work ? Below is a backtrace of the problem: #0 0xa42e2c0c in __lll_lock_wait_private (futex=futex@entry=0xa43869a0 ) at ./lowlevellock.c:33 #1 0xa426b6e8 in __GI___libc_malloc (bytes=bytes@entry=584) at malloc.c:2888 #2 0xa425ace8 in __GI___open_memstream (bufloc=0x655b4670, bufloc@entry=0x655b46d0, sizeloc=0x655b4678, sizeloc@entry=0x655b46d8) at memstream.c:76 #3 0xa42cef18 in __GI___vsyslog_chk (ap=..., fmt=0xa4be2990 "%s", flag=-1, pri=27) at ../misc/syslog.c:167 #4 __syslog (pri=pri@entry=27, fmt=fmt@entry=0xa4be2990 "%s") at ../misc/syslog.c:117 #5 0xa4bd7ab4 in unix_signal_handler (signum=, si=, uc=) at /home/gannega/vpp/build-data/../src/vlib/unix/main.c:119 #6 #7 0xa42654e0 in malloc_consolidate (av=av@entry=0xa43869a0 ) at malloc.c:4182 #8 0xa4269354 in malloc_consolidate (av=0xa43869a0 ) at malloc.c:4151 #9 _int_malloc (av=av@entry=0xa43869a0 , bytes=bytes@entry=32816) at malloc.c:3450 #10 0xa426b5b4 in __GI___libc_malloc (bytes=bytes@entry=32816) at malloc.c:2890 #11 0xa4299000 in __alloc_dir (statp=0x655b5d48, flags=0, close_fd=true, fd=5) at ../sysdeps/posix/opendir.c:247 #12 opendir_tail (fd=) at ../sysdeps/posix/opendir.c:145 #13 __opendir (name=name@entry=0xa4bdf258 "/sys/bus/pci/devices") at ../sysdeps/posix/opendir.c:200 #14 0xa4bde088 in foreach_directory_file (dir_name=dir_name@entry=0xa4bdf258 "/sys/bus/pci/devices", f=f@entry=0xa4baf4a8 , arg=arg@entry=0xa4c0af30 , scan_dirs=scan_dirs@entry=0) at /home/gannega/vpp/build-data/../src/vlib/unix/util.c:59 #15 0xa4baed64 in linux_pci_init (vm=0xa4c0af30 ) at /home/gannega/vpp/build-data/../src/vlib/linux/pci.c:648 #16 0xa4bae504 in vlib_call_init_exit_functions (vm=0xa4c0af30 , head=, call_once=call_once@entry=1) at /home/gannega/vpp/build-data/../src/vlib/init.c:57 #17 0xa4bae548 in vlib_call_all_init_functions (vm=) at /home/gannega/vpp/build-data/../src/vlib/init.c:75 #18 0xa4bb3838 in vlib_main (vm=, vm@entry=0xa4c0af30 , input=input@entry=0x655b5fc8) at /home/gannega/vpp/build-data/../src/vlib/main.c:1748 #19 0xa4bd7c0c in thread0 (arg=281473445834544) at /home/gannega/vpp/build-data/../src/vlib/unix/main.c:567 #20 0xa44f3e38 in clib_calljmp () at /home/gannega/vpp/build-data/../src/vppinfra/longjmp.S:676 Best regards, -- Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] https://gerrit.fd.io/r/#/c/8236/
I had not thought of that. Thank you for explaining this.
--
Gabriel Ganne
From: Thomas F Herbert
Sent: Wednesday, August 30, 2017 9:30:20 PM
To: Gabriel Ganne; Dave Wallace; Burt Silverman
Cc: vpp-dev
Subject: Re: [vpp-dev] https://gerrit.fd.io/r/#/c/8236/
On 08/30/2017 01:57 PM, Gabriel Ganne wrote:
<https://url10.mailanyone.net/v1/?m=1dn8h3-00048d-3t&i=57e1b682&c=gCLxW44-FKIejwC6mcn9CN9uavjLkHVE-h3pjjGdxaS47X9cA51vAOXLJcnoAyHjovBk79EbyB2_g0KUbZwWuGloomcbP4N4aeC3NSnULZTdyEAdHP6dcjNMjEsHg0nV--NOGC-inNCysJEIIWXXJes_x7CMnyZOmfH-wcmYnKQ9ocKaXKNcU3Se9njfoPS2mppBJ0eIdzi4Z2JEWbg9ckFopZbOOJMeiwhcteVQULg>https://gerrit.fd.io/r/#/c/8260/<https://url10.mailanyone.net/v1/?m=1dn8h3-00048d-3t&i=57e1b682&c=gCLxW44-FKIejwC6mcn9CN9uavjLkHVE-h3pjjGdxaS47X9cA51vAOXLJcnoAyHjovBk79EbyB2_g0KUbZwWuGloomcbP4N4aeC3NSnULZTdyEAdHP6dcjNMjEsHg0nV--NOGC-inNCysJEIIWXXJes_x7CMnyZOmfH-wcmYnKQ9ocKaXKNcU3Se9njfoPS2mppBJ0eIdzi4Z2JEWbg9ckFopZbOOJMeiwhcteVQULg>
It adds bc to the dependency list, but also replaces a $(shell $(echo …)) by
$(shell `echo …`)
They should be the same, but it seems to change the way the Makefile variables
are interpreted.
The problem I saw was on Fedora and Centos both of which have bc. The problem
it needs a double $
to escape the "$()" from make because it "thinks" it is a reference to a
variable.
commit 14afc64629e9b35a2e5c5941232236a78c2ecd75
Author: Thomas F Herbert <mailto:therb...@redhat.com>
Date: Wed Aug 30 10:13:51 2017 -0400
Fix shell error.
Change-Id: I06af51eef20c2191199613f951f569ef1727b9c4
Signed-off-by: Thomas F Herbert
<mailto:therb...@redhat.com>
diff --git a/Makefile b/Makefile
index 1548f36..ef92e2f 100644
--- a/Makefile
+++ b/Makefile
@@ -78,7 +78,7 @@ ifeq ($(OS_ID)-$(OS_VERSION_ID),fedora-25)
RPM_DEPENDS += python-devel
RPM_DEPENDS += python2-virtualenv
RPM_DEPENDS_GROUPS = 'C Development Tools and Libraries'
-else ifeq ($(shell if [ $(echo "$(OS_VERSION_ID) > 25" | bc) -eq 1 ] ; then
echo "y" ; fi),"y")
+else ifeq ($(shell if [ $$(echo "$(OS_VERSION_ID) > 25" | bc) -eq 1 ] ; then
echo "y" ; fi),"y")
RPM_DEPENDS += python2-devel
RPM_DEPENDS += python2-virtualenv
RPM_DEPENDS_GROUPS = 'C Development Tools and Libraries'
I tested on rhel 7, Ubuntu 16.04, and debian 8.
Best regards,
--
Gabriel Ganne
From: Dave Wallace [mailto:dwallac...@gmail.com]
Sent: mercredi 30 août 2017 16:27
To: Burt Silverman <mailto:bur...@gmail.com>; Gabriel Ganne
<mailto:gabriel.ga...@enea.com>
Cc: Thomas F Herbert <mailto:therb...@redhat.com>; vpp-dev
<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev]
https://gerrit.fd.io/r/#/c/8236/<https://url10.mailanyone.net/v1/?m=1dn8h3-00048d-3t&i=57e1b682&c=Qol4TcBRxO9D_O64VRs0CgFCFJK2hiP4hrIKZP9195yN9p7TFAOLajJIF6OwFCJ5zp3NMHGxL_tYAlCyVVtUBn5SNubwDRyTKCpM9gW--uqCidbD7v5OPxora9FD53IfkvSCvCADWg42d1dp2Z5EZy3_ARIy2fPoPMW0JhKWnQSw2rFaeziZkskQ2vGyTFPjWBT4ZmGi7fvou5cfPMYTPTM0LpaXtDIVUntFZ4iwqPc>
I agree.
@Gabriel, please push a patch which adds bc to DEB_DEPENDS in vpp/Makefile.
Thanks,
-daw-
On 08/30/2017 09:14 AM, Burt Silverman wrote:
To me, it doesn't seem to be a crime to add bc to the dependencies. I guess
another approach would be to remove the dot in 16dot04 and then just use shell
arithmetic. The release numbers are always in the same format, 2 digits DOT 2
digits, so I would think that should work.
Burt
On Wed, Aug 30, 2017 at 3:47 AM, Gabriel Ganne
mailto:gabriel.ga...@enea.com>> wrote:
Hi,
This probably is be because you don't have bc.
It is not in the dependency list. I'm so used to having it around that I did
not think to check.
Sorry.
If so, the best thing probably is to revert and not to increase the dependency
list just to silence a warning.
Regards,
--
Gabriel Ganne
From: Dave Wallace mailto:dwallac...@gmail.com>>
Sent: Wednesday, August 30, 2017 6:25:32 AM
To: Thomas F Herbert; Gabriel Ganne
Cc: vpp-dev
Subject: Re: [vpp-dev]
<https://url10.mailanyone.net/v1/?m=1dn3xX-0006Hd-50&i=57e1b682&c=cStJh6yQU2F9FWBIKNcsjRgTf-ntcQfeHTWOgVHSer9pSh1n2Ke77HoWikhOjcSWh0z-O2rHVl18yF2FOHhjhruUhq8VyojK4u6e0BbsFIHZleaRifwRLCWsosaGdVw__FJqiQlIB_Gvaa1w9Jm_gQAlPYBetc4L-9HozLkobTyK5775Sj6qZDN6ijVpzsIcF1ulKmuWUEnw9sNtRAXHMyDXYthGBQFz_EFyNSgCszs>
https://gerrit.fd.io/r/#/c/8236/<https://url10.mailanyone.net/v1/?m=1dn8h3-00048d-3t&i=57e1b682&c=Qol4TcBRxO9D_O64VRs0CgFCFJK2hiP4hrIKZP9195yN9p7TFAOLajJIF6OwFCJ5zp3NMHGxL_tYAlCyVVtUBn5SNubwDRyTKCpM9gW--uqCidbD7v5OPxora9FD53IfkvSCvCADWg42d1dp2Z5EZy3_ARIy2fPoPMW0JhKWnQSw2rFaeziZkskQ2vGyTFPjWBT4ZmGi7fvou5cfPMYTPTM0LpaXtDIVUntFZ4iwqPc>
Tom,
What OS are you running?
Thanks,
-daw-
On 08/29/2017 07:58 PM, Thomas F
Re: [vpp-dev] https://gerrit.fd.io/r/#/c/8236/
https://gerrit.fd.io/r/#/c/8260/ It adds bc to the dependency list, but also replaces a $(shell $(echo …)) by $(shell `echo …`) They should be the same, but it seems to change the way the Makefile variables are interpreted. I tested on rhel 7, Ubuntu 16.04, and debian 8. Best regards, -- Gabriel Ganne From: Dave Wallace [mailto:dwallac...@gmail.com] Sent: mercredi 30 août 2017 16:27 To: Burt Silverman ; Gabriel Ganne Cc: Thomas F Herbert ; vpp-dev Subject: Re: [vpp-dev] https://gerrit.fd.io/r/#/c/8236/ I agree. @Gabriel, please push a patch which adds bc to DEB_DEPENDS in vpp/Makefile. Thanks, -daw- On 08/30/2017 09:14 AM, Burt Silverman wrote: To me, it doesn't seem to be a crime to add bc to the dependencies. I guess another approach would be to remove the dot in 16dot04 and then just use shell arithmetic. The release numbers are always in the same format, 2 digits DOT 2 digits, so I would think that should work. Burt On Wed, Aug 30, 2017 at 3:47 AM, Gabriel Ganne mailto:gabriel.ga...@enea.com>> wrote: Hi, This probably is be because you don't have bc. It is not in the dependency list. I'm so used to having it around that I did not think to check. Sorry. If so, the best thing probably is to revert and not to increase the dependency list just to silence a warning. Regards, -- Gabriel Ganne From: Dave Wallace mailto:dwallac...@gmail.com>> Sent: Wednesday, August 30, 2017 6:25:32 AM To: Thomas F Herbert; Gabriel Ganne Cc: vpp-dev Subject: Re: [vpp-dev] https://gerrit.fd.io/r/#/c/8236/<https://url10.mailanyone.net/v1/?m=1dn3xX-0006Hd-50&i=57e1b682&c=cStJh6yQU2F9FWBIKNcsjRgTf-ntcQfeHTWOgVHSer9pSh1n2Ke77HoWikhOjcSWh0z-O2rHVl18yF2FOHhjhruUhq8VyojK4u6e0BbsFIHZleaRifwRLCWsosaGdVw__FJqiQlIB_Gvaa1w9Jm_gQAlPYBetc4L-9HozLkobTyK5775Sj6qZDN6ijVpzsIcF1ulKmuWUEnw9sNtRAXHMyDXYthGBQFz_EFyNSgCszs> Tom, What OS are you running? Thanks, -daw- On 08/29/2017 07:58 PM, Thomas F Herbert wrote: This patch creates may have fixed one problem with Ubuntu 16.04 but created another: $ make /bin/sh: line 0: [: -eq: unary operator expected ... -- Thomas F Herbert NFV and Fast Data Planes Office of Technology Red Hat ___ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev<https://url10.mailanyone.net/v1/?m=1dmuZP-0007YU-5v&i=57e1b682&c=Qsrdfe_DPl_SvvWzv--VtKCBJOKVTEg4VL0ZnkHG2v411y213_M9DM_3rjAI_f7X2ifYtM6xQxMwYWfBDcZTqZxJaNy5yHnZcs5MFE_YJQCWz0i2q6fT4KpnC8m_c_MsVfHOcIcUpBQ7dUboUbtyy5Ey7roG_YlGZSbaOR7rmgDeloqmgdxJ1d-Duo6FX-6ARriIWYlW9895XudmB85pM0kVgfReq85yx9Z-4QG_addHGYW74uqlKVoVuMF6O6ni> ___ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev<https://url10.mailanyone.net/v1/?m=1dn3xX-0006Hd-50&i=57e1b682&c=EqcMBcwLbPIpILbjmEVtzuPv1tv4iapVkLyJrlkzz0UhLpP0wGZLZTNDpeO9UJwtlk5EUSaYSRG16iZ7f2x6tCkRecTwkKo0B_NuE_yrCrMiUQkJOqx1KujPdKYakBj_Atb8EfOWXBZKXVyuTR9G29RBJTGbbvTxPxqont1wC6CbeyJKvJl38VYK9MYuVFMgA_-dnpOGR8Z9eXz6SHF8BJiilA1Y4WPLHciUK_1mBxXF3894rogQEQxZSVdIRm8q> ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] https://gerrit.fd.io/r/#/c/8236/
Hi, This probably is be because you don't have bc. It is not in the dependency list. I'm so used to having it around that I did not think to check. Sorry. If so, the best thing probably is to revert and not to increase the dependency list just to silence a warning. Regards, -- Gabriel Ganne From: Dave Wallace Sent: Wednesday, August 30, 2017 6:25:32 AM To: Thomas F Herbert; Gabriel Ganne Cc: vpp-dev Subject: Re: [vpp-dev] https://gerrit.fd.io/r/#/c/8236/ Tom, What OS are you running? Thanks, -daw- On 08/29/2017 07:58 PM, Thomas F Herbert wrote: This patch creates may have fixed one problem with Ubuntu 16.04 but created another: $ make /bin/sh: line 0: [: -eq: unary operator expected ... -- Thomas F Herbert NFV and Fast Data Planes Office of Technology Red Hat ___ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev<https://url10.mailanyone.net/v1/?m=1dmuZP-0007YU-5v&i=57e1b682&c=Qsrdfe_DPl_SvvWzv--VtKCBJOKVTEg4VL0ZnkHG2v411y213_M9DM_3rjAI_f7X2ifYtM6xQxMwYWfBDcZTqZxJaNy5yHnZcs5MFE_YJQCWz0i2q6fT4KpnC8m_c_MsVfHOcIcUpBQ7dUboUbtyy5Ey7roG_YlGZSbaOR7rmgDeloqmgdxJ1d-Duo6FX-6ARriIWYlW9895XudmB85pM0kVgfReq85yx9Z-4QG_addHGYW74uqlKVoVuMF6O6ni> ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] VPP Python API for create host-interface ?
Hi,
You should name the arguments you pass to the functions.
If you haven't yet, I advise you to have a look here :
https://wiki.fd.io/view/VPP/Python_API which contains some small samples using
the python API.
Regards,
-Original Message-
From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
Behalf Of Shravan Ambati
Sent: mardi 21 mars 2017 22:07
To: otr...@employees.org
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP Python API for create host-interface ?
Thanks Ole!
I did try it before. I ran into issues when I invoke the API.
>>> r = vpp.af_packet_create(veth0-craft0)
Traceback (most recent call last):
File "", line 1, in
NameError: name 'veth0' is not defined
>>> r = vpp.af_packet_create('veth0-craft0')
Traceback (most recent call last):
File "", line 1, in
TypeError: () takes exactly 0 arguments (1 given)
>>> r = vpp.af_packet_create(1)
Traceback (most recent call last):
File "", line 1, in
TypeError: () takes exactly 0 arguments (1 given)
I am a python newbie, so please excuse my naïve question.
This is probably not a vpp issue. I must be invoking the Api wrong way.
Do you happen to know by any chance what is the right way to invoke it?
Thanks
Shravan
-Original Message-
From: otr...@employees.org [mailto:otr...@employees.org]
Sent: Tuesday, March 21, 2017 5:33 AM
To: Shravan Ambati
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP Python API for create host-interface ?
Hi there,
> I am running the latest vpp code from master branch.
> I am looking at the python APIs that vpp provides.
> I am specifically trying to find the API for the following cli command
> - create host-interface []
>
> I could not find where exactly this is defined in the json files in
> /usr/shar/vpp/api/ Or is this not supported through API ?
Looks like we're not quite consistent on naming.
It is this API you are looking for I think:
/** \brief Create host-interface
@param client_index - opaque cookie to identify the sender
@param context - sender context, to match reply w/ request
@param host_if_name - interface name
@param hw_addr - interface MAC
@param use_random_hw_addr - use random generated MAC */ define
af_packet_create {
u32 client_index;
u32 context;
u8 host_if_name[64];
u8 hw_addr[6];
u8 use_random_hw_addr;
};
Best regards,
Ole
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] libpneum compilation flags
Hi Burt, Thank you for your input. I pushed a new version of my commit (https://gerrit.fd.io/r/#/c/4576/) where I tried to do things more clearly. I had a look here https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/cacheinfo.c and it seems that on arm64, recent kernels should be able return a correct value. Which means that some day, they will. Old ones will fallback to 64 Bytes. Maybe someone who has a thunder platform can try it in order to see what getconf returns him. Gabriel Ganne From: Burt Silverman Sent: Friday, February 10, 2017 3:53:19 PM To: Gabriel Ganne Cc: vpp-dev@lists.fd.io; Ole Troan (otroan); Damjan Marion (damarion) Subject: Re: [vpp-dev] libpneum compilation flags Hi Gabriel, I do not fully understand the mechanisms for all processors, and being that is the case, perhaps you can add a lot of comments to configure.ac<http://configure.ac>. I believe that the getconf command uses information from glibc/sysdeps/x86/cacheinfo.c, which uses information from the CPUID instruction of the processor, and tabulated information based on same; for the intel x86 case. I am under the impression that there is no ARM support, as there is none under glibc/sysdeps, and based upon https://bugzilla.redhat.com/show_bug.cgi?id=1190638. (Of course, I am referring to native compilation. And I don't have an ARM here to test.) The bottom line is that, in my opinion, it would not hurt to add some hints and clues using comments in configure.ac<http://configure.ac> so that somebody has a reasonably easy chance to figure out where the settings are originating from, for all interesting cases. And remember that the reader should not have to depend on searching through git commit comments for that purpose. Thanks, Gabriel. Burt On Fri, Feb 10, 2017 at 5:52 AM, Gabriel Ganne mailto:gabriel.ga...@enea.com>> wrote: Hi, I am currently working on a patch to auto-detect the cache line size with a m4 macro in autoconf (https://gerrit.fd.io/r/#/c/4576/) Part of it updates cache.h tests so that it raises an error if the cache line length is undefined. I am stuck at the libpneum compilation: it's a python module, so it has its compilation flags defined in setup.py. This means that the vpp flags are not propagated to the libpneum, and I believe this is a bug. I think the python api and the libpneum will get big changes soon anyway ... How do you think I should handle this ? Best regards, Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] libpneum compilation flags
Hi Ole, Sure, I'll wait for your CFFI patch. It does not seem ready yet, but ping me if you wish me to test it once you think it is. Thanks, Gabriel Ganne From: otr...@employees.org Sent: Friday, February 10, 2017 12:14:52 PM To: Gabriel Ganne Cc: vpp-dev@lists.fd.io; Damjan Marion (damarion) Subject: Re: [vpp-dev] libpneum compilation flags Gabriel, > I am currently working on a patch to auto-detect the cache line size with a > m4 macro in autoconf (https://gerrit.fd.io/r/#/c/4576/) > Part of it updates cache.h tests so that it raises an error if the cache line > length is undefined. > > I am stuck at the libpneum compilation: it's a python module, so it has its > compilation flags defined in setup.py. > This means that the vpp flags are not propagated to the libpneum, and I > believe this is a bug. > I think the python api and the libpneum will get big changes soon anyway ... > > How do you think I should handle this ? Can you wait a few days? Or try with my CFFI patch? The idea is to remove the C/Python vpp_api.so completely, and make the Python module pure Python. And libpenum completely built from within the VPP make system. Cheers, Ole ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] libpneum compilation flags
Hi, I am currently working on a patch to auto-detect the cache line size with a m4 macro in autoconf (https://gerrit.fd.io/r/#/c/4576/) Part of it updates cache.h tests so that it raises an error if the cache line length is undefined. I am stuck at the libpneum compilation: it's a python module, so it has its compilation flags defined in setup.py. This means that the vpp flags are not propagated to the libpneum, and I believe this is a bug. I think the python api and the libpneum will get big changes soon anyway ... How do you think I should handle this ? Best regards, Gabriel Ganne ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] vpp build failure while creating rpm package
Hi Yusuf, I wrote a small patch which is supposed to take care of this issue : https://gerrit.fd.io/r/#/c/4894/ I believe it was merged this morning. If you're not upstream, please pull and try again. Otherwise tell me so I'll look into what can cause this. Best regards, Gerrit Code Review<https://gerrit.fd.io/r/#/c/4894/> gerrit.fd.io ©2016 FD.io a Linux Foundation Collaborative Project. All Rights Reserved. Linux Foundation is a registered trademark of The Linux Foundation. Gabriel Ganne From: vpp-dev-boun...@lists.fd.io on behalf of yusuf khan Sent: Friday, January 27, 2017 4:44:20 PM To: vpp-dev@lists.fd.io Subject: [vpp-dev] vpp build failure while creating rpm package Hi Team, I am able to build vpp on centos vm but it failes while creating the rpm package. with below error. All the dependencies are installed. --- Processing files: vpp-debuginfo-17.04-rc0~141_g1730077.x86_64 Provides: vpp-debuginfo = 17.04-rc0~141_g1730077 vpp-debuginfo(x86-64) = 17.04-rc0~141_g1730077 Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 Checking for unpackaged file(s): /usr/lib/rpm/check-files /vpp/build-root/rpm/BUILDROOT/vpp-17.04-rc0~141_g1730077.x86_64 error: Installed (but unpackaged) file(s) found: /usr/bin/dpdk-pdump /usr/bin/dpdk-pmdinfo /usr/bin/dpdk-procinfo /usr/bin/testpmd RPM build errors: File not found: /vpp/build-root/rpm/BUILDROOT/vpp-17.04-rc0~141_g1730077.x86_64/usr/lib64/vpp_plugins File not found: /vpp/build-root/rpm/BUILDROOT/vpp-17.04-rc0~141_g1730077.x86_64/usr/lib64/vpp_api_test_plugins Installed (but unpackaged) file(s) found: /usr/bin/dpdk-pdump /usr/bin/dpdk-pmdinfo /usr/bin/dpdk-procinfo /usr/bin/testpmd make[1]: *** [install-rpm] Error 1 make[1]: Leaving directory `/vpp/build-root' make: *** [pkg-rpm] Error 2 [vagrant@pktgen vpp]$ ls --- The host OS is ubuntu 16.04. Just for information, debian package creation is successful on ubuntu-14.04 vm. Thanks in advance for help. Regards, Yusuf ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] trace packets going through the handoff node
Hi, I am using vpp's handoff node to dispatch some traffic (generated with dpdk pktgen) on two threads, and it seems that if I add a trace on the packets, they change their path in the node graph. The packets usually leave the handoff node by ethernet-input, but the traced packets go to the ip4 next node instead. The trace api does not seem to make use of the vnet buffer opaque field, nor anything I could find which would conflict with the handoff node. I've attached my conf and the vppctl commands I used to reproduce this. So, what's happening ? If there is a bug, any pointers to help me fix it would be welcome. Regards, -- Gabriel Ganne This message and any attachments (the "message") are confidential, intended solely for the addressees. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any other person. E-mails are susceptible to alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont confidentiels et ?tablis ? l'intention exclusive de ses destinataires. Si vous avez re?u ce message par erreur, merci d'en informer imm?diatement son ?metteur par courrier ?lectronique et d'effacer ce message de votre syst?me. Dans cette hypoth?se, vous n'?tes pas autoris? ? utiliser, copier ce message et/ou en divulguer le contenu ? un tiers. Tout message ?lectronique est susceptible d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? au titre de ce message s'il a ?t? alt?r?, d?form? ou falsifi?. handoff-test-startup.conf Description: handoff-test-startup.conf handoff-test.vppctl Description: handoff-test.vppctl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
