Re: [vpp-dev] Unable to build router plugin

[Ni, Hongjun]

Hi Carlito,

We are working on porting VPPSB/netlink & router plugins into VPP main repo.
Please see below patch, which is under review:
https://gerrit.fd.io/r/#/c/15062/ Port VPPSB's rtnetlink & router plugin to VPP 
main repo

I have tested this patch and it works well.

Thanks,
Hongjun

-Original Message-
From: Carlito Nueno [mailto:carlitonu...@gmail.com] 
Sent: Thursday, October 18, 2018 11:16 AM
To: Ni, Hongjun 
Cc: Mehran Memarnejad ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Unable to build router plugin

Hi Hongjun,

Thanks for the patch.
I tried to compile VPPSB project with the latest master and latest VPP
stable/1810 but I am getting this error:

 Building router in /vpp/build-root/build-vpp_debug-native/router 
make[1]: Entering directory '/vpp/build-root/build-vpp_debug-native/router'
  CC   router/tap_inject.lo
  CC   router/tap_inject_netlink.lo
  CC   router/tap_inject_node.lo
  CC   router/tap_inject_tap.lo
/vpp/build-data/../router/router/tap_inject_node.c: In function
‘tap_inject_tap_send_buffer’:
/vpp/build-data/../router/router/tap_inject_node.c:45:13: error:
implicit declaration of function ‘writev’; did you mean ‘write’?
[-Werror=implicit-function-declaration]
   n_bytes = writev (fd, , 1);
 ^~
 write
/vpp/build-data/../router/router/tap_inject_node.c: In function ‘tap_rx’:
/vpp/build-data/../router/router/tap_inject_node.c:231:13: error:
implicit declaration of function ‘readv’; did you mean ‘read’?
[-Werror=implicit-function-declaration]
   n_bytes = readv (fd, iov, MTU_BUFFERS);
 ^
 read
cc1: all warnings being treated as errors
Makefile:483: recipe for target 'router/tap_inject_node.lo' failed
make[1]: *** [router/tap_inject_node.lo] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/vpp/build-root/build-vpp_debug-native/router'
Makefile:691: recipe for target 'router-build' failed
make: *** [router-build] Error 2

Thanks
On Sun, Oct 7, 2018 at 7:25 PM Ni, Hongjun  wrote:
>
> Hi guys,
>
> I have submitted a patch to fix the build issue in VPPSB project:
> https://gerrit.fd.io/r/#/c/15135/ Fix build issue due to vpp's 
> function parameters change I have tested it and it works well in my server.
>
> Thanks,
> Hongjun
>
> -Original Message-
> From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of 
> carlito nueno
> Sent: Friday, September 28, 2018 9:45 AM
> To: memarnejad...@gmail.com
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Unable to build router plugin
>
> Thanks for the tip Mehran. I will take a look and report back.
> On Thu, Sep 27, 2018 at 12:16 AM Mehran Memarnejad  
> wrote:
> >
> > Hi carlito,
> >
> > I've had problems muck like yours. Sometimes VPP updates its functions 
> > while vppsb is still the same, so you need to change it to make it work.
> > In my problem I just updated the vppsb's outdated function to the new one 
> > and it worked.
> > As you know, vppsb is a plugin for vpp and it calls vpp's functions, 
> > so any change in vpp's function affects vppsb e.g. function 
> > singnature change
> >
> >
> > On Thursday, September 27, 2018, carlito nueno  
> > wrote:
> >>
> >> Hi all,
> >>
> >> I am trying to build the router-plugin:
> >> make V=0 PLATFORM=vpp TAG=vpp_debug install-deb netlink-install 
> >> router-install
> >>
> >> I am using the Vagrantfile present in vpp repo and am pulling the 
> >> current master (as of September 26 2018). I am also pulling the 
> >> current master of vppsb.
> >>
> >> But I am getting this error:
> >>
> >>  Building router in 
> >> /vpp/build-root/build-vpp_debug-native/router
> >> 
> >> make[1]: Entering directory '/vpp/build-root/build-vpp_debug-native/router'
> >>   CC   router/tap_inject.lo
> >>   CC   router/tap_inject_netlink.lo
> >> /vpp/build-data/../router/router/tap_inject_netlink.c: In function
> >> ‘add_del_neigh’:
> >> /vpp/build-data/../router/router/tap_inject_netlink.c:140:9: error:
> >> too many arguments to function ‘vnet_unset_ip6_ethernet_neighbor’
> >>  vnet_unset_ip6_ethernet_neighbor (vm, sw_if_index,
> >>  ^~~~ In file included from
> >> /vpp/build-data/../router/router/tap_inject_netlink.c:19:0:
> >> /vpp/build-root/install-vpp_debug-native/vpp/include/vnet/ip/ip6_neighbor.h:84:12:
> >> note: declared here
> >>  extern int vnet_unset_ip6_ethernet_neighbor (vlib_main_t * vm,
> >> ^~~~
> >> Makefile:483: recipe for target 'router/tap_inject_netlink.lo' 
> >> failed
> >> make[1]: *** [router/tap_inject_netlink.lo] Error 1
> >> make[1]: *** Waiting for unfinished jobs
> >> make[1]: Leaving directory '/vpp/build-root/build-vpp_debug-native/router'
> >> Makefile:691: recipe for target 'router-build' failed
> >> make: *** [router-build] Error 2
> >>
> >> Any advice?
> >>
> >> Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

Re: [vpp-dev] Unable to build router plugin

[carlito nueno]

Hi Hongjun,

Thanks for the patch.
I tried to compile VPPSB project with the latest master and latest VPP
stable/1810 but I am getting this error:

 Building router in /vpp/build-root/build-vpp_debug-native/router 
make[1]: Entering directory '/vpp/build-root/build-vpp_debug-native/router'
  CC   router/tap_inject.lo
  CC   router/tap_inject_netlink.lo
  CC   router/tap_inject_node.lo
  CC   router/tap_inject_tap.lo
/vpp/build-data/../router/router/tap_inject_node.c: In function
‘tap_inject_tap_send_buffer’:
/vpp/build-data/../router/router/tap_inject_node.c:45:13: error:
implicit declaration of function ‘writev’; did you mean ‘write’?
[-Werror=implicit-function-declaration]
   n_bytes = writev (fd, , 1);
 ^~
 write
/vpp/build-data/../router/router/tap_inject_node.c: In function ‘tap_rx’:
/vpp/build-data/../router/router/tap_inject_node.c:231:13: error:
implicit declaration of function ‘readv’; did you mean ‘read’?
[-Werror=implicit-function-declaration]
   n_bytes = readv (fd, iov, MTU_BUFFERS);
 ^
 read
cc1: all warnings being treated as errors
Makefile:483: recipe for target 'router/tap_inject_node.lo' failed
make[1]: *** [router/tap_inject_node.lo] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory '/vpp/build-root/build-vpp_debug-native/router'
Makefile:691: recipe for target 'router-build' failed
make: *** [router-build] Error 2

Thanks
On Sun, Oct 7, 2018 at 7:25 PM Ni, Hongjun  wrote:
>
> Hi guys,
>
> I have submitted a patch to fix the build issue in VPPSB project:
> https://gerrit.fd.io/r/#/c/15135/ Fix build issue due to vpp's function 
> parameters change
> I have tested it and it works well in my server.
>
> Thanks,
> Hongjun
>
> -Original Message-
> From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of carlito 
> nueno
> Sent: Friday, September 28, 2018 9:45 AM
> To: memarnejad...@gmail.com
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Unable to build router plugin
>
> Thanks for the tip Mehran. I will take a look and report back.
> On Thu, Sep 27, 2018 at 12:16 AM Mehran Memarnejad  
> wrote:
> >
> > Hi carlito,
> >
> > I've had problems muck like yours. Sometimes VPP updates its functions 
> > while vppsb is still the same, so you need to change it to make it work.
> > In my problem I just updated the vppsb's outdated function to the new one 
> > and it worked.
> > As you know, vppsb is a plugin for vpp and it calls vpp's functions,
> > so any change in vpp's function affects vppsb e.g. function singnature
> > change
> >
> >
> > On Thursday, September 27, 2018, carlito nueno  
> > wrote:
> >>
> >> Hi all,
> >>
> >> I am trying to build the router-plugin:
> >> make V=0 PLATFORM=vpp TAG=vpp_debug install-deb netlink-install
> >> router-install
> >>
> >> I am using the Vagrantfile present in vpp repo and am pulling the
> >> current master (as of September 26 2018). I am also pulling the
> >> current master of vppsb.
> >>
> >> But I am getting this error:
> >>
> >>  Building router in /vpp/build-root/build-vpp_debug-native/router
> >> 
> >> make[1]: Entering directory '/vpp/build-root/build-vpp_debug-native/router'
> >>   CC   router/tap_inject.lo
> >>   CC   router/tap_inject_netlink.lo
> >> /vpp/build-data/../router/router/tap_inject_netlink.c: In function
> >> ‘add_del_neigh’:
> >> /vpp/build-data/../router/router/tap_inject_netlink.c:140:9: error:
> >> too many arguments to function ‘vnet_unset_ip6_ethernet_neighbor’
> >>  vnet_unset_ip6_ethernet_neighbor (vm, sw_if_index,
> >>  ^~~~ In file included from
> >> /vpp/build-data/../router/router/tap_inject_netlink.c:19:0:
> >> /vpp/build-root/install-vpp_debug-native/vpp/include/vnet/ip/ip6_neighbor.h:84:12:
> >> note: declared here
> >>  extern int vnet_unset_ip6_ethernet_neighbor (vlib_main_t * vm,
> >> ^~~~
> >> Makefile:483: recipe for target 'router/tap_inject_netlink.lo' failed
> >> make[1]: *** [router/tap_inject_netlink.lo] Error 1
> >> make[1]: *** Waiting for unfinished jobs
> >> make[1]: Leaving directory '/vpp/build-root/build-vpp_debug-native/router'
> >> Makefile:691: recipe for target 'router-build' failed
> >> make: *** [router-build] Error 2
> >>
> >> Any advice?
> >>
> >> Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10861): https://lists.fd.io/g/vpp-dev/message/10861
Mute This Topic: https://lists.fd.io/mt/26280661/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vpp crash when handling IGMP with router alert

[Jeff]

Hi Neale,

Thanks for response.  On a quick tangent, your comment about unnecessary work 
got me thinking about these lines at the top of ip4_local_check_src():

vnet_buffer (b)->ip.fib_index =
    vnet_buffer (b)->sw_if_index[VLIB_TX] != ~0 ?
    vnet_buffer (b)->sw_if_index[VLIB_TX] : vnet_buffer (b)->ip.fib_index;

Wouldn't these be unnecessary given that ip_lookup_set_buffer_fib_index() does 
this already?  I guess it depends on what assumptions ip4-local, and 
ip4_local_check_src() specifically, are allowed to make.

Regarding the patch - My initial thought is to call 
ip_lookup_set_buffer_fib_index() directly (from ip4-options) rather than 
copy/paste the two fib_index lines.  If you prefer not using that function let 
me know.

Regarding test_igmp.py - My interface is not in a non-default VRF.  Triggering 
this issue requires setting the fib_index metadata to something invalid 
(recommend ~0) and then reusing that buffer for an IGMP with router alert.

Thanks,
Jeff
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10860): https://lists.fd.io/g/vpp-dev/message/10860
Mute This Topic: https://lists.fd.io/mt/27373338/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] meson build?

[Burt Silverman]

Indeed, it is time to take a break from redoing the build system -
regardless of what is best, it has been through a lot of changes and come a
long way. Taking a break from changing build systems, one can have time to
pursue one of my favorite related things -- IWYU from Google --
https://include-what-you-use.org/ -- okay, I will now continue my reading
of *How To Gain Friends and Influence People*, chuckle! [I had once come up
with some tricks to make IWYU less painful to use for VPP; I'd have to find
it, if possible, if anyone was interested.]

Burt

On Mon, Oct 15, 2018 at 5:51 PM Damjan Marion via Lists.Fd.Io  wrote:

>
>
> > On 15 Oct 2018, at 21:42, Stephen Hemminger 
> wrote:
> >
> > Has VPP ever considered using Meson, which seems to be where most
> userspace
> > projects are headed for build systems.
> >
> > http://mesonbuild.com/Comparisons.html
>
> Before I went into cmake direction, i spent significant amount of time
> looking into meson.
> Actually I come to the point where I am able to build vpp with meson
> generated ninja files.
> I thought, if we are changing let's change to something modern but after
> spending time on it
> i was not convinced it is right way to go. Beside the personal animosity
> towards python based
> tools installed trough pip, i was not able to find quick and obvious way
> to do some "special things" we need
> like multi-versioning. Today we have issues with usable version of cmake
> in CentOS7 so I can
> just guess what will be situation with meson. I guess that is the reason
> why DPDK still
> maintains both Makefiles and meson files, and maintaining both is way we
> don't want to go...
>
> Even on the page you shared there is no major issue highlighted  under
> Cons. - Cumbersome to
> work - yeah, maybe a bit but they have excellent documentation,
>  Some simple things are more complicated than necessary. - hmm, I'm more
> concerned about having
> simple solutions to more complicated things...
>
> Anyway, it is what it is, we moved to cmake recently so it is not right
> time to discuss
> about changing it again, specially without roadblocks in front of us...
>
> --
> Damjan
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#10825): https://lists.fd.io/g/vpp-dev/message/10825
> Mute This Topic: https://lists.fd.io/mt/27333225/541103
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [bur...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10859): https://lists.fd.io/g/vpp-dev/message/10859
Mute This Topic: https://lists.fd.io/mt/27333225/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP and 100G Ethernet

[via Lists.Fd.Io]

Hi,

Thanks Colin, Daniel for the useful feedback.

-- Jordan

> Hi,
> 
> From our side, same experience with ConnectX5 if you can work through
> DPDK/OFED dependencies.
> 
> We also tested the Chelsio 100GE adapters using default DPDK and NAPATECH 2x
> 100GE adapters with optimized DPDK drivers for VPP. Both these adapters
> work really well main challenge is having them supported through commercial
> releases of environments like Red Hat Linux and Openstack.
> 
> We also tested the FM10K adapters but instead of the default Intel drivers,
> we worked with Silicom and leveraged their unified driver to go around the
> complexity of dealing with the switch & dpdk drivers. Excellent support on
> their side to get this rolling quick.
> 
> Cheers,
> 
> Daniel Bernier | Bell Canada
> T: (514) 870-4822 | M: (514) 592-5033
> 
> From: vpp-dev@lists.fd.io  on behalf of colintd via
> Lists.Fd.Io  Sent: Wednesday, October 10,
> 2018 7:47 AM
> To: jordan.a...@cisco.com; vpp-dev@lists.fd.io
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] VPP and 100G Ethernet
> 
> We've had the ConnectX5 100Gig nics running nicely at around the PCIe Gen3
> x16 limit of 100Gbps across the two ports.  DPDK/OFED/rdma versions are
> important, and depending on traffic profile there are a couple of key
> setting for maximum performance with the default DPDK build, but overall
> we've found them very solid.
> 
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of via Lists.Fd.Io
> Sent: 10 October 2018 09:08
> To: vpp-dev@lists.fd.io
> Cc: vpp-dev@lists.fd.io
> Subject: [vpp-dev] VPP and 100G Ethernet
> 
> Hi,
> 
> I was wondering if anyone had any experience to share with VPP and 100G
> Ethernet cards, in particular which models were tested.
> 
> From the dpdk website, we can find references to intel fm10k driver (but i
> don't seem to find any PCIe card on the market), or Mellanox Connect-5g for
> instance. There are a few posts on the Internet about Mellanox or Napatech
> devices, but overall the information is quite scarce.
> 
> Thanks in advance.
> 
> Cheers,
> -- Jordan




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10858): https://lists.fd.io/g/vpp-dev/message/10858
Mute This Topic: https://lists.fd.io/mt/27155606/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] bug in api for tapv2

[Marco Varlese]

Thank you!
On Wed, 2018-10-17 at 12:18 +, Michal Cmarada via Lists.Fd.Io wrote:
> Hi Marco,
>  
> Done: 
> https://gerrit.fd.io/r/#/c/15342/
>  
> Michal
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Michal Cmarada
> Engineer - Software
> mcmar...@cisco.com
> Tel:
> 
>  
>  
> 
> 
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Cisco Systems, Inc.
>  
>  
>  
> Slovakia
> cisco.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Think before you print.
> 
> 
> 
> 
> This email may contain confidential and privileged material for the sole use
> of the intended recipient. Any review, use, distribution
>  or disclosure by others is strictly prohibited. If you are not the intended
> recipient (or authorized to receive for the recipient), please contact the
> sender by reply email and delete all copies of this message.
> Please
> 
> click here for Company Registration Information.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
>  
> 
> 
> From: Marco Varlese  
> 
> Sent: Wednesday, October 17, 2018 2:16 PM
> 
> To: Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco) <
> mcmar...@cisco.com>; vpp-dev@lists.fd.io
> 
> Subject: Re: [vpp-dev] bug in api for tapv2
> 
> 
>  
> 
> Hi Michal,
> 
> 
>  
> 
> 
> On Wed, 2018-10-17 at 11:49 +, Michal Cmarada via Lists.Fd.Io wrote:
> 
> > Hi VPP devs,
> >  
> > I found a bug in API for tapv2. I prepared a fix but I need someone to check
> > it.
> > 
> > 
> > gerrit patch: https://gerrit.fd.io/r/#/c/15341/
> 
> Yes, your fix makes sense to me.
> 
> 
> I am waiting for the Verified+1 to merge it.
> 
> 
>  
> 
> > 
> > also it will probably need a cherry-pick to stable 18.10
> 
> Yes, it will have to be cherry-picked to stable 18.10. Can you push a patch
> there too?
> 
> 
>  
> 
> >  
> >  
> > Thanks
> >  
> > Michal
> 
> Cheers,
> 
> 
> Marco
> 
> 
>  
> 
> >  
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Michal Cmarada
> > Engineer - Software
> > mcmar...@cisco.com
> > Tel:
> > 
> >  
> >  
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Cisco Systems, Inc.
> >  
> >  
> >  
> > Slovakia
> > cisco.com
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Think before you print.
> > 
> > 
> > 
> > 
> > This email may contain confidential and privileged material for the sole use
> > of the intended recipient. Any review, use, distribution
> >  or disclosure by others is strictly prohibited. If you are not the intended
> > recipient (or authorized to receive for the recipient), please contact the
> > sender by reply email and delete all copies of this message.
> > Please
> > 
> > click here for Company Registration Information.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> >  
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> >  
> > View/Reply Online (#10854): https://lists.fd.io/g/vpp-dev/message/10854
> > Mute This Topic: https://lists.fd.io/mt/27379050/675056
> > Group Owner: vpp-dev+ow...@lists.fd.io
> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [mvarl...@suse.de]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >  
> 
> -- 
> 
> Marco V
> 
> 
>  
> 
> SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
> 
> HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
> 
> 
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-Links: You receive all messages sent to this group.
> View/Reply Online (#10856): https://lists.fd.io/g/vpp-dev/message/10856Mute
> This Topic: https://lists.fd.io/mt/27379050/675056Group Owner: vpp-
> dev+ow...@lists.fd.ioUnsubscribe: https://lists.fd.io/g/vpp-dev/unsubb  [mvarl
> e...@suse.de]-=-=-=-=-=-=-=-=-=-=-=-
-- 
Marco V


SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10857): https://lists.fd.io/g/vpp-dev/message/10857
Mute This Topic: https://lists.fd.io/mt/27379050/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] bug in api for tapv2

[Michal Cmarada via Lists.Fd.Io]

Hi Marco,

Done: https://gerrit.fd.io/r/#/c/15342/

Michal

[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/06_standard_graphic.png]




Michal Cmarada
Engineer - Software
mcmar...@cisco.com
Tel:










Cisco Systems, Inc.



Slovakia
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.







From: Marco Varlese 
Sent: Wednesday, October 17, 2018 2:16 PM
To: Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco) 
; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] bug in api for tapv2

Hi Michal,

On Wed, 2018-10-17 at 11:49 +, Michal Cmarada via Lists.Fd.Io wrote:
Hi VPP devs,

I found a bug in API for tapv2. I prepared a fix but I need someone to check it.
gerrit patch: https://gerrit.fd.io/r/#/c/15341/
Yes, your fix makes sense to me.
I am waiting for the Verified+1 to merge it.


also it will probably need a cherry-pick to stable 18.10
Yes, it will have to be cherry-picked to stable 18.10. Can you push a patch 
there too?



Thanks

Michal
Cheers,
Marco



[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/06_standard_graphic.png]




Michal Cmarada
Engineer - Software
mcmar...@cisco.com
Tel:










Cisco Systems, Inc.



Slovakia
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.








-=-=-=-=-=-=-=-=-=-=-=-

Links: You receive all messages sent to this group.



View/Reply Online (#10854): https://lists.fd.io/g/vpp-dev/message/10854

Mute This Topic: https://lists.fd.io/mt/27379050/675056

Group Owner: vpp-dev+ow...@lists.fd.io

Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[mvarl...@suse.de]

-=-=-=-=-=-=-=-=-=-=-=-



--
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10856): https://lists.fd.io/g/vpp-dev/message/10856
Mute This Topic: https://lists.fd.io/mt/27379050/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] bug in api for tapv2

[Marco Varlese]

Hi Michal,

On Wed, 2018-10-17 at 11:49 +, Michal Cmarada via Lists.Fd.Io wrote:
> 
> 
> Hi VPP devs,
> 
>  
> 
> I found a bug in API for tapv2. I prepared a fix but I need someone to check
> it.
> 
> 
> gerrit patch: https://gerrit.fd.io/r/#/c/15341/
> 
Yes, your fix makes sense to me.
I am waiting for the Verified+1 to merge it.



also it will probably need a cherry-pick to stable 18.10
Yes, it will have to be cherry-picked to stable 18.10. Can you push a patch
there too?

 
Thanks
 
Michal
Cheers,
Marco

 
Michal Cmarada
Engineer - Software
mcmar...@cisco.com
Tel:
 
 
 
 
Cisco Systems, Inc.
 
 
 
Slovakia
cisco.com
Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution
 or disclosure by others is strictly prohibited. If you are not the intended 
recipient (or authorized to receive for the recipient), please contact the 
sender by reply email and delete all copies of this message.
Please

click here for Company Registration Information.
 
 



> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#10854): https://lists.fd.io/g/vpp-dev/message/10854
> Mute This Topic: https://lists.fd.io/mt/27379050/675056
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [mvarl...@suse.de]
> -=-=-=-=-=-=-=-=-=-=-=-
> 
-- 
Marco V


SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10855): https://lists.fd.io/g/vpp-dev/message/10855
Mute This Topic: https://lists.fd.io/mt/27379050/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] bug in api for tapv2

[Michal Cmarada via Lists.Fd.Io]

Hi VPP devs,

I found a bug in API for tapv2. I prepared a fix but I need someone to check it.
gerrit patch: https://gerrit.fd.io/r/#/c/15341/

also it will probably need a cherry-pick to stable 18.10

Thanks

Michal

[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/06_standard_graphic.png]




Michal Cmarada
Engineer - Software
mcmar...@cisco.com
Tel:










Cisco Systems, Inc.



Slovakia
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

Think before you print.

This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click 
here
 for Company Registration Information.







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10854): https://lists.fd.io/g/vpp-dev/message/10854
Mute This Topic: https://lists.fd.io/mt/27379050/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vpp 18.07.1 hangs on intel x520-sr2

[Glaza]

Investigating it further I have build 18.10-rc1 and than master. In both cases 
I got a crash dump in rte_eal_init. Bellow is BT from master:  #0  
0x7ff377882277 in raise () from /lib64/libc.so.6  #1  0x7ff377883968 in 
abort () from /lib64/libc.so.6  #2  0x0040817c in os_exit (code=1) at 
/var/vpp/vpp/src/vpp/vnet/main  #3  0x7ff379021c9f in unix_signal_handler 
(signum=6, si=0x7ff3369feeb0, uc=0x7ff3369fed80) at 
/var/vpp/vpp/src/vlib/unix/mai  #4  signal handler called  #5  
0x7ff377882277 in raise () from /lib64/libc.so.6  #6  0x7ff377883968 in 
abort () from /lib64/libc.so.6  #7  0x7ff334aba345 in __rte_panic () from 
/usr/lib/vpp_plugins/dpdk_plug  #8  0x7ff334af3f90 in rte_eal_init () from 
/usr/lib/vpp_plugins/dpdk_plug  #9  0x7ff335142df7 in dpdk_config 
(vm=0x7ff37924d240 vlib_global_main, input=0x7ff33553e0a8 
_vlib_config_function_dpdk_co at /var/vpp/vpp/src/plugins/dpdk/  #10 
0x7ff378fa854f in vlib_call_all_config_functions (vm=0x7ff37924d240 
vlib_global_main, input=0x7ff3369fffb0, is_early=0) at 
/var/vpp/vpp/src/vlib/init.c:1  #11 0x7ff378fcc004 in vlib_main 
(vm=0x7ff37924d240 vlib_global_main, input=0x7ff3369fffb0) at 
/var/vpp/vpp/src/vlib/main.c:1  #12 0x7ff3790234b5 in thread0 
(arg=140683686236736) at /var/vpp/vpp/src/vlib/unix/mai  #13 0x7ff37864d88c 
in clib_calljmp () from /lib64/libvppinfra.so.19.01  #14 0x7ffdbc134110 in 
?? ()  #15 0x7ff379023966 in vlib_unix_main (argc=29, argv=0x1315830) at 
/var/vpp/vpp/src/vlib/unix/mai  #16 0x00407b45 in main (argc=29, 
argv=0x1315830) at /var/vpp/vpp/src/vpp/vnet/main   # dpdk-devbind -s   Network 
devices using DPDK-compatible driver  ==  
:07:00.0 I210 Gigabit Network Connection 1533 drv=vfio-pci 
unused=igb_uio,uio_pci_generic  :81:00.0 82599ES 10-Gigabit SFI/SFP+ 
Network Connection 10fb drv=vfio-pci unused=igb_uio,uio_pci_generic  
:81:00.1 82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb 
drv=vfio-pci unused=igb_uio,uio_pci_generic   startup.conf is:   unix {    
nodaemon    log /var/log/vpp/vpp.log    full-coredump    cli-listen 
/run/vpp/cli.sock    gid vpp  }   api-trace {    on  }   api-segment {    gid 
vpp  }   cpu {   }   dpdk {      uio-driver vfio-pci  }  On 15 10 2018 
12:26 Glaza wrote:  Hi All,   On centos 7 after install vpp-18.07.1-release 
hangs after start when x520-sr2 NIC is in use.   # dpdk-devbind -s | head   
Network devices using DPDK-compatible driver  ==  
:81:00.0 82599ES 10-Gigabit SFI/SFP+ Network Connection 10fb 
drv=uio_pci_generic unused=igb_uio  :81:00.1 82599ES 10-Gigabit 
SFI/SFP+ Network Connection 10fb drv=uio_pci_generic unused=igb_uio   # 
/usr/bin/vpp -c /etc/vpp/startup.conf  vlib_plugin_early_init:361: plugin path 
/usr/lib/vpp_plugins:/usr/lib6  load_one_plugin:189: Loaded plugin: 
abf_plugin.so (ACL based Forwarding)  load_one_plugin:189: Loaded plugin: 
acl_plugin.so (Access Control Lists)  load_one_plugin:189: Loaded plugin: 
avf_plugin.so (Intel Adaptive Virtual Function (AVF) Device Plugin)  
load_one_plugin:191: Loaded plugin: cdp_plugin.so  load_one_plugin:189: Loaded 
plugin: dpdk_plugin.so (Data Plane Development Kit (DPDK))  
load_one_plugin:189: Loaded plugin: flowprobe_plugin.so (Flow per Packet)  
load_one_plugin:189: Loaded plugin: gbp_plugin.so (Group Based Policy)  
load_one_plugin:189: Loaded plugin: gtpu_plugin.so (GTPv1-U)  
load_one_plugin:189: Loaded plugin: igmp_plugin.so (IGMP messaging)  
load_one_plugin:189: Loaded plugin: ila_plugin.so (Identifier-locator 
addressing for IPv6)  load_one_plugin:189: Loaded plugin: ioam_plugin.so 
(Inbound OAM)  load_one_plugin:117: Plugin disabled (default): ixge_plugin.so  
load_one_plugin:189: Loaded plugin: l2e_plugin.so (L2 Emulation)  
load_one_plugin:189: Loaded plugin: lacp_plugin.so (Link Aggregation Control 
Protocol)  load_one_plugin:189: Loaded plugin: lb_plugin.so (Load Balancer)  
load_one_plugin:189: Loaded plugin: mactime_plugin.so (Time-based MAC 
source-address filter)  load_one_plugin:189: Loaded plugin: map_plugin.so 
(Mapping of address and port (MAP))  load_one_plugin:189: Loaded plugin: 
memif_plugin.so (Packet Memory Interface (experimetal))  load_one_plugin:189: 
Loaded plugin: nat_plugin.so (Network Address Translation)  
load_one_plugin:189: Loaded plugin: pppoe_plugin.so (PPPoE)  
load_one_plugin:189: Loaded plugin: srv6ad_plugin.so (Dynamic SRv6 proxy)  
load_one_plugin:189: Loaded plugin: srv6am_plugin.so (Masquerading SRv6 proxy)  
load_one_plugin:189: Loaded plugin: srv6as_plugin.so (Static SRv6 proxy)  
load_one_plugin:189: Loaded plugin: stn_plugin.so (VPP Steals the NIC for 
Container integration)  load_one_plugin:189: Loaded plugin: 
tlsmbedtls_plugin.so (mbedtls based TLS Engine)  load_one_plugin:189: Loaded 
plugin: tlsopenssl_plugin.so (openssl based TLS Engine)  
svm_client_scan_this_region_no /vpe-api: cleanup ghost pid 2517  

[vpp-dev] VPP 18.10 RC2 milestone complete!!!

[Marco Varlese]

Dear all,

I have created the v18.10-rc2 tag on stable/1810. 
VPP 18.10 Release Milestone RC2 is complete!

As a reminder, the VPP 18.10 Final Release is in one week:
Wednesday October 24, 2018.

It is important that only bugs which address critical issues (as determined by
the VPP committers), ideally limited to addressing bugs found by CSIT testing,
are pushed to stable now.

Per the standard process, all bug fixes to stable branches should follow the
best practices:
* All bug fixes must be double-committed to the release throttle as well as to
the master branch
* Commit first to the release throttle, then "git cherry-pick" into master

All bug fixes need to have a Jira ticket. Please put Jira IDs into the commit
messages. Please use the same Jira ID for both the stable branch and master.


Thanks and regards,
-- 
Marco V

SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10852): https://lists.fd.io/g/vpp-dev/message/10852
Mute This Topic: https://lists.fd.io/mt/27378265/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vapi recv error msg_id_name

[Klement Sekera via Lists.Fd.Io]

getting a message without sending one is probably because of keepalive
messages, which vapi doesn't handle automatically in your version.
newer versions support automatic handling of keepalive messages by
supplying the appropriate parameter to vapi_connect to do so.

regarding tunnel_if_index - can you verify that the reply is indeed
vapi_vxlan_add_del_reply? if so, than the bug is most probably in your
app or on vpp side. vapi library doesn't do any processing itself and
all the code is generated.

Quoting 王传国 (2018-10-17 09:47:24)
> one more question.
> 
> Even if there was no vapi_send, I can get 0 from vapi_recv after sometime. 
> why?
> sometime,vapi_vxlan_add_del'reply,retvalue=0,but the tunnel_if_index=0 which 
> should be 6(got by cmd:show int)
> 
> 
> 
> --
> 发自我的网易邮箱手机智能版
> 
> 
> 在 2018-10-15 19:03:52，"Klement Sekera"  写道：
> >Hey,
> >
> >The reason why your name doesn't match the request is related to your
> >code mixing vl_msg_id_t with vapi_msg_id_t. VPP internally assignes
> >message IDs at startup based on it's runtime configuration - plugins. If
> >a plugin is not loaded, it's API messages aren't loaded either. On the
> >other hand, VAPI IDs are constructed when the libvapiclient binary is
> >loaded and depend on included *.api.vapi.h files which your application
> >is using.
> >
> >TLDR:
> >change:
> >printf("recv msg[%d] %s\n", resp->header._vl_msg_id, 
> >vapi_get_msg_name(resp->header._vl_msg_id));
> >to:
> >printf("recv msg[%d] %s\n", resp->header._vl_msg_id, 
> >vapi_get_msg_name(vapi_lookup_vapi_msg_id_t(ctx, resp->header._vl_msg_id))); 
> >
> >Regards,
> >Klement
> >
> >Quoting wangchuan...@163.com (2018-10-14 11:43:35)
> >>My connect:
> >>vapi_connect (ctx, "test123", NULL, 64, 32, VAPI_MODE_BLOCKING);
> >>Even if there is no vapi_send, I can get 0 from vapi_recv after 
> >> sometime.
> >>My branch is stable 18.04.
> >>Who can help? 
> >>Thanks very much!
> >> 
> >>
> >> --
> >> 
> >>wangchuan...@163.com
> >> 
> >>   
> >>  From: [1]wangchuan...@163.com
> >>  Date: 2018-10-14 17:06
> >>  To: [2]vpp-dev
> >>  Subject: vapi recv error msg_id_name
> >>  Hi all,
> >>      I got a serious mistake when using vapi that 'recv msg->name' has
> >>  nothing to do with 'send msg-id'.
> >>  The currently installed RPMS were compiled yesterday,and i do some
> >>  change to src/*.
> >>  Should I compile my example after making pkg-rpm && installing all 
> >> rpms
> >>  again?
> >>  The code like :
> >>      vapi_msg_sw_interface_set_l2_bridge *msg =  
> >> vapi_alloc_sw_interface_set_l2_bridge(ctx);
> >>msg->payload.rx_sw_if_index = rx_sw_if_index;
> >>msg->payload.bd_id = bd_id;
> >>msg->payload.shg = shg;
> >>msg->payload.shg = shg;
> >>msg->payload.bvi = bvi;
> >>msg->payload.enable = enable;
> >>vapi_msg_sw_interface_set_l2_bridge_hton (msg);
> >>vapi_error_e rv = vapi_send (ctx, msg);
> >>vapi_msg_sw_interface_set_l2_bridge_reply *resp;
> >>size_t size;
> >>rv = vapi_recv (ctx, (void *) , , 0, 0);
> >>vapi_msg_sw_interface_set_l2_bridge_reply_hton(resp);
> >>printf("recv msg[%d] %s\n", resp->header._vl_msg_id, 
> >> vapi_get_msg_name(resp->header._vl_msg_id) );
> >>  
> >>  recv msg[166] ip6nd_proxy_details
> >>  recv msg[23] sw_interface_tag_add_del
> >> 
> >>
> >> --
> >> 
> >>  wangchuan...@163.com
> >> 
> >> References
> >> 
> >>Visible links
> >>1. mailto:wangchuan...@163.com
> >>2. mailto:vpp-dev@lists.fd.io
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10851): https://lists.fd.io/g/vpp-dev/message/10851
Mute This Topic: https://lists.fd.io/mt/27309659/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vapi recv error msg_id_name

[wangchuan...@163.com]

one more question.

Even if there was no vapi_send, I can get 0 from vapi_recv after sometime. why?
sometime,vapi_vxlan_add_del'reply,retvalue=0,but the tunnel_if_index=0 which 
should be 6(got by cmd:show int)



--
发自我的网易邮箱手机智能版


在 2018-10-15 19:03:52，"Klement Sekera"  写道：
>Hey,
>
>The reason why your name doesn't match the request is related to your
>code mixing vl_msg_id_t with vapi_msg_id_t. VPP internally assignes
>message IDs at startup based on it's runtime configuration - plugins. If
>a plugin is not loaded, it's API messages aren't loaded either. On the
>other hand, VAPI IDs are constructed when the libvapiclient binary is
>loaded and depend on included *.api.vapi.h files which your application
>is using.
>
>TLDR:
>change:
>printf("recv msg[%d] %s\n", resp->header._vl_msg_id, 
>vapi_get_msg_name(resp->header._vl_msg_id));
>to:
>printf("recv msg[%d] %s\n", resp->header._vl_msg_id, 
>vapi_get_msg_name(vapi_lookup_vapi_msg_id_t(ctx, resp->header._vl_msg_id))); 
>
>Regards,
>Klement
>
>Quoting wangchuan...@163.com (2018-10-14 11:43:35)
>>My connect:
>>vapi_connect (ctx, "test123", NULL, 64, 32, VAPI_MODE_BLOCKING);
>>Even if there is no vapi_send, I can get 0 from vapi_recv after sometime.
>>My branch is stable 18.04.
>>Who can help? 
>>Thanks very much!
>> 
>>--
>> 
>>wangchuan...@163.com
>> 
>>   
>>  From: [1]wangchuan...@163.com
>>  Date: 2018-10-14 17:06
>>  To: [2]vpp-dev
>>  Subject: vapi recv error msg_id_name
>>  Hi all,
>>      I got a serious mistake when using vapi that 'recv msg->name' has
>>  nothing to do with 'send msg-id'.
>>  The currently installed RPMS were compiled yesterday,and i do some
>>  change to src/*.
>>  Should I compile my example after making pkg-rpm && installing all rpms
>>  again?
>>  The code like :
>>      vapi_msg_sw_interface_set_l2_bridge *msg =  
>> vapi_alloc_sw_interface_set_l2_bridge(ctx);
>>msg->payload.rx_sw_if_index = rx_sw_if_index;
>>msg->payload.bd_id = bd_id;
>>msg->payload.shg = shg;
>>msg->payload.shg = shg;
>>msg->payload.bvi = bvi;
>>msg->payload.enable = enable;
>>vapi_msg_sw_interface_set_l2_bridge_hton (msg);
>>vapi_error_e rv = vapi_send (ctx, msg);
>>vapi_msg_sw_interface_set_l2_bridge_reply *resp;
>>size_t size;
>>rv = vapi_recv (ctx, (void *) , , 0, 0);
>>vapi_msg_sw_interface_set_l2_bridge_reply_hton(resp);
>>printf("recv msg[%d] %s\n", resp->header._vl_msg_id, 
>> vapi_get_msg_name(resp->header._vl_msg_id) );
>>  
>>  recv msg[166] ip6nd_proxy_details
>>  recv msg[23] sw_interface_tag_add_del
>> 
>>--
>> 
>>  wangchuan...@163.com
>> 
>> References
>> 
>>Visible links
>>1. mailto:wangchuan...@163.com
>>2. mailto:vpp-dev@lists.fd.io
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10850): https://lists.fd.io/g/vpp-dev/message/10850
Mute This Topic: https://lists.fd.io/mt/27309659/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vapi recv error msg_id_name

[wangchuan...@163.com]

Dear klement,
thanks very very very very … much!
i will try tomorrow!

love you!




--
发自我的网易邮箱手机智能版


在 2018-10-15 19:03:52，"Klement Sekera"  写道：
>Hey,
>
>The reason why your name doesn't match the request is related to your
>code mixing vl_msg_id_t with vapi_msg_id_t. VPP internally assignes
>message IDs at startup based on it's runtime configuration - plugins. If
>a plugin is not loaded, it's API messages aren't loaded either. On the
>other hand, VAPI IDs are constructed when the libvapiclient binary is
>loaded and depend on included *.api.vapi.h files which your application
>is using.
>
>TLDR:
>change:
>printf("recv msg[%d] %s\n", resp->header._vl_msg_id, 
>vapi_get_msg_name(resp->header._vl_msg_id));
>to:
>printf("recv msg[%d] %s\n", resp->header._vl_msg_id, 
>vapi_get_msg_name(vapi_lookup_vapi_msg_id_t(ctx, resp->header._vl_msg_id))); 
>
>Regards,
>Klement
>
>Quoting wangchuan...@163.com (2018-10-14 11:43:35)
>>My connect:
>>vapi_connect (ctx, "test123", NULL, 64, 32, VAPI_MODE_BLOCKING);
>>Even if there is no vapi_send, I can get 0 from vapi_recv after sometime.
>>My branch is stable 18.04.
>>Who can help? 
>>Thanks very much!
>> 
>>--
>> 
>>wangchuan...@163.com
>> 
>>   
>>  From: [1]wangchuan...@163.com
>>  Date: 2018-10-14 17:06
>>  To: [2]vpp-dev
>>  Subject: vapi recv error msg_id_name
>>  Hi all,
>>      I got a serious mistake when using vapi that 'recv msg->name' has
>>  nothing to do with 'send msg-id'.
>>  The currently installed RPMS were compiled yesterday,and i do some
>>  change to src/*.
>>  Should I compile my example after making pkg-rpm && installing all rpms
>>  again?
>>  The code like :
>>      vapi_msg_sw_interface_set_l2_bridge *msg =  
>> vapi_alloc_sw_interface_set_l2_bridge(ctx);
>>msg->payload.rx_sw_if_index = rx_sw_if_index;
>>msg->payload.bd_id = bd_id;
>>msg->payload.shg = shg;
>>msg->payload.shg = shg;
>>msg->payload.bvi = bvi;
>>msg->payload.enable = enable;
>>vapi_msg_sw_interface_set_l2_bridge_hton (msg);
>>vapi_error_e rv = vapi_send (ctx, msg);
>>vapi_msg_sw_interface_set_l2_bridge_reply *resp;
>>size_t size;
>>rv = vapi_recv (ctx, (void *) , , 0, 0);
>>vapi_msg_sw_interface_set_l2_bridge_reply_hton(resp);
>>printf("recv msg[%d] %s\n", resp->header._vl_msg_id, 
>> vapi_get_msg_name(resp->header._vl_msg_id) );
>>  
>>  recv msg[166] ip6nd_proxy_details
>>  recv msg[23] sw_interface_tag_add_del
>> 
>>--
>> 
>>  wangchuan...@163.com
>> 
>> References
>> 
>>Visible links
>>1. mailto:wangchuan...@163.com
>>2. mailto:vpp-dev@lists.fd.io
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10849): https://lists.fd.io/g/vpp-dev/message/10849
Mute This Topic: https://lists.fd.io/mt/27309659/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] vpp crash when handling IGMP with router alert

[Neale Ranns via Lists.Fd.Io]

Hi Jeff,

Thank you for the bug report.

As you mention the graph node path taken by these packets does not go thru 
ip4-lookup and so does not have the fib-index set. Since ip4-lookup is replaced 
by ip4-options, IMO ip4-options would be the place to add the code you have 
identified, so that we don’t do unnecessary work on packets that are for-us and 
were subject to the lookup. Please submit a patch with the change.

We have some unit tests in test/test_igmp.py (test_igmp_router()) where we send 
IGMP packets to an interface that is not IGMP enabled and so they take the same 
graph node paths as your packet. This tests passes. Is your input interface 
bound to a non-default VRF? If so would you be able to add a new test to that 
file where the input interface is bound to another table?

Thanks,
neale

De :  au nom de Jeff 
Date : mardi 16 octobre 2018 à 22:27
À : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] vpp crash when handling IGMP with router alert

Hello,

I have a tap interface connected to a noisy LAN and I found that a certain type 
of IGMP packet will sometimes cause a crash (backtrace at the end) in 
ip4_fib_mtrie_lookup_step_one().  More specifically its an IGMP packet with the 
router alert IP option.  Here's a packet trace:

00:02:41:522429: virtio-input
  virtio: hw_if_index 6 next-index 4 vring 0 len 54
hdr: flags 0x00 gso_type 0x00 hdr_len 0 gso_size 0 csum_start 0 csum_offset 
0 num_buffers 1
00:02:41:522430: ethernet-input
  IP4: 00:0c:29:1f:43:a4 -> 01:00:5e:00:00:16
00:02:41:522430: ip4-input
  IGMP: 172.20.2.194 -> 224.0.0.22
version 4, header length 24
tos 0xc0, ttl 1, length 40, checksum 0x5523
fragment id 0x, flags DONT_FRAGMENT
00:02:41:522431: ip4-options
option:[0x94,0x4,0x0,0x0]
00:02:41:522431: ip4-local
IGMP: 172.20.2.194 -> 224.0.0.22
  version 4, header length 24
  tos 0xc0, ttl 1, length 40, checksum 0x5523
  fragment id 0x, flags DONT_FRAGMENT
00:02:41:522434: igmp-input
  sw_if_index 6 next-index 0
  membership_report_v3: code 0, checksum 0xfbf4
00:02:41:522435: error-drop
  igmp-input: IGMP not enabled on this interface


I found that when the crash occurs vnet_buffer(b)->ip.fib_index is ~0 in 
ip4_local_check_src().  Here's an example debug print just added just after "if 
(PREDICT_FALSE (last_check->src.as_u32 != ip0->src_address.as_u32))" in 
ip4_local_check_src()

Usual case:
ip4_local_check_src: ( != 0101A8C0), buf 0x7f6b6301b900, vlib_tx 
4294967295 fib index 0

When crash happens:
ip4_local_check_src: ( != 0100A8C0), buf 0x7f6b63a0, vlib_tx 
4294967295 fib index 4294967295

I think the problem is that vnet_buffer(b)->ip.fib_index isn't set anywhere in 
this processing chain (ip4-input -> ip4-options -> ip4-local).  This can cause 
an invalid pointer to be used when looking up the mtrie in 
ip4_local_check_src().  Normally the fib_index metadata is assigned by 
ip4-lookup via ip_lookup_set_buffer_fib_index().  But since the packet doesn't 
traverse that node the metadata is unset.  I'm guessing that due to luck and/or 
initialization the fib_index metadata is usually zero, so the crash won't 
happen until the metadata is modified elsewhere and then the buffer is reused 
for this IGMP packet with router alert.  I hope this is what's happening and 
it's not something more nefarious like memory corruption.

I made the following change at the top of ip4_local_check_src (taken from 
ip_lookup_set_buffer_fib_index())

   const dpo_id_t *dpo0;
   load_balance_t *lb0;
   u32 lbi0;
+  ip4_main_t *im = _main;

   vnet_buffer (b)->ip.fib_index =
+vec_elt (im->fib_index_by_sw_if_index, vnet_buffer 
(b)->sw_if_index[VLIB_RX]);
+  vnet_buffer (b)->ip.fib_index =
 vnet_buffer (b)->sw_if_index[VLIB_TX] != ~0 ?
 vnet_buffer (b)->sw_if_index[VLIB_TX] : vnet_buffer (b)->ip.fib_index;

With this change I was unable to trigger the crash.  Don't know if this is a 
proper fix though.

Here's the backtrace (some of the line numbers might be offset due to my 
debugging):

Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
0x7f73861c2748 in ip4_fib_mtrie_lookup_step_one 
(dst_address=0x7f717de38e1a, m=) at 
/home/jeff/vpp/src/vnet/ip/ip4_mtrie.h:229
229 /home/jeff/vpp/src/vnet/ip/ip4_mtrie.h: No such file or directory.
(gdb) bt
#0  0x7f73861c2748 in ip4_fib_mtrie_lookup_step_one 
(dst_address=0x7f717de38e1a, m=) at 
/home/jeff/vpp/src/vnet/ip/ip4_mtrie.h:229
#1  ip4_local_check_src (error0=, last_check=, ip0=0x7f717de38e0e, b=)
at /home/jeff/vpp/src/vnet/ip/ip4_forward.c:1352
#2  ip4_local_inline (vm=, node=, 
frame=, head_of_feature_arc=)
at /home/jeff/vpp/src/vnet/ip/ip4_forward.c:1586
#3  0x7f7385c70014 in dispatch_node (last_time_stamp=17304359695215669, 
frame=0x7f718dcaf300, dispatch_state=VLIB_NODE_STATE_POLLING,
type=VLIB_NODE_TYPE_INTERNAL, node=0x7f7184ed2ec0, vm=0x7f7385ec9980 
) at /home/jeff/vpp/src/vlib/main.c:989
#4  dispatch_pending_node