Re: [vpp-dev] [csit-dev] VPP 17.01 Released

[Florin Coras]

Awesome! 

Thank you for the hard work Damjan and congratulations to the entire community!

Florin

> On Jan 20, 2017, at 2:51 PM, Damjan Marion (damarion)  
> wrote:
> 
> 
> The VPP 17.01 release i up. Many thanks to all contributors and testers
> and specially Ed for helping to roll this release over the finish line.
> 
> .rpm and .deb packages are uploaded to the nexus server.
> 
> New features in the VPP 17.01:
> 
> - Integrated November 2016 DPDK release
> - Complete rework of Forwarding Information Base (FIB)
> - Performance Improvements
>  - Improvements in DPDK input and output nodes
>  - Improvements in L2 path
>  - Improvmeents in IPv4 lookup node
> - Feature Arcs Improvements
>  - Consolidation of the code
>  - New feature arcs
>- device-input
>- interface-output
> - DPDK Cryptodev Support
>  - Software and Hardware Crypto Support
> - DPDK HQoS support
> - Simple Port Analyzer (SPAN)
> - Bidirectional Forwarding Detection
>  - Basic implementation
> - IPFIX Improvements
> - L2 GRE over IPSec tunnels
> - Link Layer Discovery Protocol (LLDP)
> - Vhost-user Improvements
>  - Performance Improvements
>  - Multi-queue
>  - Reconnect
> - LISP Enhancements
>  - Source/Dest control plane support
>  - L2 over LISP and GRE
>  - Map-Register/Map-Notify/RLOC-probing support
>  - L2 API improvements, overall code hardening
> - Plugins:
>  - New: ACL
>  - New: Flow per Packet
>  - Improved: SNAT
>- Multi-threading
>- Flow export
> - Doxygen Enhancements
> - Luajit API bindings
> - API Refactoring
>  - file split
>  - message signatures
> - Python and Scapy based unit testing infrastructure
>  - Infrastructure
>  - Various tests
> - Packet Generator improvements
> - TUN/TAP jumbo frames support
> - Other various bug fixes and improvements
> 
> Thanks,
> 
> Damjan
> ___
> csit-dev mailing list
> csit-...@lists.fd.io
> https://lists.fd.io/mailman/listinfo/csit-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] TCP Connection Failed Between two veth interfaces switched via VPP

[Florin Coras]

Hi Hang, 

A common problem when working with tcp/udp in these sort of setups is 
offloading. Have you tried doing something like:

ethtool --offload  vpp0 rx off tx off
ip netns exec ns0 ethtool --offload vethns0 rx off tx off

HTH, 
Florin

> On Feb 21, 2017, at 10:19 PM, Hang Shi  wrote:
> 
> Hi, 
> 
> I am trying to do tcp connection between two veth interfaces via switching in 
> VPP, as done in below wiki. The ping is successful, however, the TCP 
> connection failed for a TCP connection from a veth interface in one namespace 
> to another namespace. Tried on http  and netcat server. Using latest git 
> master branch. Going to try earlier codes as this seems to be a basic 
> scenarios. Anyone has any quick ideas? 
> 
> Below are the steps/commands I tried: 
> 
> https://wiki.fd.io/view/VPP/Tutorial_Routing_and_Switching 
> 
> 
> 
> 
> 
> # create namespace ns0 
> ip netns add ns0
> ip link add vpp0 type veth peer name vethns0
> ip link set vethns0 netns ns0
> ip netns exec ns0 ip link set lo up
> ip netns exec ns0 ip link set vethns0 up
> ip netns exec ns0 ip addr add 10.1.1.1/24  dev vethns0
> ip link set vpp0 up
> 
> #create namespace ns1
> ip netns add ns1
> ip link add vpp1 type veth peer name vethns1
> ip link set vethns1 netns ns1
> ip netns exec ns1 ip link set lo up
> ip netns exec ns1 ip link set vethns1 up
> ip netns exec ns1 ip addr add 10.1.1.2/24  dev vethns1
> ip link set vpp1 up
> 
> 
> # create host-interfaces for vpp0 and vpp1, and assign them to bridge domain 1
> vppctl create host-interface name vpp0
> vppctl create host-interface name vpp1
> vppctl set interface state host-vpp0 up
> vppctl set interface state host-vpp1 up
> vppctl set interface l2 bridge host-vpp0 1
> vppctl set interface l2 bridge host-vpp1 1
> 
> 
> 
> 
> # on HTTP Server terminal
> root@aurora-vpp-vm1:~# ip netns exec ns1 python -m SimpleHTTPServer 80
> Serving HTTP on 0.0.0.0 port 80 ...
> 
> 
> # on HTTP Client terminal
> root@aurora-vpp-vm1:~# ip netns exec ns0 wget http://10.1.1.2:80 
> 
> --2017-02-21 22:01:57--  http://10.1.1.2/ 
> Connecting to 10.1.1.2:80...
> 
> 
> #also tried netcat, not working either.
> 
> 
> thanks, 
> Hang
> 
> 
> 
> ___
> 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 make test is not working

[Florin Coras]

Jan, 

Could you try with master again? For reference, the patch is here [1]

Thanks, 
Florin

[1] https://gerrit.fd.io/r/#/c/5477/ 

> On Feb 22, 2017, at 11:11 AM, Klement Sekera -X (ksekera - PANTHEON 
> TECHNOLOGIES at Cisco)  wrote:
> 
> Jan,
> 
> 1. Filip is already working on a fix.
> 2. make test was accidentally removed from the make verify, Filip will
> add it back with his fix.
> 
> Regards,
> Klement
> 
> Quoting Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES at Cisco) (2017-02-22 
> 18:30:55)
>>   Hello,
>> 
>>
>> 
>>   Currently all make test are failing with the same error (run locally on my
>>   development VM system – ubuntu16.04):
>> 
>>
>> 
>>   
>> ==
>> 
>>   ERROR: setUpClass (test_ip6.TestIPv6)
>> 
>>   
>> --
>> 
>>   Traceback (most recent call last):
>> 
>> File "/home/vpp/Documents/vpp/test/test_ip6.py", line 31, in setUpClass
>> 
>>   super(TestIPv6, cls).setUpClass()
>> 
>> File "/home/vpp/Documents/vpp/test/framework.py", line 242, in
>>   setUpClass
>> 
>>   cls.vapi = VppPapiProvider(cls.shm_prefix, cls.shm_prefix, cls)
>> 
>> File "/home/vpp/Documents/vpp/test/vpp_papi_provider.py", line 54, in
>>   __init__
>> 
>>   self.papi = VPP(jsonfiles)
>> 
>> File "build/bdist.linux-x86_64/egg/vpp_papi/vpp_papi.py", line 78, in
>>   __init__
>> 
>>   self.add_message(m[0], m[1:])
>> 
>> File "build/bdist.linux-x86_64/egg/vpp_papi/vpp_papi.py", line 286, in
>>   add_message
>> 
>>   args[field_name] = self.__struct(*f)
>> 
>> File "build/bdist.linux-x86_64/egg/vpp_papi/vpp_papi.py", line 151, in
>>   __struct
>> 
>>   raise ValueError(1, 'Invalid message type: ' + t)
>> 
>>   ValueError: (1, u'Invalid message type: vl_api_local_locator_t')
>> 
>>
>> 
>>
>> 
>>   It seems that issue has been introduced by following commit:
>> 
>>
>> 
>>   vpp@vpp-VirtualBox:~/Documents/vpp$ git bisect good
>> 
>>   694396dc589b4fe75b1fad02fde1d3c3cdaeef04 is the first bad commit
>> 
>>   commit 694396dc589b4fe75b1fad02fde1d3c3cdaeef04
>> 
>>   Author: Filip Tehlar 
>> 
>>   Date:   Fri Feb 17 14:29:11 2017 +0100
>> 
>>
>> 
>>   Add Overlay Network Engine API
>> 
>>  
>> 
>>   Change-Id: I6b5984df176688f0722a2888e73f05d8ed8b9310
>> 
>>   Signed-off-by: Filip Tehlar 
>> 
>>
>> 
>>   :04 04 b3fb6d7c953b74ba85e0345f2987452f643b28dc
>>   a73d9ebb51dcda1fb4795961af1ce5fce418009b M src
>> 
>>
>> 
>>   So there are two questions:
>> 
>>
>> 
>>   1.  Could somebody have a look on this issue, please?
>> 
>>   2.  Are these (make test) tests really part of vpp-verify-master-{os}
>>   jobs (i.e. part of make verify)? I didn’t find any information about
>>   result of these tests in console output of the test
>>   ([1]https://jenkins.fd.io/job/vpp-verify-master-ubuntu1604/3963/console 
>> ).
>> 
>>
>> 
>>   Thanks,
>> 
>>   Jan
>> 
>> References
>> 
>>   Visible links
>>   1. https://jenkins.fd.io/job/vpp-verify-master-ubuntu1604/3963/console 
>> 
> ___
> 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] "TCP Shortcuts" for containers

[Florin Coras]

Hi Vadim, 

Code is still under development. We plan to merge the TCP stack and the shared 
memory FIFO code prior to 17.04 FC0. In the mean time, you can check a draft of 
what’s been done until now here [1]. Note however that most of the code is 
still in a state of flux. 

HTH, 
Florin

[1] https://gerrit.fd.io/r/#/c/5150 

> On Feb 22, 2017, at 8:31 PM, Sukhomlinov, Vadim  
> wrote:
> 
> Hi All,
>  
> On wiki there is slidedeck 
> https://wiki.fd.io/view/File:Fdio_minisummit_-_containers_(theme).pptx 
>  
> which mention handling of TCP connections between namespaces thru FIFO Shared 
> Memory buffers. However, I can’t find where it’s implemented and what is 
> “official” name for this feature and how to configure VPP and application to 
> use it.  I’m also very interested in performance data for this approach.
>  
> Thanks in advance,
> Vadim
> ___
> 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 project committer nomination: Neale Ranns

[Florin Coras]

+1

Florin

> On Oct 26, 2016, at 7:30 PM, Dave Barach (dbarach)  wrote:
> 
> I would like to nominate Neale Ranns as a vpp project committer. Neale 
> designed and built the vpp FIB 2.0, a massive contribution. 
>  
> History of Neale’s merged contributions to the vpp project: 
> https://gerrit.fd.io/r/#/q/status:merged+owner:%22Neale+Ranns+%253Cnranns%2540cisco.com%253E%22
>  
> 
>  
> Would the current vpp committers please vote (+1, 0, -1) by email to 
> vpp-dev@lists.fd.io  no later than Tuesday, 11/1 
> at 11:59pm EDT?
>  
> I would like to complete the process at next Thursday’s TSC meeting.
>  
> Thanks... Dave
>  
>  
>  
>  
> ___
> 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] [csit-dev] CSIT encapsulation test are failing

[Florin Coras]

Hi Peter, 

I just pushed [1] to address this issue. Let me know if the problem persists. 

Florin

[1] https://gerrit.fd.io/r/#/c/4115/1 

> On Dec 5, 2016, at 8:08 AM, Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at 
> Cisco)  wrote:
> 
> Hello vpp-dev,
>  
> I would like to ask if anyone have idea what may be wrong?
>  
> Thank you.
>  
> Peter Mikus
> Engineer – Software
> Cisco Systems Limited
>  
> From: Peter Mikus -X (pmikus - PANTHEON TECHNOLOGIES at Cisco) 
> Sent: Wednesday, November 30, 2016 7:58 AM
> To: vpp-dev >
> Cc: Maciek Konstantynowicz (mkonstan)  >; csit-...@lists.fd.io 
> 
> Subject: RE: CSIT encapsulation test are failing
>  
> Hello vpp-dev,
>  
> I’ve noticed that since dpdk-16.11 is merged in VPP, our encapsulation tests 
> for LISP IP4oIP4 and IP6oIP4 and also VXLANoIP4 is failing due to:
>  
> vat#CountNode  Reason
>   99  dpdk-inputRx L4 checksum errors
>  
> This does not affect oIP6 encapsulations, which might be interesting to 
> compare.
>  
> In DPDK16.11 I’ve found there was some rework regarding the Rx L4 checksum 
> handling in 
> (http://www.dpdk.org/browse/dpdk/commit/?id=9bc52f49fcfe2a499b1738700d857427c1433a5b
>  
> )
>  - Maybe it is not related but does anybody know by chance what might be the 
> issue?
>  
> Packet traces attached. I do not see packets coming from interface with 
> encapsulation. Encapsulations are done between two VPP nodes.
>  
> Thank you.
>  
> ___
> csit-dev mailing list
> csit-...@lists.fd.io 
> https://lists.fd.io/mailman/listinfo/csit-dev 
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Committer / Maintainer model.

[Florin Coras]

Wouldn’t it be better to have separate projects for each plugin (or maybe 
groups of them) and thereby have maintainers automatically become committers 
within their respective projects? As far as I can see this diminishes load on 
VPP committers and gives the required ‘power' to the interested parties. 

Just my 0.02$

Florin

> On Dec 21, 2016, at 10:25 AM, Damjan Marion  wrote:
> 
>> 
>> On 21 Dec 2016, at 18:49, Kinsella, Ray  wrote:
>> 
>> 
>>> If somebody submits plugin change + 3 lines of new
>>> code in critical ip4 path, I will greatly benefit from +1 received from
>>> plugin maintainer and i will focus on this 3 lines.
>>> If I don’t have +1 from plugin maintainer, i will just left whole diff
>>> in the gerrit, simply because i don't have a clue about that plugin.
>> 
>> But really, the committer will have nothing to add about the plugin in this 
>> case.
>> 
>> A more efficient process would be to let an IPv4 committer review and commit 
>> the IPv4 change, with the Plugin committer separately doing likewise.
>> 
>> Many open source project require that patches be made separately for 
>> component.
> 
> Yes, and hire one guy to bitch with people who are not following that rule...
> ___
> 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 project committer nomination: Sergio Gonzales Monroy

[Florin Coras]

+1

Florin

> On Mar 27, 2017, at 4:12 AM, Damjan Marion (damarion)  
> wrote:
> 
> 
> Hello VPP committers,
> 
> I would like to nominate Sergio Gonzales Monroy as a VPP project committer.
> 
> History of Sergio’s merged contributions to the VPP project: 
> 
> https://gerrit.fd.io/r/#/q/owner:sergio.gonzalez.monroy%2540intel.com+status:merged
> 
> shows significant amount of work done on VPP crypto/IPSec code including the 
> integration with DPDK CryptoDev.
> 
> Current VPP committers please vote (+1, 0, -1) by replying to this email 
> (reply-all), no later than 04.04.2017 6.00 AM PST.
> 
> Thanks,
> 
> Damjan
> 
> 
> ___
> 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 build issue on Ubuntu 16.04.2 LTS

[Florin Coras]

Hi Cristian, 

Did you try:

sudo apt-get remove —purge vpp

Florin

> On Mar 28, 2017, at 3:23 PM, Dumitrescu, Cristian 
> <cristian.dumitre...@intel.com> wrote:
> 
> Hi Florin,
>  
> I actually removed the old git clone and created a brand new one just before 
> I started getting this error.
>  
> We are potentially considering some leftover files from previous installation 
> somewhere in the file system, if there is such possibility for VPP?
>  
> Regards,
> Cristian
>   <>
>  <>From: Florin Coras [mailto:fcoras.li...@gmail.com] 
> Sent: Tuesday, March 28, 2017 10:12 PM
> To: Dumitrescu, Cristian <cristian.dumitre...@intel.com>
> Cc: Burt Silverman <bur...@gmail.com>; vpp-dev <vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] VPP build issue on Ubuntu 16.04.2 LTS
>  
> Hi Cristian, 
>  
> Did you try cleaning everything up? 
>  
> git clean -fdx 
> make bootstrap 
> ..
>  
> HTH,
> Florin
>  
> On Mar 28, 2017, at 1:28 PM, Dumitrescu, Cristian 
> <cristian.dumitre...@intel.com <mailto:cristian.dumitre...@intel.com>> wrote:
>  
> Hi Burt,
>  
> No network connectivity issues I am afraid. I pasted the output of my last 
> re-run of “make install-dep” in the previous email.
>  
> Regards,
> Cristian
>  
> From: Burt Silverman [mailto:bur...@gmail.com <mailto:bur...@gmail.com>] 
> Sent: Tuesday, March 28, 2017 5:47 PM
> To: Dumitrescu, Cristian <cristian.dumitre...@intel.com 
> <mailto:cristian.dumitre...@intel.com>>
> Cc: vpp-dev <vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>>
> Subject: Re: [vpp-dev] VPP build issue on Ubuntu 16.04.2 LTS
>  
> Also, the fact that we saw PKG_CHECK_MODULES appear in your original output 
> tells me that pkg-config was not installed when your configure was running. 
> Otherwise, I believe it would have been macro expanded and you'd only see the 
> expanded form. The mystery remains about your "make install-dep" not working. 
> Is it possible that there is a network connectivity issue, and a related 
> error message but the error message did not stick out clearly?
> 
> Baffled Burt
> ​
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> https://lists.fd.io/mailman/listinfo/vpp-dev 
> <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 build issue on Ubuntu 16.04.2 LTS

[Florin Coras]

Hi Cristian, 

Did you try cleaning everything up? 

git clean -fdx 
make bootstrap 
..

HTH,
Florin

> On Mar 28, 2017, at 1:28 PM, Dumitrescu, Cristian 
>  wrote:
> 
> Hi Burt,
>  
> No network connectivity issues I am afraid. I pasted the output of my last 
> re-run of “make install-dep” in the previous email.
>  
> Regards,
> Cristian
>   <>
>  <>From: Burt Silverman [mailto:bur...@gmail.com] 
> Sent: Tuesday, March 28, 2017 5:47 PM
> To: Dumitrescu, Cristian 
> Cc: vpp-dev 
> Subject: Re: [vpp-dev] VPP build issue on Ubuntu 16.04.2 LTS
>  
> Also, the fact that we saw PKG_CHECK_MODULES appear in your original output 
> tells me that pkg-config was not installed when your configure was running. 
> Otherwise, I believe it would have been macro expanded and you'd only see the 
> expanded form. The mystery remains about your "make install-dep" not working. 
> Is it possible that there is a network connectivity issue, and a related 
> error message but the error message did not stick out clearly?
> 
> Baffled Burt
> ​
> ___
> 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-packet generator can not send tcp packets

[Florin Coras]

Hi, 

Try “session enable” before programming the stream. Note however that the 
generator is not stateful so probably not what you’re looking for.

Florin


> On Apr 10, 2017, at 8:18 PM, 王鹏 <15803846...@163.com> wrote:
> 
> Hello, everyone
>  when we use vpp-packet generator to send udp packets, everything is 
> OK！But, when execingTCP packet scripts, it can not send tcp packets. The 
> packet generator does not work！Why？Do anyone have the same problem?
> 
> 
> 
>  
> 
> ___
> 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] Missing session.api.h file

[Florin Coras]

Hi Jon, 

Apologies about that. Alexander was kind enough to provide a quick solution 
here [1]. Will merge as soon as it passes verify.

Florin

[1] https://gerrit.fd.io/r/#/c/5621/ 

> On Mar 3, 2017, at 4:38 PM, Jon Loeliger  wrote:
> 
> VPP-ers,
> 
> I've just build RPM packages out of the current top-of-tree VPP at
> commit c83c3b7f117b981b677f646a0e30f44ec70de239.
> 
> After a yum install, a file in /usr/include/ references session.api.h:
> 
> $ grep -r session.api.h /usr/include/
> /usr/include/vnet/vnet_all_api_h.h:#include 
> 
> Yet it is not installed:
> 
> $ find /usr/include -name session\*
> /usr/include/vnet/session
> /usr/include/vnet/session/session.h
> 
> In fact, if you look in the RPM build staging directory, it is missing
> there as well:
> 
> $ find  build-root/install-vpp-native/vpp/include/ -name session\*
> build-root/install-vpp-native/vpp/include/vnet/session
> build-root/install-vpp-native/vpp/include/vnet/session/session.h
> 
> Thanks,
> jdl
> 
> ___
> 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] TCP stack in master

[Florin Coras]

Hi Alec, 

The code is still very much under development. We pushed it out early to make 
the API freeze window but our goal is to have something stable for the 17.04 
release (due in about a month or so). We’ll try to have some decent 
documentation by then, but in the mean time, running the code will probably 
result in pain. :)

Thanks,
Florin

 
> On Mar 2, 2017, at 6:51 AM, Alec Hothan (ahothan)  wrote:
> 
>  
> Impressive!
> Is there any document describing the features, how is it integrated with the 
> rest of VPP, CLI, compile flags, APIs and short term use cases?
>  
> Thanks
>  
>Alec
>  
>  
> From:  on behalf of "Damjan Marion (damarion)" 
> 
> Date: Thursday, March 2, 2017 at 5:45 AM
> To: vpp-dev 
> Subject: [vpp-dev] TCP stack in master
>  
>  
> In case people didn’t notice, since yesterday we have full TCP stack
> in master. It is “just” 17 KLOCs.
>  
> Thanks to Dave, Florin and all other folks participated in development of 
> this great addition to VPP.
>  
> Damjan
> ___
> 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 for packet prepending / trimming

[Florin Coras]

Hi Hongbin, 

See the functions here: https://git.fd.io/vpp/tree/src/vlib/buffer.h#n259

If they’re not enough, feel free to add more. 

Florin

> On Apr 18, 2017, at 3:33 PM, Hongbin Li  wrote:
> 
> Hello,
> 
> I am evaluating vpp as a tool to conduct packet prepending / trimming. 
> 
> Is there any functions available in vpp to manipulate vlib_buffer_t, just 
> like rte_pktmbuf_prepend and rte_pktmbuf_trim in DPDK?
> 
> Regards,
> Hongbin 
> ___
> 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] [csit-dev] API Change Proposal: explicit FIB table create and delete

[Florin Coras]

+1

Florin

> On Aug 3, 2017, at 12:56 AM, Neale Ranns (nranns)  wrote:
> 
> 
> Dear All,
> 
> I would like to propose the addition of a new API to explicitly create and 
> delete FIB tables. At present the only way to create FIB tables (for e.g. 
> VRFs) is to:
> 1) Bind an interface to a new table index; ‘set int ip table Eth0  TABLE_ID>
> 2) Add a route in a new table and set the create_vrf_if_needed flag
> 
> With the addition of an explicit create we have the possibility to set 
> per-table properties, like the flow-hash and (potentially) the mtrie stride 
> (to favour memory over performance for small VRFs). With an explicit delete 
> VPP is aware when it is safe to delete the table.
> 
> An explicit API makes the management of FIB tables by the agent/client the 
> same as managing any other table resource, like Bridge-Domains or classify 
> tables.
> 
> Regards,
> neale
> 
> ___
> csit-dev mailing list
> csit-...@lists.fd.io
> https://lists.fd.io/mailman/listinfo/csit-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Verify jobs failing - opensuse

[Florin Coras]

I second the request. It would be really helpful to have this fixed by Monday 
morning, CEST time. 

Thanks, 
Florin

> On Aug 12, 2017, at 8:28 AM, Neale Ranns (nranns)  wrote:
> 
> 
> Hi All,
> 
> The verify jobs are failing due to the new opensuse job, e.g. from:
>  https://gerrit.fd.io/r/#/c/8001/
> error is below.
> 
> Can we please fix ASAP or disable them.
> 
> Thanks,
> Neale
> 
> 
> 18:49:56 [vpp-verify-master-opensuse] $ /bin/bash 
> /tmp/hudson7746568270930707597.sh
> 18:49:56 make[1]: Entering directory 
> '/w/workspace/vpp-verify-master-opensuse/test'
> 18:49:56 make[1]: virtualenv: Command not found
> 18:49:56 Makefile:159: recipe for target 'checkstyle' failed
> 18:49:56 make[1]: *** [checkstyle] Error 127
> 18:49:56 make[1]: Leaving directory 
> '/w/workspace/vpp-verify-master-opensuse/test'
> 18:49:56 Makefile:379: recipe for target 'test-checkstyle' failed
> 18:49:56 make: *** [test-checkstyle] Error 2
> 18:49:56 Build step 'Execute shell' marked build as failure
> 
> 
> ___
> 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] Verify jobs failing - opensuse

[Florin Coras]

Done. Thanks, Ed!

Florin

> On Aug 12, 2017, at 1:26 PM, Ed Warnicke <hagb...@gmail.com> wrote:
> 
> If one of you would push a revert of: https://gerrit.fd.io/r/#/c/7998/ 
> <https://gerrit.fd.io/r/#/c/7998/>
> 
> I'd be happy to merge it.
> 
> Ed
> 
> On Sat, Aug 12, 2017 at 1:17 PM, Florin Coras <fcoras.li...@gmail.com 
> <mailto:fcoras.li...@gmail.com>> wrote:
> I second the request. It would be really helpful to have this fixed by Monday 
> morning, CEST time.
> 
> Thanks,
> Florin
> 
> > On Aug 12, 2017, at 8:28 AM, Neale Ranns (nranns) <nra...@cisco.com 
> > <mailto:nra...@cisco.com>> wrote:
> >
> >
> > Hi All,
> >
> > The verify jobs are failing due to the new opensuse job, e.g. from:
> >  https://gerrit.fd.io/r/#/c/8001/ <https://gerrit.fd.io/r/#/c/8001/>
> > error is below.
> >
> > Can we please fix ASAP or disable them.
> >
> > Thanks,
> > Neale
> >
> >
> > 18:49:56 [vpp-verify-master-opensuse] $ /bin/bash 
> > /tmp/hudson7746568270930707597.sh
> > 18:49:56 make[1]: Entering directory 
> > '/w/workspace/vpp-verify-master-opensuse/test'
> > 18:49:56 make[1]: virtualenv: Command not found
> > 18:49:56 Makefile:159: recipe for target 'checkstyle' failed
> > 18:49:56 make[1]: *** [checkstyle] Error 127
> > 18:49:56 make[1]: Leaving directory 
> > '/w/workspace/vpp-verify-master-opensuse/test'
> > 18:49:56 Makefile:379: recipe for target 'test-checkstyle' failed
> > 18:49:56 make: *** [test-checkstyle] Error 2
> > 18:49:56 Build step 'Execute shell' marked build as failure
> >
> >
> > ___
> > vpp-dev mailing list
> > vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> > https://lists.fd.io/mailman/listinfo/vpp-dev 
> > <https://lists.fd.io/mailman/listinfo/vpp-dev>
> 
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> https://lists.fd.io/mailman/listinfo/vpp-dev 
> <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] Host stack TCP

[Florin Coras]

Hi Hamid, 

To run the builtin client/server do 

test tcp [server|clients] 

To see the cli options, just execute the command appended with “?”. The options 
list not complete right now but this patch [1] fixes that. 

Hope it helps, 
Florin

[1] https://gerrit.fd.io/r/#/c/8041/ 

> On Aug 13, 2017, at 12:58 AM, hamid nak  wrote:
> 
> Hi all,
> I don't know how to run builtin_server and builtin_client examples. Also 
> don't know how to set LD_PRELOAD to run every native application on top of 
> vpp. Please help!
> ___
> 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] set mapping from node to thread

[Florin Coras]

Hi Yuliang, 

Are you running with dpdk or with tap/af_packet interfaces? As far as I 
remember multithreading for the last two might not work properly. 

Florin

> On Jul 7, 2017, at 5:55 PM, Yuliang Li  wrote:
> 
> I printed 3 thread_index, and all 3 shows the same value: 
> 
> 1. vlib_frame_t's thread_index:
> For each pending frame p: 
> vlib_pending_frame_t *p = nm->pending_frames + i;
> I get the vlib_frame_t f: 
> vlib_frame_t *f = vlib_get_frame (vm, p->frame_index);
> and I print f->thread_index
> 
> 2. vlib_node_runtime_t's thread_indes:
> For each pending frame p, I get its node runtime nr:
> vlib_node_runtime_t *nr = vec_elt_at_index 
> (nm->nodes_by_type[VLIB_NODE_TYPE_INTERNAL], p->node_runtime_index);
> and I print nr->thread_index
> 
> 3. vlib_main_t's thread_index:
> I print vm->thread_index
> 
> 
> On Fri, Jul 7, 2017 at 5:37 PM, Dave Barach (dbarach)  > wrote:
> What exactly were you printing? Vlib_pending_frame_t’s don’t have a 
> thread_index field...: <>
>  
> 
>  
> 
> /* A frame pending dispatch by main loop. */
> 
> typedef struct
> 
> {
> 
>   /* Node and runtime for this frame. */
> 
>   u32 node_runtime_index;
> 
>  
> 
>   /* Frame index (in the heap). */
> 
>   u32 frame_index;
> 
>  
> 
>   /* Start of next frames for this node. */
> 
>   u32 next_frame_index;
> 
>  
> 
>   /* Special value for next_frame_index when there is no next frame. */
> 
> #define VLIB_PENDING_FRAME_NO_NEXT_FRAME ((u32) ~0)
> 
> } vlib_pending_frame_t;
> 
>  
> 
> Thanks… Dave
> 
>  
> 
> From: Yuliang Li [mailto:yuliang...@yale.edu ] 
> Sent: Friday, July 7, 2017 8:04 PM
> To: Dave Barach (dbarach) >
> Cc: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] set mapping from node to thread
> 
>  
> 
> Hi Dave,
> 
>  
> 
> Thanks for the detailed response. 
> 
>  
> 
> However, from the experiment I did, I see the same packet being processed by 
> two threads. That is why I asked this question. Maybe I made some mistakes, 
> here is what I did:
> 
>  
> 
> - In vlib_main_or_worker_loop function, I print out all pending frames here, 
> as well as the thread_index of them, and the node name.
> 
> - I start the vpp with 4 worker threads, and set up SNAT according to the 
> progressive tutorial .
> 
> - I run iperf that go through the SNAT.
> 
>  
> 
> The printed information shows that, each TCP packet from the inside to the 
> outside of the SNAT will go through the ethernet-input and snat-in2out. But 
> the thread_index at the ethernet-input is 2, while the thread_index at 
> snat-in2out is 1.
> 
>  
> 
> Is the above expected?
> 
>  
> 
> Thanks,
> 
>  
> 
> On Fri, Jul 7, 2017 at 12:22 PM, Dave Barach (dbarach)  > wrote:
> 
> Dear Yuliang, <>
>  
> 
> From a high level: vpp creates N identical graph replicas in a multi-core 
> configuration. When practicable, we use hardware RSS hashing to ensure that 
> all packets belonging to a specific flow are processed [in order!] by the 
> same thread / graph replica. In effect, embarrassing parallelism.
> 
>  
> 
> It’s easy enough to hand off packets between threads - see the “handoff-node” 
> - but we avoid that whenever possible.
> 
>  
> 
> Although one could - and I have - divided graph nodes across threads to 
> create pipelines, that scheme needs significant dynamic tuning to handle a 
> traffic pattern change. It’s hard to map nodes onto cores so that each thread 
> in a pipeline uses approximately the same number of clocks/pkt; critical, 
> since pipelines run at the speed of the slowest stage.
> 
>  
> 
> It’s possible to hand off a full frame of packets for less than two 
> clocks/pkt. Unfortunately, that’s the least significant issue. Handing off a 
> packet from one core/thread to another guarantees a bunch of memory/cache 
> subsystem pressure as the system moves packet data and metadata from A to B.  
> 
>  
> 
> HTH... Dave
> 
>  
> 
> From: vpp-dev-boun...@lists.fd.io  
> [mailto:vpp-dev-boun...@lists.fd.io ] On 
> Behalf Of Yuliang Li
> Sent: Friday, July 7, 2017 1:14 PM
> To: vpp-dev@lists.fd.io 
> Subject: [vpp-dev] set mapping from node to thread
> 
>  
> 
> Hi,
> 
>  
> 
> Is there a way to set which node should run on which thread? And is there a 
> command that shows the mapping from nodes to threads?
> 
>  
> 
> Thanks,
> 
> --
> 
> Yuliang Li
> 
> PhD student
> 
> Department of Computer Science
> 
> Yale University
> 
> 
> 
> 
>  
> 
> -- 
> 
> Yuliang Li
> 
> PhD student
> 
> Department of Computer Science
> 
> Yale University
> 
> 
> 
> 
> -- 
> Yuliang Li
> PhD student
> Department of Computer Science
> Yale University
> ___
> 

Re: [vpp-dev] [csit-dev] 17.07 Release

[Florin Coras]

Awesome! 

Congrats to you and the whole community for all the hard work!

Cheers, 
Florin


> On Jul 20, 2017, at 4:56 PM, Neale Ranns (nranns)  wrote:
> 
> 
> Dear VPP community,
> 
> The VPP 17.07 release is complete. The release artefacts are now available on 
> the nexus server.
> 
> I’d like to take this opportunity to thank you all for your continued support 
> for VPP.
> 
> Best regards,
> Neale
> 
> 
> ___
> csit-dev mailing list
> csit-...@lists.fd.io
> https://lists.fd.io/mailman/listinfo/csit-dev

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] 17.10 Release Dates and Features

[Florin Coras]

Folks, 

It’s that time again! We are compiling the list of features we plan to release 
in 17.10 and a release schedule. For more details, see the wiki page here [1].

Please feel free to add any features you are/will be working on and intend to 
release for 17.10. As always, the list serves as an indication of intent to the 
wider community and does not come with an implicit commitment to deliver said 
features within the release’s time frame. 

Regards, 
Florin (with the release manager hat on)

[1] https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_17.10 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] User-space TCP Stack

[Florin Coras]

Hi Stephen,

The goal is to have a complete userspace stack, i.e., a session layer 
accessible over VPP’s binary API, a transport layer, a POSIX-like wrapper 
library for interacting with the stack and a shared memory mechanism to pass 
data between apps and VPP. We have support for pluggable transports but the 
only one actively being developed right now is TCP. The wrapper library (VCL) 
will soon be published, but Keith can tell you more about it.

Florin 

> On Aug 9, 2017, at 7:55 AM, STEPHEN PETRIDES  
> wrote:
> 
> Hi All,
> 
> I came across this exchange 
> (https://www.mail-archive.com/vpp-dev@lists.fd.io/msg03112.html 
> ) in the 
> mailing list and wanted to learn more about what features of the stack are 
> available currently and what is still being developed.
> 
> For the internal/external apps mentioned, how do these work and what features 
> are currently supported?
> 
> For the wrapper library being developed, what will this look like? Will there 
> be an API or interface for endpoint applications?
> 
> Thank you.
> 
> -- 
> Stephen
> ___
> 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] user space TCP stack

[Florin Coras]

Hi Hamid, 

Yes, we do have a userspace TCP stack but it is still under development. You 
can find examples of external apps here [1] and internal apps here [2, 3]. 

All of these use the binary api to interact with the session layer code. We’ll 
soon publish a wrapper library that should make interaction with the stack much 
easier. 

Regards, 
Florin

[1] https://git.fd.io/vpp/tree/src/uri/uri_tcp_test.c 

[2] https://git.fd.io/vpp/tree/src/vnet/tcp/builtin_server.c 

[3] https://git.fd.io/vpp/tree/src/vnet/tcp/builtin_client.c 


> On Aug 7, 2017, at 3:38 AM, kheirabadi  wrote:
> 
> ​Hi,
> I trying to use mTCP in my application but it is very primitive, for example 
> it permits only one epoll instance and does not have shutdown API equivalent. 
> Does VPP support user space TCP stack similar to mTCP? if so where is a 
> sample application using it?
> Thanks,
> hamid
> ___
> 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] APIs frozen date , 2017-09-13

[Florin Coras]

Hi Shachar, 

Yes, the API freeze date for 17.10 is 2017-09-13.

Florin

> On Aug 19, 2017, at 11:50 PM, Shachar Beiser  wrote:
> 
> Hi ,
>I have just joined this community. I would like to verify my current 
> understanding.
>The due date for APIs frozen is : 2017-09-13.
>Is that right ?
> 
>  -Shachar Beiser.
>  
>  
> 2017-09-13 
> APIs frozen. Only low-risk changes accepted on main branch.
>  
>  
>  
> ___
> 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] [csit-dev] vpp-verify-master-centos7 failure (was: Change in vpp[master]: Build uri_udp_test app)

[Florin Coras]

Dave, 

A quick solution for that problem is to switch uri.am back to noinst_PROGRAMS. 

Still, I’m also curious as to why that fails only for Centos. 

HTH,
Florin

> On May 17, 2017, at 7:27 PM, Dave Wallace <dwallac...@gmail.com> wrote:
> 
> Tom,
> 
> The verify job that builds VPP on Centos7 failed on the patch 
> https://gerrit.fd.io/r/6672 <https://gerrit.fd.io/r/6672> due to an error 
> installing DPDK:
> 
>  %< 
> 00:04:23.601 make[2]: Leaving directory 
> `/w/workspace/vpp-verify-master-centos7/dpdk'
> 00:04:23.601 sudo rpm -Uih vpp-dpdk-devel-17.05-vpp1.x86_64.rpm
> 00:04:23.710 
> 00:04:23.778 package vpp-dpdk-devel-17.05-vpp3.x86_64 (which is newer 
> than vpp-dpdk-devel-17.05-vpp1.x86_64) is already installed
> 00:04:23.781 make[1]: *** [install-rpm] Error 2
> 00:04:23.781 make[1]: Leaving directory 
> `/w/workspace/vpp-verify-master-centos7/dpdk'
> 00:04:23.782 make: *** [dpdk-install-dev] Error 2
> 00:04:23.811 Build step 'Execute shell' marked build as failure
>  %< 
> 
> Is this a known failure signature?  
> I think that vpp-verify-master-centos7 should  un-install the 
> vpp-dpdk-dev-*.rpm before the running the build to avoid this error case.  Do 
> you agree?
> 
> I wonder if this case shows up because the build minion was re-used as 
> opposed to being freshly spawned.  If that is the case, then all of the vpp 
> packages that are installed as part of the verify job should be un-installed 
> after the test build has completed (i.e. in the teardown phase).
> 
> Thanks,
> -daw-
> 
>  Forwarded Message 
> Subject:  Change in vpp[master]: Build uri_udp_test app
> Date: Wed, 17 May 2017 23:21:15 +
> From: fd.io JJB (Code Review) <ger...@fd.io> <mailto:ger...@fd.io>
> Reply-To: jobbuil...@projectrotterdam.info 
> <mailto:jobbuil...@projectrotterdam.info>
> To:   shrinivasan ganapathy <shrinivasanganapa...@gmail.com> 
> <mailto:shrinivasanganapa...@gmail.com>
> CC:   Florin Coras <florin.co...@gmail.com> <mailto:florin.co...@gmail.com>, 
> Dave Wallace <dwallac...@gmail.com> <mailto:dwallac...@gmail.com>, Keith 
> Burns<alaga...@gmail.com> <mailto:alaga...@gmail.com>, Ed Kern 
> <ejkern_st...@mac.com> <mailto:ejkern_st...@mac.com>
> 
> fd.io JJB has posted comments on this change. ( https://gerrit.fd.io/r/6672 
> <https://gerrit.fd.io/r/6672> )
> 
> Change subject: Build uri_udp_test app
> ..
> 
> 
> Patch Set 5: Verified-1
> 
> Build Failed 
> 
> https://jenkins.fd.io/job/vpp-verify-master-centos7/5490/ 
> <https://jenkins.fd.io/job/vpp-verify-master-centos7/5490/> : 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-verify-master-centos7/5490/ 
> <https://jenkins.fd.io/job/vpp-verify-master-centos7/5490/> )
> 
> Logs: 
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-centos7/5490
>  
> <https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-centos7/5490>
> 
> https://jenkins.fd.io/job/vpp-verify-master-ubuntu1604/5495/ 
> <https://jenkins.fd.io/job/vpp-verify-master-ubuntu1604/5495/> : SUCCESS
> 
> Logs: 
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1604/5495
>  
> <https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-ubuntu1604/5495>
> 
> https://jenkins.fd.io/job/vpp-csit-verify-virl-master/5494/ 
> <https://jenkins.fd.io/job/vpp-csit-verify-virl-master/5494/> : SUCCESS
> 
> Logs: 
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-csit-verify-virl-master/5494
>  
> <https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-csit-verify-virl-master/5494>
> 
> https://jenkins.fd.io/job/vpp-docs-verify-master/4090/ 
> <https://jenkins.fd.io/job/vpp-docs-verify-master/4090/> : SUCCESS
> 
> Logs: 
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-docs-verify-master/4090
>  
> <https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-docs-verify-master/4090>
> 
> https://jenkins.fd.io/job/vpp-make-test-docs-verify-master/1818/ 
> <https://jenkins.fd.io/job/vpp-make-test-docs-verify-master/1818/> : SUCCESS
> 
> Logs: 
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-make-test-docs-verify-master/1818
>  
> <https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-make-test-docs-verify-master/1818>
> 
> -- 
> To view, visit https://gerrit.fd.io/r/6672

Re: [vpp-dev] VPP now has basic tab completion

[Florin Coras]

Awesome!

Florin

> On May 23, 2017, at 12:00 PM, Luke, Chris  wrote:
> 
> Thanks to the work of Yoann we now have some tab-completion goodness in the 
> debug CLI! I know it has been a long-desired feature for many people here.
>  
> It works pretty much as you’d expect with the obvious caveat it can only 
> complete for things registered with the CLI parser; where commands implement 
> their own unformat() parsing for parameters we have no hope of completing on, 
> or after, those.
>  
> Enjoy! Feedback and enchancements welcome, of course. :)
>  
> Chris.
> ___
> 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] Is the TCP implementation multi-instance capable?

[Florin Coras]

Hi Nagp, 

No, the current implementation is not multi-fib capable, i.e., all connections 
go through the main fib. Transport endpoint structs used in the session api and 
the application interface already carry vrfs but we’re not yet using them in 
tcp and for session lookup. We do however plan to support this in the future. 

Could you elaborate on why you would need support for this?

HTH,
Florin

> On May 24, 2017, at 10:28 PM, Nagaprabhanjan Bellaru  
> wrote:
> 
> I am asking this because the session lookup functions in tcp_input.c does not 
> seem to be taking a fib index or a table id to look up the session - just the 
> usual 4-tuple.
> 
> If it is done in a different way, please help me see it.
> 
> Thanks,
> -nagp
> ___
> 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] Is there TCP performance test report?

[Florin Coras]

Hi, 

Parts of the code critical to performance are still under heavy development. 
Thereby, until we finish optimizing the fast path and extending the congestion 
control code, performance numbers will not be that relevant. Once things 
somewhat stabilize, and hopefully that will happen within the 17.07 timeframe, 
we’ll put together a report and notify the community. 

Cheers,
Florin

> On May 25, 2017, at 1:53 AM,   
> wrote:
> 
> Hi,Florin
> 
> We want to get the TCP session performance report about Throughput and CPS, 
> where can't we get it ?
> 
> 
> 

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP & UDP Traffic

[Florin Coras]

Hi Alessio, 

Take a look at udp_register_dst_port () and at how it is used in other places 
(e.g., lisp/vxlan).

Cheers, 
Florin

> On May 30, 2017, at 1:01 AM, Alessio Silvestro  
> wrote:
> 
> Dear all,
> 
> I am currently working on VPP and I am interested in receiving UDP traffic at 
> a specific port.
> 
> However, I have seen that the project regarding L4 protocols (e.g., TCP, UDP) 
> namely TLDK (Transport Layer Development Kit), is still a project proposal.
> 
> Is there a simple way to listen to UDP traffic on the current VPP 
> implementation -- considering that UDP does not need any special treatment 
> (e.g., re-ordering, sequence number, etc.)?
> 
> Thanks for any help!
> 
> Best regards,
> Alessio
> ___
> 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] Build failures on master

[Florin Coras]

Hi Tomas, 

That sure is weird. 

(backup everything that’s not in git)
git clean -fdx
make bootstrap
make build

Do you still see the issue?

HTH, 
Florin

> On Jun 1, 2017, at 6:18 AM, Tomas Brännström  
> wrote:
> 
> Hi
> I'm getting build errors when trying to build a recent commit on the master 
> branch:
> 
> /home/ubuntu/git/vpp/build-data/../src/vnet/tcp/builtin_client.c:25:29: fatal 
> error: vpp/app/version.h: No such file or directory
>  #include 
>  ^
> compilation terminated.
> 
> I'm building using the "extras/vagrant/build.sh" script (or 
> "build-root/vagrant/build.sh" in slightly earlier versions). What's strange 
> here is that I built it successfully on the exact same commit yesterday on 
> another machine. The commit in question is 
> 79ea7ec3b3c04d334a21107818c64d70c42b99ae but I tried on the latest master as 
> well.
> 
> Also, I tried to build an earlier version (git tag v17.07-rc0) and got 
> another error, where the .deb files could not be built  because the "version" 
> was missing. I don't have the exact printout though.
> 
> Am I missing something here? I'm trying to build in an ubuntu trusty server 
> install, and it has worked before.
> 
> /Tomas
> 
> ___
> 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] Jira cleanup, FYI

[Florin Coras]

Chris, 

Thanks a lot!

Cheers, 
Florin

> On Sep 18, 2017, at 11:03 AM, Luke, Chris  wrote:
> 
> All,
>  
> As an FYI… I just did a bunch of cleanup in Jira. Closed a lot of issues 
> (~100) that were marked Complete but never actually Closed. A significant 
> number of these did not have fixed in dates, so for the ones completed in 
> 2017 I worked out which release they likely would have landed in before 
> closing.
>  
> As usual, if any of this was in error, feel free to undo.
>  
> Chris.
> ___
> 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 SIGSEGV

[Florin Coras]

Hi Stan, 

If I recall correctly, we update an adjacency only when adding a neighbor. So, 
I a few clarifying questions to better understand the problem:
- From your description am I right to understand that you manage to forward 
some traffic and only after some time hit the issue?
- Could you paste the fib entry that’s being updated (sh ip fib )? 
- Are you using VPP’s TCP stack?

Thanks, 
Florin

> On Sep 18, 2017, at 8:19 AM, Ratliff, Stanley  wrote:
> 
> Hi,
>  
> I’m getting a SIGSEGV in VPP trying to send a lot of traffic in one direction 
> via a TCP connection. I’ve enabled the VLIB_BUFFER_TRAJECTORY_TRACE, and I’m 
> getting this:
>  
> Context trace for bi 28664834 b 0x7fff5cd8bf00, visited 3
> ip4-lookup (238)
> ip4-rewrite (230)
> ip4-lookup (238)
>  
> Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
> vlib_increment_combined_counter (byte_increment=1448, packet_increment=1, 
> index=4294967295, cpu_index=, cm=0x7fffb5bec40c)
> at /home/sratliff/vpp/build-data/../src/vlib/counter.h:258
> 258   new_bytes = old_bytes + byte_increment;
> (gdb) bt
> #0  vlib_increment_combined_counter (byte_increment=1448, packet_increment=1, 
> index=4294967295, cpu_index=,
> cm=0x7fffb5bec40c) at 
> /home/sratliff/vpp/build-data/../src/vlib/counter.h:258
> #1  vnet_interface_output_node (vm=, node=, 
> frame=)
> at /home/sratliff/vpp/build-data/../src/vnet/interface_output.c:624
> #2  0x777567d2 in dispatch_node (vm=0x779a9240 
> , node=0x7fffb591d240, type=,
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=, 
> last_time_stamp=21044750699247852)
> at /home/sratliff/vpp/build-data/../src/vlib/main.c:998
> #3  0x77756b85 in dispatch_pending_node (vm=vm@entry=0x779a9240 
> , p=0x7fffb6c5a244,
> last_time_stamp=) at 
> /home/sratliff/vpp/build-data/../src/vlib/main.c:1136
> #4  0x7775732b in vlib_main_loop (vm=0x779a9240 
> ) at /home/sratliff/vpp/build-data/../src/vlib/main.c:1545
> #5  vlib_main (vm=vm@entry=0x779a9240 , 
> input=input@entry=0x7fffb5e9efa0)
> at /home/sratliff/vpp/build-data/../src/vlib/main.c:1681
> #6  0x77790373 in thread0 (arg=140737347490368) at 
> /home/sratliff/vpp/build-data/../src/vlib/unix/main.c:507
> #7  0x76a07c40 in clib_calljmp () at 
> /home/sratliff/vpp/build-data/../src/vppinfra/longjmp.S:110
> #8  0x7fffd4d0 in ?? ()
> #9  0x77790d02 in vlib_unix_main (argc=, 
> argv=)
> at /home/sratliff/vpp/build-data/../src/vlib/unix/main.c:575
> #10 0x in ?? ()
> (gdb)
>  
>  
> I’ve seen a couple of paths on the back-trace – this one, and one in mtrie.h. 
> It appears that the ip4-lookup sends the packet off to re-write, and the 
> Ethernet header *is* applied. Then, ip4_rewrite decides to send the packet 
> back to lookup, and of course, the current_data is pointing at the Ethernet 
> header, not the IP header. My surmise is that this has something to do with 
> the adjacency processing.  Is there any way to lengthen the amount of time 
> that an adjacency is seen to be “good”? It looks like traffic is caught in 
> the timeframe where VPP is ARPing, looking to refresh the adjacency, and this 
> traffic is misdirected. Or, I could be way out in left field…
>  
> Any pointers would be appreciated. 
>  
> Regards,
> Stan
> This electronic message and any files transmitted with it contains
> information from iDirect, which may be privileged, proprietary
> and/or confidential. It is intended solely for the use of the individual
> or entity to whom they are addressed. If you are not the original
> recipient or the person responsible for delivering the email to the
> intended recipient, be advised that you have received this email
> in error, and that any use, dissemination, forwarding, printing, or
> copying of this email is strictly prohibited. If you received this email
> in error, please delete it and immediately notify the sender.
> ___
> 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] Failed to use vcl_test_client

[Florin Coras]

Hi xyxue,

What you’re getting is a connect fail because, I assume from trace, the server 
is not started on the peer vpp. Because the server is not started, i.e., bind 
wasn’t called, when the peer vpp receives the syn it replies with a reset. That 
reset finally results in a connect fail notify. 

As for your other questions:

1. Obviously, the one in vpp is for handling connect requests from applications 
while the one in vppcom is for cut-through session. That is, vpp acts as 
introduction mechanism for the two apps which afterwards exchange data via 
shared memory fifos. 
2. For exchanging control messages, e.g., bind, connect, accept, they use the 
binary api. For exchanging data, that is, moving data from vpp to vcl and 
vice-versa, they use shared memory fifos. 
3. That message is a notification from vpp to the application (vcl in this 
case) regarding a previous connect attempt. As you’ve discovered, if is_fail=1, 
the connect attempt failed. 

Hope this helps, 
Florin

> On Sep 19, 2017, at 7:30 PM, 薛欣颖  wrote:
> 
> 
> Hi ,
> 
> There are still problems:
> root@ubuntu:/home/vpp_communication/vpp/build-root/install-vpp-native/vpp/bin#
>  ./vcl_test_client -U 1.1.1.2 22000
> 
> CLIENT: Connecting to server...
> vl_api_connect_session_reply_t_handler:697: [9478] connect failed: Session 
> failed to connect (-115)
> 
> Breakpoint 1, send_session_connected_callback (app_index=1, api_context=0, 
> s=0x0, is_fail=1 '\001')
> at 
> /home/vpp_communication/vpp/build-data/../src/vnet/session/session_api.c:157
> 157 {
> (gdb) bt
> #0  send_session_connected_callback (app_index=1, api_context=0, s=0x0, 
> is_fail=1 '\001')
> at 
> /home/vpp_communication/vpp/build-data/../src/vnet/session/session_api.c:157
> #1  0x7f35c658459c in stream_session_connect_notify (tc=0x7f358585e3f8, 
> is_fail=, 
> is_fail@entry=1 '\001') at 
> /home/vpp_communication/vpp/build-data/../src/vnet/session/session.c:489
> #2  0x7f35c6456972 in tcp_connection_reset (tc=tc@entry=0x7f358585e3f8)
> at /home/vpp_communication/vpp/build-data/../src/vnet/tcp/tcp.c:258
> #3  0x7f35c6429977 in tcp46_syn_sent_inline (is_ip4=1, 
> from_frame=, node=, 
> vm=) at 
> /home/vpp_communication/vpp/build-data/../src/vnet/tcp/tcp_input.c:2023
> #4  tcp4_syn_sent (vm=, node=, 
> from_frame=)
> at /home/vpp_communication/vpp/build-data/../src/vnet/tcp/tcp_input.c:2184
> #5  0x7f35c6962d14 in dispatch_node (last_time_stamp=204974335045786, 
> frame=0x7f35858596c0, 
> dispatch_state=VLIB_NODE_STATE_POLLING, type=VLIB_NODE_TYPE_INTERNAL, 
> node=0x7f3584da06c0, 
> 
> 
> code segment：
> int
> send_session_connected_callback (u32 app_index, u32 api_context,
>stream_session_t * s, u8 is_fail)
> {
>   vl_api_connect_session_reply_t *mp;
>   unix_shared_memory_queue_t *q;
>   application_t *app;
>   unix_shared_memory_queue_t *vpp_queue;
> 
>   app = application_get (app_index);
>   q = vl_api_client_index_to_input_queue (app->api_client_index);
> 
>   if (!q)
> return -1;
> 
>   mp = vl_msg_api_alloc (sizeof (*mp));
>   mp->_vl_msg_id = clib_host_to_net_u16 (VL_API_CONNECT_SESSION_REPLY); 
>   mp->context = api_context;
>   if (!is_fail)
> {
>   vpp_queue = session_manager_get_vpp_event_queue (s->thread_index);
>   mp->server_rx_fifo = pointer_to_uword (s->server_rx_fifo);
>   mp->server_tx_fifo = pointer_to_uword (s->server_tx_fifo);
>   mp->handle = stream_session_handle (s);
>   mp->vpp_event_queue_address = pointer_to_uword (vpp_queue);
>   mp->retval = 0;
> }
>   else
> {
>   mp->retval = clib_host_to_net_u32 
> (VNET_API_ERROR_SESSION_CONNECT_FAIL);  
> }
>   vl_msg_api_send_shmem (q, (u8 *) & mp);
>   return 0;
> }
> 
> ruturn message to VCL， connect failed: Session failed to connect 
> 
> I have two question :
> 1.  there are two function "vl_api_connect_sock_t_handler", one in 
> session_api.c,  another in vppcom.c, 
> How to work ?
> 
> 2.  How to VCL and VPP communication ? 
> 
> 3. Why the message of VPP to VCL  is "send_session_connected_callback" 
> function send ?
> 
> thanks,
> xyxue
>  
> From: Dave Wallace 
> Date: 2017-09-19 01:29
> To: 薛欣颖 ; vpp-dev@lists.fd.io 
> 
> Subject: Re: [vpp-dev] Failed to use vcl_test_client
> Hi Xyeue,
> 
> I believe this patch fixes this issue:  https://gerrit.fd.io/r/#/c/8315/ 
> 
> 
> Can you please pull the latest source code and try again?
> 
> Thanks,
> -daw-
> 
> On 9/18/2017 2:43 AM, 薛欣颖 wrote:
>> 
>> Hi,
>> 
>> When I test vcl ,there is some error :
>> root@ubuntu:/home/vpp_communication/vpp/build-root/install-vpp-native/vpp/bin#
>>  ./vcl_test_client -U 1.1.1.2 22000
>> 
>> CLIENT: Connecting to server...
>> msg_handler_internal:429: no handler for msg id 424
>> ..
>> ...
>> ...
>> ERROR in main(): 

Re: [vpp-dev] some issue about using unformat %u

[Florin Coras]

Hi Hui, 

Yup, that’s a ‘known’ unformat trap. When unformatting integers, use u32. 

Florin

> On Sep 19, 2017, at 8:33 PM,   
> wrote:
> 
> hi all:
> 
> we found some common using issues about the use of CLI unformat, as follow:
> 
> 
> 
> u16 out_port = 0;
> 
> u32 vrf_id = 0, protocol;
> 
> else if (unformat (line_input, "%U %u", unformat_ip4_address,
> 
>_addr, _port))
> 
> 
> 
> when inputing u16 or u8 type param(not u32)， the  local variable which behind 
> of "out_port" in stack will be overwrited, is that right? is there some Notes 
> about this?
> 
> I think the bellow code maybe  cause that issue.
> 
> unformat->va_unformat->do_percent->unformat_integer-> *(u32 *) v = value;
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 王辉 wanghui
> 
> 
> 
> IT开发工程师 IT Development Engineer
> 虚拟化南京四部/无线研究院/无线产品经营部 NIV Nanjing Dept. IV/Wireless Product R＆D 
> Institute/Wireless Product Operation Division
> 
> 
> 
> 
> ___
> 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] Failed to use vcl_test_client

[Florin Coras]

Hi xyxue, 

I just tested the stack with linux and everything seems to be working fine. I 
tested the stack with linux using uri_tcp_test and nc and the cut-through path 
with the vcl test tools. How are you running the server?

Florin

> On Sep 19, 2017, at 8:29 PM, 薛欣颖 <xy...@fiberhome.com> wrote:
> 
> Hi Florin,
> 
> The server is started on the peer vpp . And through  
> 'sock_test_client/sock_test_server' can be normal communication.
> 
> Thanks,
> xyxue
>  
> From: Florin Coras <mailto:fcoras.li...@gmail.com>
> Date: 2017-09-20 10:52
> To: 薛欣颖 <mailto:xy...@fiberhome.com>
> CC: dwallacelf <mailto:dwallac...@gmail.com>; vpp-dev 
> <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] Failed to use vcl_test_client
> Hi xyxue,
> 
> What you’re getting is a connect fail because, I assume from trace, the 
> server is not started on the peer vpp. Because the server is not started, 
> i.e., bind wasn’t called, when the peer vpp receives the syn it replies with 
> a reset. That reset finally results in a connect fail notify. 
> 
> As for your other questions:
> 
> 1. Obviously, the one in vpp is for handling connect requests from 
> applications while the one in vppcom is for cut-through session. That is, vpp 
> acts as introduction mechanism for the two apps which afterwards exchange 
> data via shared memory fifos. 
> 2. For exchanging control messages, e.g., bind, connect, accept, they use the 
> binary api. For exchanging data, that is, moving data from vpp to vcl and 
> vice-versa, they use shared memory fifos. 
> 3. That message is a notification from vpp to the application (vcl in this 
> case) regarding a previous connect attempt. As you’ve discovered, if 
> is_fail=1, the connect attempt failed. 
> 
> Hope this helps, 
> Florin
> 
>> On Sep 19, 2017, at 7:30 PM, 薛欣颖 <xy...@fiberhome.com 
>> <mailto:xy...@fiberhome.com>> wrote:
>> 
>> 
>> Hi ,
>> 
>> There are still problems:
>> root@ubuntu:/home/vpp_communication/vpp/build-root/install-vpp-native/vpp/bin#
>>  ./vcl_test_client -U 1.1.1.2 22000
>> 
>> CLIENT: Connecting to server...
>> vl_api_connect_session_reply_t_handler:697: [9478] connect failed: Session 
>> failed to connect (-115)
>> 
>> Breakpoint 1, send_session_connected_callback (app_index=1, api_context=0, 
>> s=0x0, is_fail=1 '\001')
>> at 
>> /home/vpp_communication/vpp/build-data/../src/vnet/session/session_api.c:157
>> 157 {
>> (gdb) bt
>> #0  send_session_connected_callback (app_index=1, api_context=0, s=0x0, 
>> is_fail=1 '\001')
>> at 
>> /home/vpp_communication/vpp/build-data/../src/vnet/session/session_api.c:157
>> #1  0x7f35c658459c in stream_session_connect_notify (tc=0x7f358585e3f8, 
>> is_fail=, 
>> is_fail@entry=1 '\001') at 
>> /home/vpp_communication/vpp/build-data/../src/vnet/session/session.c:489
>> #2  0x7f35c6456972 in tcp_connection_reset (tc=tc@entry=0x7f358585e3f8)
>> at /home/vpp_communication/vpp/build-data/../src/vnet/tcp/tcp.c:258
>> #3  0x7f35c6429977 in tcp46_syn_sent_inline (is_ip4=1, 
>> from_frame=, node=, 
>> vm=) at 
>> /home/vpp_communication/vpp/build-data/../src/vnet/tcp/tcp_input.c:2023
>> #4  tcp4_syn_sent (vm=, node=, 
>> from_frame=)
>> at 
>> /home/vpp_communication/vpp/build-data/../src/vnet/tcp/tcp_input.c:2184
>> #5  0x7f35c6962d14 in dispatch_node (last_time_stamp=204974335045786, 
>> frame=0x7f35858596c0, 
>> dispatch_state=VLIB_NODE_STATE_POLLING, type=VLIB_NODE_TYPE_INTERNAL, 
>> node=0x7f3584da06c0, 
>> 
>> 
>> code segment：
>> int
>> send_session_connected_callback (u32 app_index, u32 api_context,
>>   stream_session_t * s, u8 is_fail)
>> {
>>   vl_api_connect_session_reply_t *mp;
>>   unix_shared_memory_queue_t *q;
>>   application_t *app;
>>   unix_shared_memory_queue_t *vpp_queue;
>> 
>>   app = application_get (app_index);
>>   q = vl_api_client_index_to_input_queue (app->api_client_index);
>> 
>>   if (!q)
>> return -1;
>> 
>>   mp = vl_msg_api_alloc (sizeof (*mp));
>>   mp->_vl_msg_id = clib_host_to_net_u16 (VL_API_CONNECT_SESSION_REPLY); 
>>   mp->context = api_context;
>>   if (!is_fail)
>> {
>>   vpp_queue = session_manager_get_vpp_event_queue (s->thread_index);
>>   mp->server_rx_fifo = pointer_to_uword (s->server_rx_fifo);
>>   mp->server_tx_fifo = pointer_to_uword (s->server_tx_fifo);
>>   mp->handle = stream_session_handle (s);
&

Re: [vpp-dev] FD.io Enabling Jenkins openSUSE : 2017-09-13 @ 0830 UTC (1:30pm PDT)

[Florin Coras]

Vanessa, 

Today is API freeze, could you postpone until tomorrow?

Florin

> On Sep 13, 2017, at 12:55 PM, Vanessa Valderrama 
>  wrote:
> 
> 
> 
> 
> 
> What:
> 
> LF is enabling openSUSE minions for VPP jobs in Jenkins
> When:
> 
> 2017-09-13 @ 0830 UTC (1:30pm PDT)
> 
> Where: 
> 
> Please contact valderrv via IRC fdio-meeting if you experiene any issue 
> related to this change
> 
> 
> Impact:
> 
> No restart is required for this change.  Once the change is made VPP jobs 
> will build on openSUSE minions.
> ___
> 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] Jenkins ubuntu 1604 failures

[Florin Coras]

Hi Vanessa, 

We’re seeing lots of vpp-verify-master-ubuntu1604 failures that seem to be 
timeouts related. Could they be related to the recent switch to the new 
instances?

Thanks, 
Florin

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] vppctl / cli improvements

[Florin Coras]

Much appreciated, Chris!

Florin

> On Sep 21, 2017, at 11:27 AM, Luke, Chris  wrote:
> 
> FYI all, https://gerrit.fd.io/r/8491  fixes 
> several vppctl and cli issues and generally makes them work together better.
>  
> Of most note to people is it (finally) fixes the noise vppctl was producing 
> when used non-interactively. Ie, the command echo, welcome banner and CLI 
> prompt are no more when you use it in a script or pass commands on the 
> command line. This is achieved by having vppctl use a magic terminal type 
> (“vppctl”) to inform VPP to not dress the session up as an interactive one.
>  
> In working this I uncovered several long-standing issues, not least if the 
> CLI socket dies before VPP has spoken to it, VPP didn’t notice and ended up 
> triggering a fatal SIGPIPE. Lovely! The commit message has extensive notes 
> for the morbidly interested.
>  
> Anyway, once merged, keep a watch for any CLI issues I may have introduced; 
> let me know if you come across anything odd or fatal.
>  
> Chris.
> ___
> 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] Coverity runs

[Florin Coras]

+1

Thanks, Chris!

Florin

> On Sep 19, 2017, at 9:03 AM, Dave Barach (dbarach)  wrote:
> 
> Very cool! Thanks for working on it...  <>Dave
>  
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Luke, Chris
> Sent: Tuesday, September 19, 2017 11:50 AM
> To: vpp-dev 
> Subject: [vpp-dev] Coverity runs
>  
> All,
>  
> Coverity have increased the limits for our project size again; effective 
> yesterday I run the build twice daily. 0600 and 1500 Eastern is what I have 
> in cron currently, which I hope will be useful times for the majority of the 
> current contributors to get feedback on their patches once merged. Thoughts 
> on the timing welcome.
>  
> Chris.
> ___
> 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] Multiple VRFs in 1609

[Florin Coras]

Michael, 

I would recommend you switched to a newer release (17.07 or the soon to be 
release 17.10) since the fib code has been completely reworked in 17.01. 

Florin

> On Oct 4, 2017, at 7:13 PM, Michael Borokhovich  wrote:
> 
> Hi,
> 
> I'm trying to configure the following setup.
> 
> GigabitEthernet0/4/0 - Table 1
> GigabitEthernet0/5/0 - Table 2
> GigabitEthernet0/6/0 - Table 0 (default)
> 
> If a packet with DST_IP="10.5.1.0/24 " received at 
> GigabitEthernet0/4/0 or GigabitEthernet0/5/0 it needs to be sent via 
> GigabitEthernet0/6/0.
> 
> The following works for VPP 1710:
> vppctl ip route add 10.5.1.0/24  table 1 via 10.5.4.11 
> GigabitEthernet0/6/0
> 
> 
> vppctl ip route add 10.5.1.0/24  table 2 via 10.5.4.11 
> GigabitEthernet0/6/0
> 
> But for 1609 it does not work. The routes are added to the default table 0 
> instead of tables 1 and 2.
> 
> If I do just this (just interface name, without the next ho IP): 
> 
> vppctl ip route add 10.5.1.0/24  table 1 via 
> GigabitEthernet0/6/0
> 
> Then the route is installed correctly to table 1 but the outgoing packets are 
> messed up - sent without ethernet header.
> 
> 
> 
> Any ideas how to make multiple VRFs woks in 1609?
> 
> 
> 
> Thanks,
> 
> Michael.
> 
> 
> 
> ___
> 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] Growing build queue

[Florin Coras]

Queue is back down to 1. 

Thanks a lot Vanessa!

Florin

> On Oct 2, 2017, at 11:59 AM, Vanessa Valderrama 
> <vvalderr...@linuxfoundation.org> wrote:
> 
> Florin,
> 
> I'm looking into the issue now.
> 
> Thank you,
> Vanessa
> 
> On 10/02/2017 11:49 AM, Florin Coras wrote:
>> Hi Vanessa, 
>> 
>> It would seem we’re running out of executors and the build queue keeps on 
>> growing. Could you take a look at it?
>> 
>> Thanks,
>> Florin
> 

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Fixes not being cherry picked to stable/1710

[Florin Coras]

Folks, 

I see a number of patches on master that look like fixes, have the word “fix” 
in subject line, but no jira ticket assigned and have not been cherry-picked to 
stable/1710. Could patch owners, once their patches have been merged, take care 
of these last two steps *if needed* and thereby avoid possible future pain to 
be created by me haphazardly porting their fixes? Also, in closing, let me 
remind you all the wise teachings of our creed:

• 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
• Manual merges may be required, depending on the degree of 
divergence between throttle and master
• All bug fixes need to have a Jira ticket
• Please put Jira IDs into the commit messages.
• Please use the same Jira ID

Regards, 
Florin
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Running multiple instances of VPP as it was allowed with VPP-lite

[Florin Coras]

Hi Justin, 

Try api-segment {prefix }

Florin

> On Oct 4, 2017, at 9:23 AM, Justin Iurman  wrote:
> 
> Hi all,
> 
> Is it still possible to run multiple instances of VPP, just like it was done 
> with VPP-lite (see here: 
> https://wiki.fd.io/view/VPP/Progressive_VPP_Tutorial) before merging it ?
> 
> Actually, my problem is the following. I need to run several instances of VPP 
> (eg. vpp1, vpp2, vpp3, etc) to simulate a topology. But, for some reason, I'm 
> not able to make it work as expected. I've already disabled DPDK plugin to 
> run in "lite" mode. Could it be a configuration issue ? VPP startup.conf:
> 
> unix {
>  nodaemon
>  log /tmp/vpp.log
>  full-coredump
>  cli-listen /run/vpp/cli.sock
>  gid vpp
> }
> 
> api-trace {
>  on
> }
> 
> api-segment {
>  gid vpp
> }
> 
> plugins {
>  plugin dpdk_plugin.so { disable }
> }
> 
> I tried to compare both VPP and VPP-lite. A first observation showed that VPP 
> is installed as a service, which is not the case for VPP-lite. I've also 
> compared both config files. Here is VPP-lite startup.conf:
> 
> unix {
>  nodaemon
>  log /tmp/vpp.log
>  full-coredump
> }
> 
> api-trace {
>  on
> }
> 
> api-segment {
>  gid vpp
> }
> 
> Currently, here is how I try to mimic VPP-lite behavior with VPP:
> 
> sudo vpp api-segment { prefix vpp1 } unix { cli-listen /run/vpp/cli.vpp1.sock 
> }
> sudo vppctl -s /run/vpp/cli.vpp1.sock
> 
> It works for one instance, but not for more, even if it does not throw any 
> error. Do you have any idea on how to proceed or what is wrong here ?
> 
> Thanks !
> 
> Justin
> ___
> 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] Process for submitting patches to stable/1710

[Florin Coras]

Hi Tom, 

As long as the patches have a jira ticket, procedurally all is fine with me. 
However, since we’re so close to release, I’d like Damjan, since he’s the build 
infra manager, to vet the changes. 

Regards, 
Florin

> On Oct 10, 2017, at 12:24 PM, Thomas F Herbert  wrote:
> 
> Dave, Florin,
> I have two patches in gerrit for stable/1710, both with JIRAs.
> 
> Is there a chance that these can make it into 1710-rc2? They both fix 
> problems that break rpm builds but add no additional features.
> 
> I want to confirm I am following the correct procedure. One was originally 
> submitted to master and rebased to stable/1710 and the other one was 
> submitted directly to stable/1710.
> 
> https://gerrit.fd.io/r/8721 
> https://gerrit.fd.io/r/8720 
> https://jira.fd.io/browse/VPP-1015 
> https://jira.fd.io/browse/VPP-1014 
> --Tom
> 
> -- 
> Thomas F Herbert 
> NFV and Fast Data Planes 
> Office of Technology 
> Red Hat
> ___
> 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] Problem with new c api patch commit 8f2a4ea merged on September 19

[Florin Coras]

Hi Klement, 

It’s okay :-)

Just open a ticket, cherry-pick the patch and append the jira ticket id to the 
subject. That should be enough. 

Cheers, 
Florin

> On Oct 5, 2017, at 8:11 AM, Klement Sekera -X (ksekera - PANTHEON 
> TECHNOLOGIES at Cisco)  wrote:
> 
> Oh shoot, I never really learned the process..
> Looking at the other email, I've already screwed this up on multiple
> levels as I did not file a JIRA and committed to master instead of
> release throttle.
> How do we proceed in these cases?
> 
> Quoting Billy McFall (2017-10-05 17:08:50)
>>   Klement,
>>   Thank you for the path "drop python3 dependency" on master
>>   ([1]https://gerrit.fd.io/r/#/c/8584/), it will make ours lives downstream
>>   much easier. I don't see the patch on stable/1710. Is there a plan to
>>   cherry pick to 1710? (Sorry if it already there, just didn't see it.)
>>   Thanks,
>>   Billy McFall
>>   On Mon, Sep 25, 2017 at 8:03 AM, Klement Sekera -X (ksekera - PANTHEON
>>   TECHNOLOGIES at Cisco) <[2]ksek...@cisco.com> wrote:
>> 
>> Quoting Thomas F Herbert (2017-09-25 13:31:55)
>>> On 09/25/2017 05:02 AM, Marco Varlese wrote:
>>> 
>>>   Thanks for the thorough explanation Klement!Based on that, I think
>> (2) is still the better option for the current situation...
>>> 
>>>   Tom, how would that sound to you?
>>> 
>>> 
>>>   "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)"
>> [1]<[3]ksek...@cisco.com> 09/25/17 10:40 AM >>>
>>> 
>>>   Quoting Marco Varlese (2017-09-25 10:26:50)
>>> 
>>>   Hi Klement,
>>> 
>>> 
>>>   "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)"
>> [2]<[4]ksek...@cisco.com> 09/25/17 9:33 AM >>>
>>> 
>>>   At the time of creating this patch, epel was part of Makefile and
>>>   python34 was installed as dependency from that repo.
>>>   (see [3][5]https://gerrit.fd.io/r/#/c/6983/53/Makefile)
>>>   At later time, the epel stuff disappeared and with it also
>>>   the possibility to add python34 as a centos dependency - commit
>>>   bd8e242024fcc2daffa77bdd6e2da1296ace5c69. I remember pointing this
>> out
>>>   in discussion with Neale, but I didn't get a chance to test whether
>>>   centos works or not before it was merged.
>>> 
>>> That's OK. You would have had to test with a system without EPEL
>> Repo
>>> enabled to discover this problem.
>>> 
>>> I should have paid closer attention when this patch was first
>> discussed in
>>> May. Please add me as a reviewer for patches that have implications
>> for
>>> RPM packaging and requirements.
>>> 
>>> 
>>>   I think it would be nice though to update other scripts too so to
>> have one single python version used across the board.
>>>   Currently, to build VPP on our distribution I need to require both
>> python and python3 packages since some python scripts use one rather
>> than the other.
>>>   Aligning python versions would make downstream consumption better I
>> believe.
>>>   Is this something which will/could be done?
>>> 
>>>   See below.
>>> 
>>> 
>>> 
>>>   As for the solution, I can think of 3 options:
>>> 
>>>   1.) require python3 (which has been around for some ~9 years now)
>>>   2.) disable generation of the C (and C++) API if python3 is not
>> detected
>>> 
>>>   I think this would be a fair compromise for distros not supporting
>> (yet) python3. However, I am not sure how this would result in the VPP
>> CI... wouldn't this break all tests running over those API?
>>> 
>>>   Tests are python2.7 because scapy wasn't python3 capable when we
>>>   designed the test framework.
>>> 
>>>   These are language bindings, not different API calls. Only test_vapi,
>>>   which tests that the language bindings of different types (simple
>>>   request, dump, event, etc.) work would have to be disabled.
>>> 
>>> I think this is a good interim work-around until the distros have
>> Python3.
>>> I can submit another patch to allow this the inclusion would be
>> enabled as
>>> a default but could be disabled only in downstream builds in RHEL
>> and
>>> Centos 7.
>>> 
>>> When will we have tests in CSIT that use the C/C++ APIs in 17.10?
>>> 
>>> Neale, are we planning to cherry-pick this patch into 17.10?
>>> 
>>> Do we have yet tests in CSIT that use the C/C++ APIs in 17.10?
>> 
>> Let me rephrase my words to clarify possible confusion which I see. New
>> C/C++ API bindings are just a way of calling old VPP APIs in a more
>> user-friendly way. They still call e.g. sw_interface_dump - there is no
>> change to APIs themselves.
>> 
>> So it's important to distinguish between API (e.g. sw_interface_dump)
>> and API binding (which is a language-specific way of constructing
>> sw_interface_dump message and sending it over shared memory to VPP).
>> 
>> I don't know about CSIT, but "make test" tests use python API bindings,
>> which internally uses old C API bindings 

Re: [vpp-dev] Running multiple instances of VPP as it was allowed with VPP-lite

[Florin Coras]

Justin, 

That looks about right. The other option would be to use telnet. So instead of 
“cli-listen /run/vpp/cli.vpp1.sock” do something like “cli-listen 
localhost:5002” and then telnet 0 5002

Florin

> On Oct 5, 2017, at 1:18 AM, Justin Iurman <justin.iur...@ulg.ac.be> wrote:
> 
> Hi Florin,
> 
> In fact, that's what I was already trying. Anyway, I found a way to make it 
> work but I'm still not sure that's the right/best way to do so.
> 
> # vpp1 instance
> sudo vpp unix { log /tmp/vpp1.log full-coredump cli-listen 
> /run/vpp/cli.vpp1.sock } api-segment { prefix vpp1 } api-trace { on } plugins 
> { plugin dpdk_plugin.so { disable } }
> 
> # vpp2 instance
> sudo vpp unix { log /tmp/vpp2.log full-coredump cli-listen 
> /run/vpp/cli.vpp2.sock } api-segment { prefix vpp2 } api-trace { on } plugins 
> { plugin dpdk_plugin.so { disable } }
> 
> # vppctl vpp1
> sudo vppctl -s /run/vpp/cli.vpp1.sock 
> 
> # vppctl vpp2
> sudo vppctl -s /run/vpp/cli.vpp2.sock 
> 
> Since I build a dynamic topology, I won't use startup config files. That's 
> why i'm using parameters in command line. Commands above work good, as it 
> mimics the behavior I had with VPP-lite. But again, is it the right/best way 
> to do so ? Or would there be anything better suited ?
> 
> Justin
> 
> - Mail original -
> De: "Florin Coras" <fcoras.li...@gmail.com>
> À: "Justin Iurman" <justin.iur...@ulg.ac.be>
> Cc: vpp-dev@lists.fd.io
> Envoyé: Mercredi 4 Octobre 2017 18:32:27
> Objet: Re: [vpp-dev] Running multiple instances of VPP as it was allowed with 
> VPP-lite
> 
> Hi Justin, 
> 
> Try api-segment {prefix }
> 
> Florin
> 
>> On Oct 4, 2017, at 9:23 AM, Justin Iurman <justin.iur...@ulg.ac.be> wrote:
>> 
>> Hi all,
>> 
>> Is it still possible to run multiple instances of VPP, just like it was done 
>> with VPP-lite (see here: 
>> https://wiki.fd.io/view/VPP/Progressive_VPP_Tutorial) before merging it ?
>> 
>> Actually, my problem is the following. I need to run several instances of 
>> VPP (eg. vpp1, vpp2, vpp3, etc) to simulate a topology. But, for some 
>> reason, I'm not able to make it work as expected. I've already disabled DPDK 
>> plugin to run in "lite" mode. Could it be a configuration issue ? VPP 
>> startup.conf:
>> 
>> unix {
>> nodaemon
>> log /tmp/vpp.log
>> full-coredump
>> cli-listen /run/vpp/cli.sock
>> gid vpp
>> }
>> 
>> api-trace {
>> on
>> }
>> 
>> api-segment {
>> gid vpp
>> }
>> 
>> plugins {
>> plugin dpdk_plugin.so { disable }
>> }
>> 
>> I tried to compare both VPP and VPP-lite. A first observation showed that 
>> VPP is installed as a service, which is not the case for VPP-lite. I've also 
>> compared both config files. Here is VPP-lite startup.conf:
>> 
>> unix {
>> nodaemon
>> log /tmp/vpp.log
>> full-coredump
>> }
>> 
>> api-trace {
>> on
>> }
>> 
>> api-segment {
>> gid vpp
>> }
>> 
>> Currently, here is how I try to mimic VPP-lite behavior with VPP:
>> 
>> sudo vpp api-segment { prefix vpp1 } unix { cli-listen 
>> /run/vpp/cli.vpp1.sock }
>> sudo vppctl -s /run/vpp/cli.vpp1.sock
>> 
>> It works for one instance, but not for more, even if it does not throw any 
>> error. Do you have any idea on how to proceed or what is wrong here ?
>> 
>> Thanks !
>> 
>> Justin
>> ___
>> 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] syslog in snat

[Florin Coras]

Indeed!

Florin

> On Oct 13, 2017, at 3:31 PM, Luke, Chris  wrote:
> 
> The release stable branch was forked several weeks ago; at this point it the 
> release only accepts bug fixes.
>  
> Chris.
>  
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Matt Paska
> Sent: Friday, October 13, 2017 17:11
> To: Matus Fabian -X (matfabia - PANTHEON TECHNOLOGIES at Cisco) 
> 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] syslog in snat
>  
> Thanks for the info. Is there not enough interest to warrant being included?
>  
> On Thu, Oct 12, 2017 at 9:26 PM, Matus Fabian -X (matfabia - PANTHEON 
> TECHNOLOGIES at Cisco) > wrote:
> Syslog in NAT plugin is not a part of 17.10 release.
>  
> Matus
>  
>  
> From: vpp-dev-boun...@lists.fd.io  
> [mailto:vpp-dev-boun...@lists.fd.io ] On 
> Behalf Of Matt Paska
> Sent: Friday, October 13, 2017 2:48 AM
> To: Ole Troan >
> Cc: vpp-dev@lists.fd.io 
> 
> Subject: Re: [vpp-dev] syslog in snat
>  
> Hi all, 
>  
> Is Syslog in SNAT planned for the upcoming 17.10 release?
>  
> Thanks!
>  
> On Thu, Jun 22, 2017 at 6:48 PM, Matt Paska  > wrote:
> We just don't have ipfix collectors setup right now. We have a system for 
> syslog and I was hoping to integrate vpp snat into that as well. 
>  
> Thanks for the quick response.
>  
> On Thu, Jun 22, 2017 at 2:50 PM, Ole Troan  > wrote:
> Tell me more. 
>  
> Ole
> 
> On 22 Jun 2017, at 23:37, Matt Paska  > wrote:
> 
> Yes, we do need it. What's the current plan?
>  
> On Thu, Jun 22, 2017 at 1:05 PM, Ole Troan  > wrote:
> Matt,
>  
> It will not have it for 17.07. 
> We have ipfix support now as well as deterministic. 
>  
> Do you need it?
>  
> Cheers 
> Ole
> 
> On 22 Jun 2017, at 21:33, Matt Paska  > wrote:
> 
> Hi,
>  
> Is Snat syslog based logging support still planned for 17.07? I see it 
> mentioned on the release plan 
> wiki(https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_17.07 
> ) but 
> not on the snat work list(https://wiki.fd.io/view/VPP/SNAT 
> ).
>  
> Thanks
>  
> On Tue, May 23, 2017 at 10:45 PM, Matus Fabian -X (matfabia - PANTHEON 
> TECHNOLOGIES at Cisco) > wrote:
> Hi,
>  
> Snat plugin doesn’t support syslog logging, currently support only IPFIX.
>  
> Regards,
> Matus
>  
> From: vpp-dev-boun...@lists.fd.io  
> [mailto:vpp-dev-boun...@lists.fd.io ] On 
> Behalf Of Matt Paska
> Sent: Tuesday, May 23, 2017 8:23 PM
> To: vpp-dev@lists.fd.io ; Jim Thompson 
> >
> Cc: Andrew Taylor  >
> Subject: Re: [vpp-dev] syslog in snat
>  
> Is there further info/docs on using syslog for snat on the wiki? I searched 
> through but couldn't find anything. 
>  
> Thanks.
>  
> On Sat, May 13, 2017 at 10:32 PM, Jim Thompson  > wrote:
>  
> On May 13, 2017, at 11:58 PM, Andrew Taylor  > wrote:
>  
> Hi, 
> 
> Could you please explain what is "Syslog based SNAT login" in Release Plan 
> 17.07
>  
> Added here, so you could ask 
> https://wiki.fd.io/index.php?title=Projects%2Fvpp%2FRelease_Plans%2FRelease_Plan_17.07
>  
> iff=5072=5071
>  
> 
>  
>  
> 
> Is it an alternative option for logging session like IPFIX ?
>  
> I suspect this was intended to be “syslog-based SNAT logging”, and that only 
> the final ‘g’ is missing.
>  
>  
> 
> ___
> 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

[vpp-dev] VPP API Freeze September 13

[Florin Coras]

All, 

On September 13th end of day PST we enter VPP API freeze for the upcoming 17.10 
release. Subsequently, we will not be accepting binary API patches nor 
high-risk changes on the main branch. 

API freeze will last until September 27th when 17.10 stable branch will be 
created and master will return to normal operation. For more details, please 
refer to the release plan [1]. 

Regards, 
Florin

[1] https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_17.10 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [tsc] FD.io Jenkins Maintenance: 2017-09-07 @ 0415 UTC (9:15am PDT)

[Florin Coras]

Thanks, Vanessa!

Florin

> On Sep 11, 2017, at 7:53 AM, Vanessa Valderrama 
>  wrote:
> 
> Switching VPP jobs to new instances.  This change should stabilize build 
> times.
> 
> Thank you,
> Vanessa
> 
> On 09/08/2017 01:51 PM, Vanessa Valderrama wrote:
>> While the build timeouts issue appears to be resolved, there does seem to be 
>> an increase in build times for various VPP jobs.  We are aware of and 
>> looking into this issue.
>> 
>> Thank you,
>> Vanessa
>> 
>> 
>> On 09/07/2017 11:27 AM, Vanessa Valderrama wrote:
>>> Change is complete.  The new nodes appear to be spinning up successfully.  
>>> We'll be monitoring jobs throughout the day.  Please report issues via IRC 
>>> fdio-infra.
>>> 
>>> Thank you,
>>> Vanessa
>>> 
>>> On 09/07/2017 11:18 AM, Vanessa Valderrama wrote:
 Starting change now.
 
 On 09/07/2017 10:51 AM, Vanessa Valderrama wrote:
> 
> 
> 
> What:
> 
> LF is switching VPP jobs to use new Jenkins nodes with dedicated core 
> instances
> When:
> 
> 2017-09-07 @ 0415 UTC (9:15am PDT)
> 
> 
> Impact:
> 
> No restart is required for this change.  Once the change is made new 
> instances will spin up on the new nodes.
> 
> Why:
> Various FD.io projects have been intermittently experiencing build time 
> out issues.  Dedicated core instances should alleviate these issues by 
> reducing CPU over subscription.
> 
> 
 
>>> 
>> 
> 
> ___
> tsc mailing list
> t...@lists.fd.io
> https://lists.fd.io/mailman/listinfo/tsc

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] More build timeouts for vpp-verify-master-ubuntu1604

[Florin Coras]

Hi, 

Any news regarding this? We are 1 week away from API freeze and the infra makes 
it almost impossible to merge patches! 

Thanks, 
Florin

> On Sep 4, 2017, at 9:44 PM, Dave Wallace  wrote:
> 
> Dear helpd...@fd.io ,
> 
> There has been another string of build timeouts for 
> vpp-verify-master-ubuntu1604:
> https://jenkins.fd.io/job/vpp-verify-master-ubuntu1604/buildTimeTrend 
> 
> Please change the timeout for build failures from 360 minutes to 120 minutes 
> in addition to addressing the slow minion issue.
> 
> 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

Re: [vpp-dev] vpp performance numbers with 10Gbps interface.

[Florin Coras]

Hi Rahul, 

It looks like all your packets are going to ip4-imcp-error, ip4-local and 
ip4-udp-lookup. What is your test setup?

Florin
 
> On Sep 12, 2017, at 5:10 AM, Rahul Negi  wrote:
> 
> Hi All,
> I was trying to measure maximum PPS handled by vpp.I have installed ubuntu 
> 16.04 on my server.I have followed vpp recommended bios settings.
> 
> Hardware specs:
> root@kujo:~# lscpu
> Architecture:  x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Little Endian
> CPU(s):8
> On-line CPU(s) list:   0-7
> Thread(s) per core:1
> Core(s) per socket:8
> Socket(s): 1
> NUMA node(s):  1
> Vendor ID: GenuineIntel
> CPU family:6
> Model: 45
> Model name:Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz
> Stepping:  7
> CPU MHz:   1200.000
> CPU max MHz:   2900.
> CPU min MHz:   1200.
> BogoMIPS:  5786.39
> Virtualization:VT-x
> L1d cache: 32K
> L1i cache: 32K
> L2 cache:  256K
> L3 cache:  20480K
> NUMA node0 CPU(s): 0-7
> Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
> pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
> nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx 
> est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt 
> tsc_deadline_timer aes xsave avx lahf_lm epb tpr_shadow vnmi flexpriority ept 
> vpid xsaveopt dtherm  
> 
> 
> Vpp version:
> 
> vpp# show version
> vpp v17.10-rc0~301-gb2d2fc7 built by root on kujo at Mon Sep 11 16:39:34 IST 
> 2017
> 
> My vpp model has 1 main thread and 1 worker thread.I was not able to get more 
> than 6Mpps .After 6 Mpps i can see the rx_miss counters in vpp stats.
> 
> vpp# show interface
> 
>   Name   Idx   State  Counter  
> Count
> 
> TenGigabitEtherneta/0/0   1down  rx-error 
>   2
> 
> TenGigabitEtherneta/0/1   2 up   rx packets  
> 52647168
> 
>  rx bytes  
> 3369416188
> 
>  tx packets  
> 52638150
> 
>  tx bytes  
> 4842700014
> 
>  drops
>9024
> 
>  ip4 
> 52645519
> 
>  tx-error 
>   1
> 
> local00down 
> 
> vpp# show interface
> 
>   Name   Idx   State  Counter  
> Count
> 
> TenGigabitEtherneta/0/0   1down  rx-error 
>   2
> 
> TenGigabitEtherneta/0/1   2 up   rx packets  
> 54696192
> 
>  rx bytes  
> 3500553704
> 
>  tx packets  
> 54687170
> 
>  tx bytes  
> 5031209822
> 
>  drops
>9028
> 
>  ip4 
> 54694538
> 
>  tx-error 
>   1
> 
> local00down 
> 
> vpp# show interface
> 
>   Name   Idx   State  Counter  
> Count
> 
> TenGigabitEtherneta/0/0   1down  rx-error 
>   2
> 
> TenGigabitEtherneta/0/1   2 up   rx packets  
> 56743168
> 
>  rx bytes  
> 3631560168
> 
>  tx packets  
> 56734146
> 
>  tx bytes  
> 5219531614
> 
>  drops
>9028
> 
>  ip4 
> 56741514
> 
>  rx-miss 
> 23152160
> 
>  tx-error 
>   1
> 
> local00down 
> 
> vpp# show interface
> 
>   Name   Idx   State  Counter  
> Count
> 
> TenGigabitEtherneta/0/0   

Re: [vpp-dev] Failed to use vcl_test_client

[Florin Coras]

Hi xyxue, 

I think the issue may be the way you build your topology. You may actually want 
to use 2 veth pairs, one per vpp instance. So something along the lines of:

Linux:
ip netns add vppns
ip link add veth_vpp1 type veth peer name vpp1
ip link set dev vpp1 up
ip link set dev veth_vpp1 up netns vppns
ip link add veth_vpp2 type veth peer name vpp2
ip link set dev vpp2 up
ip link set dev veth_vpp2 up netns vppns

vpp1:
create host-interface name vpp1
…

vpp2:
create host-interface name vpp2
...

Hope this helps, 
Florin

> On Sep 28, 2017, at 5:11 AM, 薛欣颖 <xy...@fiberhome.com> wrote:
> 
> 
> Hi,
>> 
>> I have added  '#define __NR_memfd_create 319' to 
>> /usr/include/x86_64-linux-gnu/asm/unistd_64.h.
> The following error still occurred during the test:
> root@ubuntu:/home/vpp_communication/vpp/build-root/install-vpp-native/vpp/bin#
>  ./vcl_test_client -U 1.1.1.2 22000
> 
> CLIENT: Connecting to server...
> vl_api_connect_session_reply_t_handler:697: [9478] connect failed: Session 
> failed to connect (-115)
> 
> Are we missing the configuration? Or are there any problems with our testing 
> methods?
> 
> The kernel version：
> root@ubuntu:/home/vpp_communication/vppsb/vcl-ldpreload/src# uname -a
> Linux ubuntu 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 
> 2016 x86_64 x86_64 x86_64 GNU/Linux
> 
> 
> Test topology:
> <CatchAA2A(09-28-19-39-54).jpg>
> 
> 
> Server vpp configure：
> create host-interface name eth1
> set interface mac address host-eth1 00:0c:29:4c:35:65 
> set interface state host-eth1 up
> set interface ip address host-eth1 1.1.1.2/24
> 
> start VCL server ：
> root@ubuntu:/home/vpp_communication/vpp/build-root/install-vpp-native/vpp/bin#
>  ./vcl_test_server 
> 
> SERVER: Waiting for a client to connect on port 22000...
> 
> vcl Client:
> create host-interface name eth1
> set interface mac address host-eth1 00:0c:29:db:3c:8f 
> set interface state host-eth1 up
> set interface ip address host-eth1 1.1.1.1/24
> 
> start VCL client：
> root@ubuntu:/home/vpp_communication/vpp/build-root/install-vpp-native/vpp/bin#
>  ./vcl_test_client -U 1.1.1.2 22000
> 
> CLIENT: Connecting to server...
> vl_api_connect_session_reply_t_handler:697: [9478] connect failed: Session 
> failed to connect (-115)
> 
> Breakpoint 1, send_session_connected_callback (app_index=1, api_context=0, 
> s=0x0, is_fail=1 '\001')
> at 
> /home/vpp_communication/vpp/build-data/../src/vnet/session/session_api.c:157
> 
> 
> 2. Run the test script 'socket_test.sh' directly.The error is shown below： 
> -(missing a software?)
> root@ubuntu:/home/vpp_communication/vpp/test/scripts# ./socket_test.sh -U nv
> Warning: This program is an suid-root program or is being run by the root 
> user.
> The full text of the error or warning message cannot be safely formatted
> in this environment. You may get a more descriptive message by running the
> program as a non-root user or by removing the suid bit on the executable.
> Warning: This program is an suid-root program or is being run by the root 
> user.
> The full text of the error or warning message cannot be safely formatted
> in this environment. You may get a more descriptive message by running the
> program as a non-root user or by removing the suid bit on the executable.
> xterm: xterm: Xt error: Can't open display: %s
> Xt error: Can't open display: %s
> xterm: xterm: DISPLAY is not set
> Warning: This program is an suid-root program or is being run by the root 
> user.
> The full text of the error or warning message cannot be safely formatted
> in this environment. You may get a more descriptive message by running the
> program as a non-root user or by removing the suid bit on the executable.
> xterm: Xt error: Can't open display: %s
> xterm: DISPLAY is not set
> DISPLAY is not set
> 
> Thanks,
> Xyxue
>  
> From: Florin Coras <mailto:fcoras.li...@gmail.com>
> Date: 2017-09-28 02:31
> To: John Lo (loj) <mailto:l...@cisco.com>
> CC: 薛欣颖 <mailto:xy...@fiberhome.com>; vpp-dev <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] Failed to use vcl_test_client
> Cool! Thanks for the info, John!
> 
> Xyxue, could you try it out and see if it works?
> 
> Florin
> 
>> On Sep 27, 2017, at 11:25 AM, John Lo (loj) <l...@cisco.com 
>> <mailto:l...@cisco.com>> wrote:
>> 
>> I am able to use memfd with 14.04 by updating its kernel to 3.19 (my 14.04 
>> kernel was 3.13 before the update).  
>>  
>> I also had to add the following to 
>> /usr/include/x86_64-linux-gnu/asm/unistd_64.h
>> #define __NR_memfd_create 319
>>  
>> Hope this works for you,
>&g

[vpp-dev] Growing build queue

[Florin Coras]

Hi Vanessa, 

It would seem we’re running out of executors and the build queue keeps on 
growing. Could you take a look at it?

Thanks,
Florin
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Failed to use vcl_test_client

[Florin Coras]

Hi xyxue, 

Ow, but if you’re running with vms, there’s no need to use net namespaces. If 
your vms have e1000/vmxnet3 nics you can actually run vpp with dpdk. Just 
configure the ip addresses in the two vpps and test with ping, from within one 
of the vpps, that the topology is configured correctly. 

Alternatively, yes, you can run 2 vpp instances in one vm with netns. Just 
remember to change your config files to have the vpps run with different 
api-segments like:
api-segment { prefix “” }

Cheers, 
Florin

> On Sep 28, 2017, at 6:40 PM, 薛欣颖 <xy...@fiberhome.com> wrote:
> 
> 
> Hi，
> 
> topology： VPP1 and VPP2 on two virtual machines,
>  Have you verified the VPP1 and VPP2 are connected (i.e. ping 1.1.1.2 from 
> vpp1) ? ---ping 1.1.1.2 from vpp1 is ok
> 
> <Catch(09-29-09-1(09-29-09-38-55).jpg>
> 
> The following configuration for cyberspace is on the same virtual machine:
> Linux:
> ip netns add vppns
> ip link add veth_vpp1 type veth peer name vpp1
> ip link set dev vpp1 up
> ip link set dev veth_vpp1 up netns vppns
> ip link add veth_vpp2 type veth peer name vpp2
> ip link set dev vpp2 up
> ip link set dev veth_vpp2 up netns vppns
> 
> By the way, is it ok to start two vpp in the same virtual machine?
> 
> Thanks，
> xyxue
>  
> From: Dave Wallace <mailto:dwallac...@gmail.com>
> Date: 2017-09-29 00:03
> To: 薛欣颖 <mailto:xy...@fiberhome.com>; Florin Coras 
> <mailto:fcoras.li...@gmail.com>; John Lo (loj) <mailto:l...@cisco.com>
> CC: vpp-dev <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] Failed to use vcl_test_client
> Xyxue,
> 
> Have you verified the VPP1 and VPP2 are connected (i.e. ping 1.1.1.2 from 
> vpp1) ? 
> 
> The multi-host configuration has been tested using vagrant/virtualbox using 
> .../vpp/extras/vagrant/Vagrantfile.vcl_test.  I will add a recipe to the wiki 
> in the next day or so.
> 
> The socket_test.sh script is designed to auto-configure different test 
> configurations in an X-Window environment.  It runs the client / server 
> configuration in xterm (or xfce4_terminal) and can optionally run gdb in the 
> xterm or in emacs.  
> 
> Thanks,
> -daw-
> 
> 
> On 09/28/2017 08:11 AM, 薛欣颖 wrote:
>> 
>> Hi,
>>> 
>>> I have added  '#define __NR_memfd_create 319' to 
>>> /usr/include/x86_64-linux-gnu/asm/unistd_64.h.
>> The following error still occurred during the test:
>> root@ubuntu:/home/vpp_communication/vpp/build-root/install-vpp-native/vpp/bin#
>>  ./vcl_test_client -U 1.1.1.2 22000
>> 
>> CLIENT: Connecting to server...
>> vl_api_connect_session_reply_t_handler:697: [9478] connect failed: Session 
>> failed to connect (-115)
>> 
>> Are we missing the configuration? Or are there any problems with our testing 
>> methods?
>> 
>> The kernel version：
>> root@ubuntu:/home/vpp_communication/vppsb/vcl-ldpreload/src# uname -a
>> Linux ubuntu 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 
>> 2016 x86_64 x86_64 x86_64 GNU/Linux
>> 
>> 
>> Test topology:
>> <CatchAA2A(09-28-(09-29-09-39-45).jpg>
>> 
>> 
>> Server vpp configure：
>> create host-interface name eth1
>> set interface mac address host-eth1 00:0c:29:4c:35:65 
>> set interface state host-eth1 up
>> set interface ip address host-eth1 1.1.1.2/24
>> 
>> start VCL server ：
>> root@ubuntu:/home/vpp_communication/vpp/build-root/install-vpp-native/vpp/bin#
>>  ./vcl_test_server 
>> 
>> SERVER: Waiting for a client to connect on port 22000...
>> 
>> vcl Client:
>> create host-interface name eth1
>> set interface mac address host-eth1 00:0c:29:db:3c:8f 
>> set interface state host-eth1 up
>> set interface ip address host-eth1 1.1.1.1/24
>> 
>> start VCL client：
>> root@ubuntu:/home/vpp_communication/vpp/build-root/install-vpp-native/vpp/bin#
>>  ./vcl_test_client -U 1.1.1.2 22000
>> 
>> CLIENT: Connecting to server...
>> vl_api_connect_session_reply_t_handler:697: [9478] connect failed: Session 
>> failed to connect (-115)
>> 
>> Breakpoint 1, send_session_connected_callback (app_index=1, api_context=0, 
>> s=0x0, is_fail=1 '\001')
>> at 
>> /home/vpp_communication/vpp/build-data/../src/vnet/session/session_api.c:157
>> 
>> 
>> 2. Run the test script 'socket_test.sh' directly.The error is shown below： 
>> -(missing a software?)
>> root@ubuntu:/home/vpp_communication/vpp/test/scripts# ./socket_test.sh -U nv
>> Warning: This program is an suid-root program or is being run by the root 
>> user.
>> The full text of the erro

[vpp-dev] Stable branch for 17.10 pulled

[Florin Coras]

Folks, 

The release branch, stable/1710, for VPP 17.10 has now been pulled and tags 
have been laid. As a result, master is yet again open for all changes. 

From this point onward, up until the release date on October 25th [1], we need 
to be disciplined with respect to bugfixes. Here is the traditional list of 
common-sense suggestions:

• 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
• Manual merges may be required, depending on the degree of 
divergence between throttle and master
• All bug fixes need to have a Jira ticket
• Please put Jira IDs into the commit messages.
• Please use the same Jira ID

Regards, 
Florin

[1] https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_17.10 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Packet loss on use of API & cmdline

[Florin Coras]

Hi Colin,

Your assumption was right. Most often than not, a binary API/CLI call results 
in a vlib_worker_thread_barrier_sync because most handlers and cli are not mp 
safe. As a consequence, vpp may experience packet loss.

One way around this issue, for binary APIs, is to make sure the handler you’re 
interested in is thread safe and then mark it is_mp_safe in api_main. See, for 
instance, VL_API_IP_ADD_DEL_ROUTE. 

Hope this helps, 
Florin 

> On Aug 22, 2017, at 1:11 AM, Colin Tregenza Dancer via vpp-dev 
>  wrote:
> 
> I might have just missed it, but looking through the ongoing regression tests 
> I can’t see anything that explicitly tests for packet loss during CLI/API 
> commands, so I’m wondering whether minimization of packet loss during 
> configuration is viewed as a goal for vpp?  
>  
> Many/most of the real world applications I’ve been exploring require the 
> ability to reconfigure live systems without impacting the existing flows 
> related to stable elements (route updates, tunnel add/remove, VM 
> addition/removal), and it would be great to understand how this fit with vpp 
> use cases.
>  
> Thanks again,
>  
> Colin.
>   <>
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
> Behalf Of Colin Tregenza Dancer via vpp-dev
> Sent: 19 August 2017 12:17
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Packet loss on use of API & cmdline
>  
> Hi,
>  
> I’ve been doing some prototyping and load testing of the vpp dataplane, and 
> have observed packet loss when I issue API requests or use the debug command 
> line.  Is this to be expected given the use of the worker_thread_barrier, or 
> might there be some way I could improve matters?
>  
> Currently I’m running a fairly modest 2Mpps throughput between a pair of 10G 
> ports on an Intel X520 NIC, with baremetal Ubuntu 16, & vpp 17.01.
>  
> Thanks in advance,
>  
> Colin. 
> ___
> 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] Missing include file. Again.

[Florin Coras]

Hi Jon, 

There was a pending patch for that but apparently it got abandoned. Here’s a 
fix [1] that we’ll merge as soon as it passes verify.

Sorry for the inconvenience.

Regards,
Florin

[1] https://gerrit.fd.io/r/#/c/8188/ 

> On Aug 23, 2017, at 11:21 AM, Jon Loeliger  wrote:
> 
> Folks,
> 
> I get the following compilation error with current (ie,
> 
>commit af3d9771dbf89087d3e8bed11aca0a2efa5d7bc8
>Author: Marek Gradzki 
>Date:   Fri Aug 18 08:47:48 2017 +0200
> 
> ) top-of-tree builds:
> 
> 
>CC tap_inject.c
> In file included from /usr/include/vpp/api/vpe_all_api_h.h:25:0,
> from /usr/include/vpp/api/vpe_msg_enum.h:24,
> from api_setup.c:11:
> /usr/include/vnet/vnet_all_api_h.h:61:30: fatal error:
> vnet/tcp/tcp.api.h: No such file or directory
> #include 
> 
> The install only supplies these /usr/include/vnet/tcp files:
> 
> $ ll /usr/include/vnet/tcp
> total 68K
> 0K drwxr-xr-x  2 bin bin73 Aug 23 11:19 .
> 4K drwxr-xr-x 46 bin bin  4096 Aug 23 11:19 ..
> 24K -rw-r--r--  1 bin bin 23207 Aug 23 11:16 tcp_debug.h
> 28K -rw-r--r--  1 bin bin 28574 Aug 23 11:16 tcp.h
> 8K -rw-r--r--  1 bin bin  5961 Aug 23 11:16 tcp_packet.h
> 4K -rw-r--r--  1 bin bin   922 Aug 23 11:16 tcp_timer.h
> 
> So, either the tcp.api.h should be installed, or it should not
> be referenced.  Again, I don't know which will be the correct
> and intended solution, so someone upstream from me will
> need to fix this.
> 
> Thanks,
> jdl
> ___
> 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] Failed to use vcl_test_client

[Florin Coras]

Hi xyxue, 

The issue is the stack not VCL. As of now, UDP is not fully supported. 

Florin

> On Oct 8, 2017, at 6:12 PM, 薛欣颖  wrote:
> 
> 
> Hi，
>  
> We use the TCP protocol to test VCL, the function is OK. If I modify the UDP 
> protocol, the function is abnormal.
> The error message is:
> DBGvpp# 0: udp_open_connection:254: Not implemented
> 
> The code is implemented as follows:
> int
> udp_open_connection (transport_endpoint_t * tep)
> {
>   clib_warning ("Not implemented");
>   return 0;
> }
> 
> Does the current VCL support the UDP protocol?
> 
> Thanks,
> xyxue

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VPP 17.10 RC2

[Florin Coras]

Folks, 

17.10 RC2 tag has been laid. Nonetheless, our patching process continues to 
remain the same until formal release [1], i.e., fixes first to stable/1710 and 
then cherry-pick to master. 

Regards, 
Florin

[1]  https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_17.10 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Failed to use vcl_test_client

[Florin Coras]

Hi xyxue, 

VPP now has a dependency on memfd which is not available in 14.04. 
Unfortunately, that means you’ll have to switch to ubuntu 16.04. 

Florin

> On Sep 27, 2017, at 1:34 AM, 薛欣颖 <xy...@fiberhome.com> wrote:
> 
>> Hi Florin,
>> 
> There is a compile error:not support ‘__NR_memfd_create’
> /home/vpp_communication/vpp/build-root/../src/vppinfra/linux/syscall.h:45:19: 
> error: '__NR_memfd_create' undeclared (first use in this function)
>return syscall (__NR_memfd_create, name, flags);
>
> Is the kernel version of the problem ?  What is your kernel version?
>  
> The Kernel version of mine：
> root@ubuntu:/home/vpp_communication/vppsb/vcl-ldpreload/src# uname -a
> Linux ubuntu 4.4.0-31-generic #50~14.04.1-Ubuntu SMP Wed Jul 13 01:07:32 UTC 
> 2016 x86_64 x86_64 x86_64 GNU/Linux
> 
>  If I change ‘return syscall (__NR_memfd_create, name, flags);’ to ‘return 0’.
>  Will the vcl function  be affected?
> 
> Thanks,
> xyxue
>  
> From: Florin Coras <mailto:fcoras.li...@gmail.com>
> Date: 2017-09-20 13:05
> To: 薛欣颖 <mailto:xy...@fiberhome.com>
> CC: dwallacelf <mailto:dwallac...@gmail.com>; vpp-dev 
> <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] Failed to use vcl_test_client
> Hi xyxue, 
> 
> I just tested the stack with linux and everything seems to be working fine. I 
> tested the stack with linux using uri_tcp_test and nc and the cut-through 
> path with the vcl test tools. How are you running the server?
> 
> Florin
> 
>> On Sep 19, 2017, at 8:29 PM, 薛欣颖 <xy...@fiberhome.com 
>> <mailto:xy...@fiberhome.com>> wrote:
>> 
>> Hi Florin,
>> 
>> The server is started on the peer vpp . And through  
>> 'sock_test_client/sock_test_server' can be normal communication.
>> 
>> Thanks,
>> xyxue
>>  
>> From: Florin Coras <mailto:fcoras.li...@gmail.com>
>> Date: 2017-09-20 10:52
>> To: 薛欣颖 <mailto:xy...@fiberhome.com>
>> CC: dwallacelf <mailto:dwallac...@gmail.com>; vpp-dev 
>> <mailto:vpp-dev@lists.fd.io>
>> Subject: Re: [vpp-dev] Failed to use vcl_test_client
>> Hi xyxue,
>> 
>> What you’re getting is a connect fail because, I assume from trace, the 
>> server is not started on the peer vpp. Because the server is not started, 
>> i.e., bind wasn’t called, when the peer vpp receives the syn it replies with 
>> a reset. That reset finally results in a connect fail notify. 
>> 
>> As for your other questions:
>> 
>> 1. Obviously, the one in vpp is for handling connect requests from 
>> applications while the one in vppcom is for cut-through session. That is, 
>> vpp acts as introduction mechanism for the two apps which afterwards 
>> exchange data via shared memory fifos. 
>> 2. For exchanging control messages, e.g., bind, connect, accept, they use 
>> the binary api. For exchanging data, that is, moving data from vpp to vcl 
>> and vice-versa, they use shared memory fifos. 
>> 3. That message is a notification from vpp to the application (vcl in this 
>> case) regarding a previous connect attempt. As you’ve discovered, if 
>> is_fail=1, the connect attempt failed. 
>> 
>> Hope this helps, 
>> Florin
>> 
>>> On Sep 19, 2017, at 7:30 PM, 薛欣颖 <xy...@fiberhome.com 
>>> <mailto:xy...@fiberhome.com>> wrote:
>>> 
>>> 
>>> Hi ,
>>> 
>>> There are still problems:
>>> root@ubuntu:/home/vpp_communication/vpp/build-root/install-vpp-native/vpp/bin#
>>>  ./vcl_test_client -U 1.1.1.2 22000
>>> 
>>> CLIENT: Connecting to server...
>>> vl_api_connect_session_reply_t_handler:697: [9478] connect failed: Session 
>>> failed to connect (-115)
>>> 
>>> Breakpoint 1, send_session_connected_callback (app_index=1, api_context=0, 
>>> s=0x0, is_fail=1 '\001')
>>> at 
>>> /home/vpp_communication/vpp/build-data/../src/vnet/session/session_api.c:157
>>> 157 {
>>> (gdb) bt
>>> #0  send_session_connected_callback (app_index=1, api_context=0, s=0x0, 
>>> is_fail=1 '\001')
>>> at 
>>> /home/vpp_communication/vpp/build-data/../src/vnet/session/session_api.c:157
>>> #1  0x7f35c658459c in stream_session_connect_notify (tc=0x7f358585e3f8, 
>>> is_fail=, 
>>> is_fail@entry=1 '\001') at 
>>> /home/vpp_communication/vpp/build-data/../src/vnet/session/session.c:489
>>> #2  0x7f35c6456972 in tcp_connection_reset (tc=tc@entry=0x7f358585e3f8)
>>> at /home/vpp_communication/vpp/build-data/../src/vnet/tcp/tcp.c:258
&g

Re: [vpp-dev] VPP 17.10 RC2

[Florin Coras]

Hi Tom, 

I’d appreciate it if patch owners would cherry-pick the patches. It might be 
the case that some fixes may not need to be cherry picked to master and in 
other cases, when master and stable run out of sync, the cherry-picks might 
actually require more work. 

Regards,
Florin

> On Oct 12, 2017, at 7:13 AM, Thomas F Herbert <therb...@redhat.com> wrote:
> 
> 
> 
> On 10/11/2017 06:14 PM, Florin Coras wrote:
>> Folks, 
>> 
>> 17.10 RC2 tag has been laid. Nonetheless, our patching process continues to 
>> remain the same until formal release [1], i.e., fixes first to stable/1710 
>> and then cherry-pick to master. 
> Florin, should us submitters cherry-pick our own bug-fix patches to master or 
> should we wait for you do them all?
>> 
>> Regards, 
>> Florin
>> 
>> [1]  https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_17.10 
>> <https://wiki.fd.io/view/Projects/vpp/Release_Plans/Release_Plan_17.10>
>> 
>> ___
>> vpp-dev mailing list
>> vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
>> https://lists.fd.io/mailman/listinfo/vpp-dev 
>> <https://lists.fd.io/mailman/listinfo/vpp-dev>
> -- 
> Thomas F Herbert 
> NFV and Fast Data Planes 
> Office of Technology 
> Red Hat
> ___
> 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] 17.10 draft release notes

[Florin Coras]

Dear all, 

You can find a draft of VPP 17.10 release notes here [1]. Feel free to add 
comments, reply to this message or send me private messages if something is 
missing. 

Regards, 
Florin

[1] https://gerrit.fd.io/r/#/c/8953/ ___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Maximum TCP session number

[Florin Coras]

When apps attach to the session layer they request a given size for the shared 
memory segment out of which fifos are allocated and also the sizes of the rx/tx 
fifos for each connection. If the segment is filled, more shared memory 
segments are allocated. However, if you’re running the builtin test 
client/servers, segments are allocated out of vpp’s private heap. You can 
circumvent this through config parameters:
- private-segment-size 
- preallocate-fifos   

You can check to see that things have worked by doing: “sh segment-manager 
segments”. 

Hope this helps, 
Florin

> On Nov 22, 2017, at 9:00 PM, choonho@gmail.com wrote:
> 
> Hi,
> 
> I got tcp servers warning like,
> 
> 0: segment_manager_alloc_session_fifos:464: No space to allocate fifos!
> 0: tcp46_listen_inline:2788: session accept fail
> 
> 
> DBGvpp# show session
> Thread 0: 2031 active sessions
> 
> What is tunning parameter or codes to increase number of tcp session?
> 
> Thanks,
> Choonho
> ___
> 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] problem in elog format

[Florin Coras]

Hi Juan, 

We don’t typically use elogs to store strings, still, you may be able to get it 
to run with: 

struct
{
u8 err[20];
} * ed;

And then copy your data to err: clib_memcpy (ed->err, your_vec, vec_len 
(your_vec)). Make sure your vec is 0 terminated.

HTH,
Florin

> On Nov 28, 2017, at 9:12 PM, Juan Salmon  wrote:
> 
> 
> I want to use event-log and send string to one of elements of ed struct.
> but the result is not correct.
> 
> the sample code:
> 
> ELOG_TYPE_DECLARE (e) = {
> .format = "Test LOG: %s",
> .format_args = "s20",
> };
> struct
> {
> u8 * err;
> } * ed;
> 
> 
> vlib_worker_thread_t * w = vlib_worker_threads + cpu_index;
> ed = ELOG_TRACK_DATA (_global_main.elog_main, e, w->elog_track);
> 
> ed->err = format (0,"%s", "This is a Test");
> 
> 
> Could you please help me?
> 
> 
> Best Regards,
> Juan Salmon.
> ___
> 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] Is "gpe" a special word?

[Florin Coras]

Swarup, 

LISP-GPE has its own CLI to enable/disable which until now [1] returned status 
0 even if no input was provided. Therefore, the CLI parser, after finishing 
executing the first command, actually tried to execute 
lisp_gpe_enable_disable_command_fn and returned successfully. 

Should be fixed now. 

Thanks,
Florin

[1] https://gerrit.fd.io/r/#/c/9694/ 

> On Dec 1, 2017, at 11:21 AM, swarup  wrote:
> 
> Hi,
> 
> Some strange behavior with the word "gpe". We can add this word at the end of 
> many commands, it'll not throw any parsing error, but add anything else it'll 
> give parsing error.
> 
> Some example:
> 
> vpp# show vxlan tunnel ?
>   show vxlan tunnelshow vxlan tunnel
> vpp# show vxlan tunnel gpe  ---> No parse error
> No vxlan tunnels configured...
> vpp# show vxlan tunnel abc
> No vxlan tunnels configured...
> unknown input `abc'---> parse error
> vpp#
> vpp# show oam
>   Fib   Src   Dst  Last HeardState
> vpp# show oam gpe---> No parse error
>   Fib   Src   Dst  Last HeardState
> vpp# show oam ?
>   show oam show oam
> vpp# show oam abc
>   Fib   Src   Dst  Last HeardState
> unknown input `abc'  ---> parse error
> vpp#vpp# show one statistics details
> No statistics found.
> vpp# show one statistics details gpe
> No statistics found.
> vpp# show one statistics details abc
> No statistics found.
> unknown input `abc'
> vpp# show one statistics details vxlan
> No statistics found.
> unknown input `vxlan'
> vpp#
> 
> Sorry if this is not a problem at all..
> 
> Regards,
> 
> Swarup
> 
> ___
> 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] openSUSE build fails

[Florin Coras]

Agreed, doing functional testing against one distro should suffice (famous last 
words :-)). 

What do people think about running the verify jobs for the debians and then 
periodically (once per day/week?) run for the other distros, to make sure 
they’re not broken? 

Florin

> On Dec 14, 2017, at 8:04 AM, Damjan Marion (damarion)  
> wrote:
> 
> 
> Folks,
> 
> I'm hearing from multiple people that OpenSUSE verify job is failing (again).
> 
> 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.
> Also it cost resources
> 
> Thoughts?
> 
> Damjan
> 
> 
> 
> ___
> 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] TCP Options: tcp_header_t and tcp_options_t

[Florin Coras]

Hi Justin, 

The expectation until now has been that options are not parsed until hitting 
the tcp related nodes. If tcp_options_parse is enough, then make it public and 
use it.  That function just expects a tcp_options_t struct for outputting the 
results so no need for a tcp_connection_t. Now, if you need your special 
function to both read, match and update in place the options, then I recommend 
you write your own options parser. 

Hope this helps,
Florin

> On Nov 14, 2017, at 5:13 AM, Justin Iurman  wrote:
> 
> Hi Dave,
> 
> Thanks (again) for your reply.
> 
>> Brief commercial: hopefully you added your node to the ip4 unicast feature 
>> arc,
>> configured to grab pkts, pre-ip4/6-lookup.
> 
> Indeed, I added my node to the ip4-unicast feature arc.
> 
>> In feature-arc land, the following one-liner sets next0 so pkts will visit 
>> the
>> next enabled feature. The last node in the ip4-unicast feature arc is
>> ip4-lookup...
>> 
>> /* Next node in unicast feature arc */
>>vnet_get_config_data (em->config_main[table_index],
>>  >current_config_index, ,
>>  /* # bytes of config data */ 0);
>> 
>> Check the ip protocol and ignore any non-TCP pkts:
>> 
>> ip40 = vlib_buffer_get_current (b0);
>> if (ip40->protocol != IP_PROTOCOL_TCP)
>>   goto trace0;
>> 
>> Then use ip4_next_header() to find the tcp layer, etc. etc.
> 
> Actually, I'm already able to access L3 and L4 structures. But, when I have 
> the following, for instance:
> 
> ip40 = vlib_buffer_get_current (b0);
> if (ip40->protocol == IP_PROTOCOL_TCP)
> {
>  tcp_header_t *tcp = ip4_next_header(ip40);
>  // where are options (tcp_options_t) ?
> }
> 
> How am I able to access TCP options for each packet ? I mean, I could 
> directly parse them by moving the data pointer but I've also seen a function 
> called tcp_options_parse (see my previous email) that already does this job. 
> How would you proceed to do this ? The expected behavior is to match some 
> options and strip them.
> 
> Thanks,
> 
> Justin
> ___
> 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] TCP Options: tcp_header_t and tcp_options_t

[Florin Coras]

Hi Justin, 

For discarding options you’ll probably need to write your own function that 
first recomputes them and then moves the payload closer to the header. 
tcp_buffer_discard_bytes just chops off payload bytes, as in moves the buffer’s 
current_data pointer. I don’t think it’s enough for what you need. 

Cheers,
Florin

> On Nov 20, 2017, at 9:21 AM, Justin Iurman  wrote:
> 
> Hi Florin,
> 
> Sorry for the late response. In fact, you just confirmed what I expected, 
> thank you. I'll go with my own parser to include all options (even the 
> reserved ones), inspired by tcp_options_parse. I'll go with my own rewriter 
> too, inspired by tcp_options_write. 
> 
> But, what about discarded options (the ones I just want to remove) ? How 
> would you free/allocate/resize the buffer containing data (..., ip header, 
> tcp header, payload...) ? I just found a function called 
> tcp_buffer_discard_bytes but I'm not sure it's what I really need. I'm 
> looking for the cleanest vpp-way to do this.
> 
> Thanks for your help !
> 
> Justin
> 
>> Hi Justin,
>> 
>> The expectation until now has been that options are not parsed until hitting 
>> the
>> tcp related nodes. If tcp_options_parse is enough, then make it public and 
>> use
>> it.  That function just expects a tcp_options_t struct for outputting the
>> results so no need for a tcp_connection_t. Now, if you need your special
>> function to both read, match and update in place the options, then I 
>> recommend
>> you write your own options parser.
>> 
>> Hope this helps,
>> Florin
>> 
>>> On Nov 14, 2017, at 5:13 AM, Justin Iurman  wrote:
>>> 
>>> Hi Dave,
>>> 
>>> Thanks (again) for your reply.
>>> 
 Brief commercial: hopefully you added your node to the ip4 unicast feature 
 arc,
 configured to grab pkts, pre-ip4/6-lookup.
>>> 
>>> Indeed, I added my node to the ip4-unicast feature arc.
>>> 
 In feature-arc land, the following one-liner sets next0 so pkts will visit 
 the
 next enabled feature. The last node in the ip4-unicast feature arc is
 ip4-lookup...
 
/* Next node in unicast feature arc */
  vnet_get_config_data (em->config_main[table_index],
>current_config_index, ,
/* # bytes of config data */ 0);
 
 Check the ip protocol and ignore any non-TCP pkts:
 
ip40 = vlib_buffer_get_current (b0);
if (ip40->protocol != IP_PROTOCOL_TCP)
  goto trace0;
 
 Then use ip4_next_header() to find the tcp layer, etc. etc.
>>> 
>>> Actually, I'm already able to access L3 and L4 structures. But, when I have 
>>> the
>>> following, for instance:
>>> 
>>> ip40 = vlib_buffer_get_current (b0);
>>> if (ip40->protocol == IP_PROTOCOL_TCP)
>>> {
>>> tcp_header_t *tcp = ip4_next_header(ip40);
>>> // where are options (tcp_options_t) ?
>>> }
>>> 
>>> How am I able to access TCP options for each packet ? I mean, I could 
>>> directly
>>> parse them by moving the data pointer but I've also seen a function called
>>> tcp_options_parse (see my previous email) that already does this job. How 
>>> would
>>> you proceed to do this ? The expected behavior is to match some options and
>>> strip them.
>>> 
>>> Thanks,
>>> 
>>> Justin
>>> ___
>>> 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] TCP Options: tcp_header_t and tcp_options_t

[Florin Coras]

Quick note, for completeness: If you’re planning on discarding all headers up 
to tcp, the other option would be to move the tcp header forward, since it’s 
typically smaller than the payload. 

Florin

> On Nov 20, 2017, at 2:07 PM, Florin Coras <fcoras.li...@gmail.com> wrote:
> 
> Hi Justin, 
> 
> For discarding options you’ll probably need to write your own function that 
> first recomputes them and then moves the payload closer to the header. 
> tcp_buffer_discard_bytes just chops off payload bytes, as in moves the 
> buffer’s current_data pointer. I don’t think it’s enough for what you need. 
> 
> Cheers,
> Florin
> 
>> On Nov 20, 2017, at 9:21 AM, Justin Iurman <justin.iur...@uliege.be> wrote:
>> 
>> Hi Florin,
>> 
>> Sorry for the late response. In fact, you just confirmed what I expected, 
>> thank you. I'll go with my own parser to include all options (even the 
>> reserved ones), inspired by tcp_options_parse. I'll go with my own rewriter 
>> too, inspired by tcp_options_write. 
>> 
>> But, what about discarded options (the ones I just want to remove) ? How 
>> would you free/allocate/resize the buffer containing data (..., ip header, 
>> tcp header, payload...) ? I just found a function called 
>> tcp_buffer_discard_bytes but I'm not sure it's what I really need. I'm 
>> looking for the cleanest vpp-way to do this.
>> 
>> Thanks for your help !
>> 
>> Justin
>> 
>>> Hi Justin,
>>> 
>>> The expectation until now has been that options are not parsed until 
>>> hitting the
>>> tcp related nodes. If tcp_options_parse is enough, then make it public and 
>>> use
>>> it.  That function just expects a tcp_options_t struct for outputting the
>>> results so no need for a tcp_connection_t. Now, if you need your special
>>> function to both read, match and update in place the options, then I 
>>> recommend
>>> you write your own options parser.
>>> 
>>> Hope this helps,
>>> Florin
>>> 
>>>> On Nov 14, 2017, at 5:13 AM, Justin Iurman <justin.iur...@uliege.be> wrote:
>>>> 
>>>> Hi Dave,
>>>> 
>>>> Thanks (again) for your reply.
>>>> 
>>>>> Brief commercial: hopefully you added your node to the ip4 unicast 
>>>>> feature arc,
>>>>> configured to grab pkts, pre-ip4/6-lookup.
>>>> 
>>>> Indeed, I added my node to the ip4-unicast feature arc.
>>>> 
>>>>> In feature-arc land, the following one-liner sets next0 so pkts will 
>>>>> visit the
>>>>> next enabled feature. The last node in the ip4-unicast feature arc is
>>>>> ip4-lookup...
>>>>> 
>>>>>   /* Next node in unicast feature arc */
>>>>> vnet_get_config_data (em->config_main[table_index],
>>>>>   >current_config_index, ,
>>>>>   /* # bytes of config data */ 0);
>>>>> 
>>>>> Check the ip protocol and ignore any non-TCP pkts:
>>>>> 
>>>>>   ip40 = vlib_buffer_get_current (b0);
>>>>>   if (ip40->protocol != IP_PROTOCOL_TCP)
>>>>> goto trace0;
>>>>> 
>>>>> Then use ip4_next_header() to find the tcp layer, etc. etc.
>>>> 
>>>> Actually, I'm already able to access L3 and L4 structures. But, when I 
>>>> have the
>>>> following, for instance:
>>>> 
>>>> ip40 = vlib_buffer_get_current (b0);
>>>> if (ip40->protocol == IP_PROTOCOL_TCP)
>>>> {
>>>> tcp_header_t *tcp = ip4_next_header(ip40);
>>>> // where are options (tcp_options_t) ?
>>>> }
>>>> 
>>>> How am I able to access TCP options for each packet ? I mean, I could 
>>>> directly
>>>> parse them by moving the data pointer but I've also seen a function called
>>>> tcp_options_parse (see my previous email) that already does this job. How 
>>>> would
>>>> you proceed to do this ? The expected behavior is to match some options and
>>>> strip them.
>>>> 
>>>> Thanks,
>>>> 
>>>> Justin
>>>> ___
>>>> 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] [FD.io Helpdesk #48422] Gerrit and git out of sync?

[Florin Coras]

Hi Vanessa, 

It seems it got fixed in the morning but yesterday we were lagging something 
like 10+h. The two are now in sync. Hopefully it was just a passing glitch. 

Thanks, 
Florin

> On Nov 21, 2017, at 11:42 AM, Vanessa Valderrama via RT 
>  wrote:
> 
> Can you point me to specific changes that aren't in sync.  The branches 
> appear to be in sync.
> 
> 
> On Mon Nov 20 21:45:46 2017, fcoras.li...@gmail.com wrote:
>> Hi,
>> 
>> It seems that git master head points at a gerrit patch merged 10h
>> ago[1]. There have been several recent merges and none show up [2].
>> Any idea what may be causing this?
>> 
>> Thanks,
>> Florin
>> 
>> [1] https://git.fd.io/vpp/log/ 
>> [2] https://gerrit.fd.io/r/#/q/project:vpp
>> 
> 
> 
> 
> 

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Packages for master not published

[Florin Coras]

Feel free to ignore this. For some reason I only got Chris’ email after sending 
this one... 

Florin

> On Nov 6, 2017, at 10:09 AM, Florin Coras <fcoras.li...@gmail.com> wrote:
> 
> Hi Vanessa,
> 
> You can find a full log here[1] and what I suspect to be the culprit lower. 
> Any idea why this is happening?
> 
> Thanks, 
> Florin
> 
> 13:29:49 [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file (default-cli) on 
> project standalone-pom: Failed to deploy artifacts: Could not transfer 
> artifact io.fd.vpp:vpp-dpdk-dev:deb:deb:17.08-vpp2_amd64 from/to 
> fd.io.master.ubuntu.xenial.main 
> (https://nexus.fd.io/content/repositories/fd.io.master.ubuntu.xenial.main 
> <https://nexus.fd.io/content/repositories/fd.io.master.ubuntu.xenial.main>): 
> Failed to transfer file: 
> https://nexus.fd.io/content/repositories/fd.io.master.ubuntu.xenial.main/io/fd/vpp/vpp-dpdk-dev/17.08-vpp2_amd64/vpp-dpdk-dev-17.08-vpp2_amd64-deb.deb.
>  Return code is: 400, ReasonPhrase: Bad Request. -> [Help 1]
> 
> [1] https://jenkins.fd.io/job/vpp-merge-master-ubuntu1604/3147/consoleFull 
> <https://jenkins.fd.io/job/vpp-merge-master-ubuntu1604/3147/consoleFull>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Packages for master not published

[Florin Coras]

Hi Vanessa,

You can find a full log here[1] and what I suspect to be the culprit lower. Any 
idea why this is happening?

Thanks, 
Florin

13:29:49 [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file (default-cli) on 
project standalone-pom: Failed to deploy artifacts: Could not transfer artifact 
io.fd.vpp:vpp-dpdk-dev:deb:deb:17.08-vpp2_amd64 from/to 
fd.io.master.ubuntu.xenial.main 
(https://nexus.fd.io/content/repositories/fd.io.master.ubuntu.xenial.main): 
Failed to transfer file: 
https://nexus.fd.io/content/repositories/fd.io.master.ubuntu.xenial.main/io/fd/vpp/vpp-dpdk-dev/17.08-vpp2_amd64/vpp-dpdk-dev-17.08-vpp2_amd64-deb.deb.
 Return code is: 400, ReasonPhrase: Bad Request. -> [Help 1]

[1] https://jenkins.fd.io/job/vpp-merge-master-ubuntu1604/3147/consoleFull 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Missing udp.api.h header file?

[Florin Coras]

Hi Jon, 

This dates back to a couple of days ago. Fix is on the way … 

Florin

> On Nov 9, 2017, at 1:33 PM, Jon Loeliger <j...@netgate.com> wrote:
> 
> Folks,
> 
> Anyone recognize this one?
> 
> CC my_af_packet.c
> In file included from /usr/include/vpp/api/vpe_all_api_h.h:25:0,
>  from /usr/include/vpp/api/vpe_msg_enum.h:24,
>  from my_af_packet.c:14:
> /usr/include/vnet/vnet_all_api_h.h:64:30: fatal error: vnet/udp/udp.api.h: No 
> such file or directory
>  #include 
> 
> That is as of:
> 
> Author: Florin Coras <fco...@cisco.com <mailto:fco...@cisco.com>>
> Date:   Thu Nov 9 10:05:42 2017 -0800
> 
> session: fix app index in unbind
> 
>     Change-Id: Iff1a665b6cf9ca2def0fcdacf02d7f8c579c0f4e
> Signed-off-by: Florin Coras <fco...@cisco.com 
> <mailto:fco...@cisco.com>>
> 
> Thanks,
> jdl
> 
> ___
> 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] Missing udp.api.h header file?

[Florin Coras]

> On Nov 9, 2017, at 2:51 PM, Jon Loeliger <j...@netgate.com> wrote:
> 
> On Thu, Nov 9, 2017 at 4:29 PM, Florin Coras <fcoras.li...@gmail.com 
> <mailto:fcoras.li...@gmail.com>> wrote:
> Hi Jon, 
> 
> This dates back to a couple of days ago.
> 
> Hey, I don't pull *every* day... :-)

That was more of a “sigh” because we didn’t catch it … :-)

>  
> Fix is on the way … 
> 
> Florin
> 
> Thank you!
> 

No problem! Should be fine now.

Florin

> jdl
>  

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] syntax error near unexpected token `g2,'

[Florin Coras]

Hi Lori, 

backup
git clean -fdx
make bootstrap 
make build

Any luck?

Florin

> On Nov 6, 2017, at 4:17 AM, Lori Jakab  wrote:
> 
> Hi,
> 
> I see the exact same issue that is reported in a previous thread [0], which 
> didn't have a solution. I wonder if anyone has more insight now.
> 
> I did not use Vagrant to set up a VM with the build environment. On an Ubuntu 
> 16.04 VM I clone VPP latest master, do a `make install-dep` and then a `make 
> bootstrap`. This is what I get:
> 
> [...]
> checking for LIBRTE_PMD_AESNI_MB in rte_config.h... no
> checking for LIBRTE_PMD_AESNI_GCM in rte_config.h... no
> checking for RTE_VERSION 17.02/17.05 in rte_version.h... no
> checking for LIBRTE_MLX4_PMD in rte_config.h... no
> checking for LIBRTE_MLX5_PMD in rte_config.h... no
> /home/vagrant/vpp/build-root/../src/configure: line 18206: syntax error near 
> unexpected token `g2,'
> /home/vagrant/vpp/build-root/../src/configure: line 18206: `  
> PKG_CHECK_MODULES(g2, gtk+-2.0)'
> Makefile:635: recipe for target 'tools-configure' failed
> make[1]: *** [tools-configure] Error 2
> make[1]: Leaving directory '/home/vagrant/vpp/build-root'
> Makefile:226: recipe for target '/home/vagrant/vpp/build-root/.bootstrap.ok' 
> failed
> make: *** [/home/vagrant/vpp/build-root/.bootstrap.ok] Error 2
> 
> No idea what package may I be missing.
> 
> -Lori
> 
> [0] https://lists.fd.io/pipermail/vpp-dev/2017-March/004543.html 
> ___
> 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] Is there a planned VPP 17.10.01?

[Florin Coras]

The second option :-)

Cheers, 
Florin

> On Dec 7, 2017, at 2:27 PM, Billy McFall  wrote:
> 
> I see a handful of merges on stable/1710 and was just looking to see if there 
> is a scheduled date or plan for a VPP 17.10.01 release? OR are these merges 
> just there in-case there is a VPP 17.10.01 release in the future?
> 
> Thanks,
> Billy McFall
> 
> -- 
> Billy McFall 
> Networking Group 
> CTO Office
> Red Hat
> ___
> 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] The feasibility of C++ gRPC with libvcl_ldpreload

[Florin Coras]

Hi Peter, 

eventfd, as far as I know, is used for event notification. In other words, it’s 
not something needed for exchanging data with a remote peer over tcp. Could you 
provide more details concerning what you’re trying to achieve?

Cheers, 
Florin

> On Dec 6, 2017, at 2:25 PM, Peter Palmár  wrote:
> 
> Hi,
> 
> we are testing the VPP TCP stack by using the following combination: A C++ 
> application based on C++ gRPC with libvcl_ldpreload.
> 
> We use greeter_server and greeter_client from grpc/examples/cpp/helloworld 
> taken from https://github.com/grpc/grpc .
> 
> The server and client use the eventfd()/eventfd2() system call which is not 
> implemented in libvcl_ldpreload;
> this seems to be a reason why the communication between the server and client 
> does not work.
> 
> Could you please let me know whether I am right and if so, whether/when an 
> implementation of eventfd is planned to be added to libvcl_ldpreload?
> 
> The attached file contains the client output.
> 
> Regards,
> Peter
> 
> ___
> 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] assertion in gpe testing

[Florin Coras]

Hi Xyxue,

Did you by chance configure an ip or a route through the gpe interface? If yes, 
then that is probably the issue. If not, could you provide more details 
regarding your configuration. 

Thanks,
Florin

> On Dec 10, 2017, at 6:25 PM, 薛欣颖  wrote:
> 
> 
> Hi guys，
> 
> There is an assertion when I was configuring the GPE service, and I didn't 
> find a solution. Can you help me see the reasons for it?
> 
> Breakpoint 1, vl_api_gpe_add_del_fwd_entry_t_handler (mp=0x2b8413872f9c) at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/lisp-gpe/lisp_gpe_api.c:328
> 328 {
> (gdb) p *mp
> $1 = {_vl_msg_id = 16129, client_index = 805306625, context = 0, is_add = 1 
> '\001', eid_type = 0 '\000', rmt_eid = 
> "1.1.3.1\000\000\000\000\000\000\000\000", 
>   lcl_eid = "1.1.2.1\000\000\000\000\000\000\000\000", rmt_len = 24 '\030', 
> lcl_len = 24 '\030', vni = 16777216, dp_table = 16777216, action = 4 '\004', 
> loc_num = 33554432, 
>   locs = 0x2b8413872fd7}
> (gdb) c
> Continuing.
> 
> Program received signal SIGABRT, Aborted.
> 0x2b8412519c37 in __GI_raise (sig=sig@entry=6) at 
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> 56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x2b8412519c37 in __GI_raise (sig=sig@entry=6) at 
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x2b841251d028 in __GI_abort () at abort.c:89
> #2  0x00406e9b in os_panic () at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vpp/vnet/main.c:294
> #3  0x2b8411e36b98 in debugger () at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vppinfra/error.c:84
> #4  0x2b8411e36f9f in _clib_error (how_to_die=2, function_name=0x0, 
> line_number=0, fmt=0x2b8411a87488 "%s:%d (%s) assertion `%s' fails")
> at /home/vpp/17.07_x64/vpp/build-data/../src/vppinfra/error.c:143
> #5  0x2b84117d9f14 in lisp_gpe_build_rewrite (vnm=0x2b8411e07560 
> , sw_if_index=3, link_type=VNET_LINK_ARP, dst_address=0x0)
> at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/lisp-gpe/lisp_gpe_adjacency.c:370
> #6  0x2b8411985a76 in vnet_rewrite_for_sw_interface (vnm=0x2b8411e07560 
> , link_type=VNET_LINK_ARP, sw_if_index=3, node_index=312, 
> dst_address=0x0, rw=0x2b841386a780, 
> max_rewrite_bytes=112) at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/adj/rewrite.c:133
> #7  0x2b8411978012 in adj_glean_add_or_lock (proto=FIB_PROTOCOL_IP4, 
> sw_if_index=3, nh_addr=0x0) at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/adj/adj_glean.c:73
> #8  0x2b84119683b6 in fib_path_attached_get_adj (path=0x2b8413866bc8, 
> link=VNET_LINK_IP4) at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/fib/fib_path.c:719
> #9  0x2b841196a7a2 in fib_path_resolve (path_index=22) at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/fib/fib_path.c:1880
> #10 0x2b8411964406 in fib_path_list_resolve (path_list=0x2b841386619c) at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/fib/fib_path_list.c:567
> #11 0x2b84119648bd in fib_path_list_create 
> (flags=FIB_PATH_LIST_FLAG_SHARED, rpaths=0x2b8413a96080) at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/fib/fib_path_list.c:725
> #12 0x2b841195ff39 in fib_entry_src_lisp_path_swap (src=0x2b8413872dd4, 
> entry=0x2b84138700c4, pl_flags=FIB_PATH_LIST_FLAG_NONE, paths=0x2b8413a96080)
> at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/fib/fib_entry_src_lisp.c:42
> #13 0x2b841195b529 in fib_entry_src_action_path_swap 
> (fib_entry=0x2b84138700c4, source=FIB_SOURCE_LISP, flags=FIB_ENTRY_FLAG_NONE, 
> rpaths=0x2b8413a96080)
> at /home/vpp/17.07_x64/vpp/build-data/../src/vnet/fib/fib_entry_src.c:1191
> #14 0x2b8411956c3c in fib_entry_create (fib_index=1, 
> prefix=0x2b8413674a30, source=FIB_SOURCE_LISP, flags=FIB_ENTRY_FLAG_NONE, 
> paths=0x2b8413a96080)
> at /home/vpp/17.07_x64/vpp/build-data/../src/vnet/fib/fib_entry.c:828
> #15 0x2b8411947a39 in fib_table_entry_update (fib_index=1, 
> prefix=0x2b8413674a30, source=FIB_SOURCE_LISP, flags=FIB_ENTRY_FLAG_NONE, 
> paths=0x2b8413a96080)
> at /home/vpp/17.07_x64/vpp/build-data/../src/vnet/fib/fib_table.c:778
> #16 0x2b84117dffdc in ip_src_fib_add_route (src_fib_index=1, 
> src_prefix=0x2b8413674ab0, paths=0x2b8413a2d7f0)
> at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/lisp-gpe/lisp_gpe_fwd_entry.c:288
> #17 0x2b84117e063e in create_fib_entries (lfe=0x2b8413872f28) at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/lisp-gpe/lisp_gpe_fwd_entry.c:384
> #18 0x2b84117e13ac in add_ip_fwd_entry (lgm=0x2b8411e10040 
> , a=0x2b8413674c50) at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/lisp-gpe/lisp_gpe_fwd_entry.c:568
> #19 0x2b84117e36f5 in vnet_lisp_gpe_add_del_fwd_entry (a=0x2b8413674c50, 
> hw_if_indexp=0x0) at 
> /home/vpp/17.07_x64/vpp/build-data/../src/vnet/lisp-gpe/lisp_gpe_fwd_entry.c:1264
> #20 0x2b84117f1bec in vl_api_gpe_add_del_fwd_entry_t_handler 
> (mp=0x2b8413872f9c) at 
> 

Re: [vpp-dev] 17.10 draft release notes

[Florin Coras]

Good news is that we’re still in time for the change. Bad news is that there’s 
no time for a real ‘community vote’ on this. 

I also liked the first option better but since Ole and Jon pushed for the 
change, I went with what they liked.

Does anyone object to using the first option?

Thanks,
Florin 


> On Oct 25, 2017, at 3:56 PM, Luke, Chris <chris_l...@comcast.com> wrote:
> 
> Hrm, I personally feel the breakdown by file to be more useful than who made 
> the change.
> 
> Chris
> 
>> -Original Message-
>> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
>> Behalf Of Florin Coras
>> Sent: Wednesday, October 25, 2017 1:58 PM
>> To: Ole Troan <otr...@employees.org>
>> Cc: vpp-dev <vpp-dev@lists.fd.io>
>> Subject: Re: [vpp-dev] 17.10 draft release notes
>> 
>> Updated release notes to use the format Jon proposed.
>> 
>> Florin
>> 
>>> On Oct 25, 2017, at 9:11 AM, Ole Troan <otr...@employees.org> wrote:
>>> 
>>> Thanks Jon, love that!
>>> 
>>> So something like:
>>> git shortlog --format="* [%h] %s" v17.07..v17.10-rc2 -- *.api
>>> 
>>> Cheers,
>>> Ole
>>> 
>>> 
>>>> On 25 Oct 2017, at 07:13, Jon Loeliger <j...@netgate.com> wrote:
>>>> 
>>>> On Wed, Oct 25, 2017 at 7:28 AM, Ole Troan <otr...@employees.org>
>> wrote:
>>>> Hi Florin,
>>>> 
>>>> Hi Ole,
>>>> 
>>>> What about something like this?
>>>> 
>>>> #!/usr/bin/env python
>>>> import os, fnmatch, subprocess
>>>> starttag = 'v17.07'
>>>> endtag = 'v17.10-rc2'
>>>> apifiles = []
>>>> for root, dirnames, filenames in os.walk('.'):
>>>>   for filename in fnmatch.filter(filenames, '*.api'):
>>>>   apifiles.append(os.path.join(root, filename)) for f in
>>>> apifiles:
>>>>   commits = subprocess.check_output(['git', 'log',
>>>>  '--oneline', starttag + '..' + endtag,
>>>>  f])
>>>>   if commits:
>>>>   print f
>>>>   print commits
>>>> 
>>>> 
>>>> Just as an FYI, Git might be able to help simplify some of this
>>>> script for you too.  For example:
>>>> 
>>>>   $ git ls-files *.api
>>>>   src/examples/sample-plugin/sample/sample.api
>>>>   src/plugins/acl/acl.api
>>>>   src/plugins/dpdk/api/dpdk.api
>>>>   src/plugins/flowprobe/flowprobe.api
>>>>   src/plugins/gtpu/gtpu.api
>>>>   
>>>> 
>>>> Depending on development at HEAD, you may want:
>>>>   $ git ls-files v17.10-rc2 *.api
>>>> or so.
>>>> 
>>>> Then, if you are not too concerned about the individual break-down by
>>>> file, you can one-line it:
>>>> 
>>>>   $ git log --oneline v17.07..v17.10-rc2 -- *.api
>>>>   50570ec Update of free text tag patch for BD
>>>>   831fb59 Stats refactor
>>>>   2297af0 Add a name to the creation of an IP and MPLS table
>>>>   c29940c ACL-plugin add "replace" semantics for adding a new MacIP acl
>>>>   8a19f12 Allow individual stats API and introduce stats.api -
>> want_interface_simple_stats - want_interface_combined_stats -
>> want_ip4|6_fib|nbr_stats
>>>>   d630713 LISP: add neighbor discovery and CP protocol separation APIs
>>>>   111a5ce LISP: Add APIs for enable/disable xTR/P-ITR/P-ETR modes
>>>>   4802632 Punt socket: Fix coverity error for pathname length mismatch
>> between API and sun_path.
>>>>   33e002b Fix session connect_* api message handling.
>>>>   
>>>> 
>>>> Also, the "shortlog" command is tailored to producing release notes:
>>>> 
>>>>   $ git shortlog v17.07..v17.10-rc2 -- *.api
>>>>   Dave Barach (1):
>>>> TCP source address automation
>>>> 
>>>>   Dave Wallace (1):
>>>> Fix session connect_* api message handling.
>>>> 
>>>>   Eyal Bari (3):
>>>> API:fix arp/ND event messages - remove context
>>>> SPAN:add l2 mirror
>>>> SPAN/API:enable L2 dump
>>>> 
>>>>   Filip Tehlar (4):
>>>> LISP: make TTL for map register messages configurable
>>>> LISP: Map-server fallback feature
>>>> LISP: Add APIs for enable/disable xTR/P-ITR/P-ETR modes
>>>> LISP: add neighbor discovery and CP protocol separation APIs
>>>>   
>>>> 
>>>> HTH,
>>>> jdl
>>> 
>> 
>> ___
>> 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] 17.10 draft release notes

[Florin Coras]

Hi Ole, 

Looks good to me. I’d add it after the list of APIs that changed. Is that fine 
with you?

Cheers, 
Florin

> On Oct 25, 2017, at 5:28 AM, Ole Troan  wrote:
> 
> Hi Florin,
> 
> What about something like this?
> 
> #!/usr/bin/env python
> import os, fnmatch, subprocess
> starttag = 'v17.07'
> endtag = 'v17.10-rc2'
> apifiles = []
> for root, dirnames, filenames in os.walk('.'):
>for filename in fnmatch.filter(filenames, '*.api'):
>apifiles.append(os.path.join(root, filename))
> for f in apifiles:
>commits = subprocess.check_output(['git', 'log',
>   '--oneline', starttag + '..' + endtag,
>   f])
>if commits:
>print f
>print commits
> 
> 
> 
> Which gives:
> 
> ./src/plugins/pppoe/pppoe.api
> 62f9cdd8 Add PPPoE Plugin
> 
> ./src/plugins/acl/acl.api
> c29940c5 ACL-plugin add "replace" semantics for adding a new MacIP acl
> de9fbf43 MAC IP ACL interface list dump (as an alternative to the get/reply)
> 
> ./src/plugins/nat/nat.api
> 704018cf NAT: Destination NAT44 with load-balancing (VPP-954)
> 2ba92e32 NAT: Rename snat plugin to nat (VPP-955)
> 
> ./src/vnet/interface.api
> 831fb59f Stats refactor
> d292ab1e No context in SW interface event
> a07bd708 Dedicated SW Interface Event
> 
> ./src/vnet/dhcp/dhcp.api
> 51822bf0 DHCP client option 61 "client_id"
> 4729b1ec DHCP complete event sends mask length
> 
> ./src/vnet/lldp/lldp.api
> 99a0e60e Add API support for LLDP config/interface set
> 
> ./src/vnet/lisp-cp/one.api
> d630713d LISP: add neighbor discovery and CP protocol separation APIs
> 111a5cea LISP: Add APIs for enable/disable xTR/P-ITR/P-ETR modes
> 7048ff1e LISP: Map-server fallback feature
> 1e553a00 LISP: make TTL for map register messages configurable
> 
> ./src/vnet/ethernet/p2p_ethernet.api
> 15ac81c1 P2P Ethernet
> 
> ./src/vnet/mpls/mpls.api
> 2297af01 Add a name to the creation of an IP and MPLS table
> 28ab9cc1 FIB table add/delete API only
> da78f957 L2 over MPLS
> a0a908f1 FIB path weight incorrect in dump (VPP-922)
> 57b5860f FIB path preference
> 
> ./src/vnet/session/session.api
> 33e002b1 Fix session connect_* api message handling.
> 
> ./src/vnet/span/span.api
> 5b311202 SPAN/API:enable L2 dump
> 001fd406 SPAN:add l2 mirror
> 
> ./src/vnet/devices/virtio/vhost_user.api
> 4ba75f54 vhost: Remove operation mode in the API
> 
> ./src/vnet/vxlan-gpe/vxlan_gpe.api
> 04ffd0ad VPP crash on creating vxlan gpe interface. VPP-875
> 
> ./src/vnet/tcp/tcp.api
> 3bbcfab1 TCP source address automation
> 
> ./src/vnet/ip/ip.api
> 2297af01 Add a name to the creation of an IP and MPLS table
> 28ab9cc1 FIB table add/delete API only
> 57b5860f FIB path preference
> 
> ./src/vnet/lisp-gpe/lisp_gpe.api
> af3d9771 Remove unused retval from gpe_native_fwd_rpath type definition
> 
> ./src/vnet/l2/l2.api
> 50570ece Update of free text tag patch for BD
> 48304141 Support for bridge domain free text tag
> e531f4cb Increase default MAC learn limit and check it in learn-update path
> 8d00fff8 Add support for API client to receive L2 MAC events
> 
> ./src/vpp/api/vpe.api
> 8a19f12a Allow individual stats API and introduce stats.api - 
> want_interface_simple_stats - want_interface_combined_stats - 
> want_ip4|6_fib|nbr_stats
> 4802632d Punt socket: Fix coverity error for pathname length mismatch between 
> API and sun_path.
> f7a55ad7 PUNT socket: External control plane processes connected via UNIX 
> domain sockets.
> 75e2f2ac API:fix arp/ND event messages - remove context
> 99a0e60e Add API support for LLDP config/interface set
> 
> ./src/vpp/stats/stats.api
> 831fb59f Stats refactor
> 8a19f12a Allow individual stats API and introduce stats.api - 
> want_interface_simple_stats - want_interface_combined_stats - 
> want_ip4|6_fib|nbr_stats
> 

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] 17.10 draft release notes

[Florin Coras]

Updated release notes to use the format Jon proposed. 

Florin

> On Oct 25, 2017, at 9:11 AM, Ole Troan  wrote:
> 
> Thanks Jon, love that!
> 
> So something like:
> git shortlog --format="* [%h] %s" v17.07..v17.10-rc2 -- *.api
> 
> Cheers,
> Ole
> 
> 
>> On 25 Oct 2017, at 07:13, Jon Loeliger  wrote:
>> 
>> On Wed, Oct 25, 2017 at 7:28 AM, Ole Troan  wrote:
>> Hi Florin,
>> 
>> Hi Ole,
>> 
>> What about something like this?
>> 
>> #!/usr/bin/env python
>> import os, fnmatch, subprocess
>> starttag = 'v17.07'
>> endtag = 'v17.10-rc2'
>> apifiles = []
>> for root, dirnames, filenames in os.walk('.'):
>>for filename in fnmatch.filter(filenames, '*.api'):
>>apifiles.append(os.path.join(root, filename))
>> for f in apifiles:
>>commits = subprocess.check_output(['git', 'log',
>>   '--oneline', starttag + '..' + endtag,
>>   f])
>>if commits:
>>print f
>>print commits
>> 
>> 
>> Just as an FYI, Git might be able to help simplify some of
>> this script for you too.  For example:
>> 
>>$ git ls-files *.api
>>src/examples/sample-plugin/sample/sample.api
>>src/plugins/acl/acl.api
>>src/plugins/dpdk/api/dpdk.api
>>src/plugins/flowprobe/flowprobe.api
>>src/plugins/gtpu/gtpu.api
>>
>> 
>> Depending on development at HEAD, you may want:
>>$ git ls-files v17.10-rc2 *.api
>> or so.
>> 
>> Then, if you are not too concerned about the individual
>> break-down by file, you can one-line it:
>> 
>>$ git log --oneline v17.07..v17.10-rc2 -- *.api
>>50570ec Update of free text tag patch for BD
>>831fb59 Stats refactor
>>2297af0 Add a name to the creation of an IP and MPLS table
>>c29940c ACL-plugin add "replace" semantics for adding a new MacIP acl
>>8a19f12 Allow individual stats API and introduce stats.api - 
>> want_interface_simple_stats - want_interface_combined_stats - 
>> want_ip4|6_fib|nbr_stats
>>d630713 LISP: add neighbor discovery and CP protocol separation APIs
>>111a5ce LISP: Add APIs for enable/disable xTR/P-ITR/P-ETR modes
>>4802632 Punt socket: Fix coverity error for pathname length mismatch 
>> between API and sun_path.
>>33e002b Fix session connect_* api message handling.
>>
>> 
>> Also, the "shortlog" command is tailored to producing release notes:
>> 
>>$ git shortlog v17.07..v17.10-rc2 -- *.api
>>Dave Barach (1):
>>  TCP source address automation
>> 
>>Dave Wallace (1):
>>  Fix session connect_* api message handling.
>> 
>>Eyal Bari (3):
>>  API:fix arp/ND event messages - remove context
>>  SPAN:add l2 mirror
>>  SPAN/API:enable L2 dump
>> 
>>Filip Tehlar (4):
>>  LISP: make TTL for map register messages configurable
>>  LISP: Map-server fallback feature
>>  LISP: Add APIs for enable/disable xTR/P-ITR/P-ETR modes
>>  LISP: add neighbor discovery and CP protocol separation APIs
>>
>> 
>> HTH,
>> jdl
> 

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] how to punt a specific TCP flow into linux kernel?

[Florin Coras]

Hi Lin, 

You can punt all tcp traffic without state in the stack with "set punt tcp”. 
You’ll also have to enable the session layer for that to work with “session 
enable”. Finally, the simplest way to get the traffic into linux is to add to 
vpp’s startup.conf tuntap { enable }.

Hope this helps, 
Florin

> On Dec 20, 2017, at 4:01 AM, lin huang  wrote:
> 
> Hi all
>  I want to punt a specific TCP flow into linux kernel. and there will 
> be an application which receive the packets.
> So, how can I solve this problem?? Is there a demo for me???
> ___
> 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] question about the VCL

[Florin Coras]

Hi Xyxue, 

No, the stack does not support IPPROTO_RAW. Given that this is a user space 
stack and that you have access to things like memif, may I ask what use case 
you would need that for?

Florin

> On May 14, 2018, at 12:58 AM, xyxue  wrote:
> 
> 
> Hi guys,
> 
> Is the VCL support RAW_IP now ? Or is there a plan to support it? 
> 
> Thanks,
> Xyxue
> 

Re: [vpp-dev] TCP performance - TSO - HW offloading in general.

[Florin Coras]

Hi Luca, 

That is most probably the reason. We don’t support raw sockets. 

Florin

> On May 14, 2018, at 1:21 AM, Luca Muscariello (lumuscar) <lumus...@cisco.com> 
> wrote:
> 
> Hi Florin,
>
> Session enable does not help.
> hping is using raw sockets so this must be the reason.
>
> Luca
>
>
>
> From: Florin Coras <fcoras.li...@gmail.com>
> Date: Friday 11 May 2018 at 23:02
> To: Luca Muscariello <lumuscar+f...@cisco.com>
> Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] TCP performance - TSO - HW offloading in general.
>
> Hi Luca,
>
> Not really sure why the kernel is slow to reply to ping. Maybe it has to do 
> with scheduling but it’s just guess work. 
>
> I’ve never tried hping. Let me see if I understand your scenario: while 
> running iperf you tried to hping the stack and you got no rst back? Anything 
> interesting in “sh error” counters? If iperf wasn’t running, did you first 
> enable the stack with “session enable”?
>
> Florin
> 
> 
>> On May 11, 2018, at 3:19 AM, Luca Muscariello <lumuscar+f...@cisco.com 
>> <mailto:lumuscar+f...@cisco.com>> wrote:
>>
>> Florin,
>>
>> A few more comments about latency.
>> Some number in ms in the table below:
>>
>> This is ping and iperf3 concurrent. In case of VPP it is vppctl ping.
>>
>> Kernel w/ load   Kernel w/o load  VPP w/ load  VPP w/o load
>> Min.   :0.1920   Min.   :0.0610   Min.   :0.0573   Min.   :0.03480
>> 1st Qu.:0.2330   1st Qu.:0.1050   1st Qu.:0.2058   1st Qu.:0.04640
>> Median :0.2450   Median :0.1090   Median :0.2289   Median :0.04880
>> Mean   :0.2458   Mean   :0.1153   Mean   :0.2568   Mean   :0.05096
>> 3rd Qu.:0.2720   3rd Qu.:0.1290   3rd Qu.:0.2601   3rd Qu.:0.05270
>> Max.   :0.2800   Max.   :0.1740   Max.   :0.6926   Max.   :0.09420
>>
>> In short: ICMP packets have a lower latency under load.
>> I could interpret this as du to vectorization maybe. Also the Linux kernel
>> is slower to reply to ping by x2 factor (system call latency?) 115us vs
>> 50us in VPP. w/ load no difference. In this test Linux TCP is using TSO.
>>
>> While trying to use hping  to have a latency sample w/ TCP instead of ICMP 
>> we noticed that VPP TCP stack does not reply with a RST. So we don’t get
>> any sample. Is that expected behavior?
>>
>> Thanks
>>
>>
>> Luca
>>
>>
>>
>>
>>
>> From: Luca Muscariello <lumus...@cisco.com <mailto:lumus...@cisco.com>>
>> Date: Thursday 10 May 2018 at 13:52
>> To: Florin Coras <fcoras.li...@gmail.com <mailto:fcoras.li...@gmail.com>>
>> Cc: Luca Muscariello <lumuscar+f...@cisco.com 
>> <mailto:lumuscar+f...@cisco.com>>, "vpp-dev@lists.fd.io 
>> <mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io 
>> <mailto:vpp-dev@lists.fd.io>>
>> Subject: Re: [vpp-dev] TCP performance - TSO - HW offloading in general.
>>
>> MTU had no effect, just statistical fluctuations in the test reports. Sorry 
>> for misreporting the info.
>>
>> We are exploiting vectorization as we have a single memif channel 
>> per transport socket so we can control the size of the batches dynamically. 
>>
>> In theory the size of outstanding data from the transport should be 
>> controlled in bytes for 
>> batching to be useful and not harmful as frame sizes can vary a lot. But I’m 
>> not aware of a queue abstraction from DPDK 
>> to control that from VPP.
>>
>> From: Florin Coras <fcoras.li...@gmail.com <mailto:fcoras.li...@gmail.com>>
>> Date: Wednesday 9 May 2018 at 18:23
>> To: Luca Muscariello <lumus...@cisco.com <mailto:lumus...@cisco.com>>
>> Cc: Luca Muscariello <lumuscar+f...@cisco.com 
>> <mailto:lumuscar+f...@cisco.com>>, "vpp-dev@lists.fd.io 
>> <mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io 
>> <mailto:vpp-dev@lists.fd.io>>
>> Subject: Re: [vpp-dev] TCP performance - TSO - HW offloading in general.
>>
>> Hi Luca,
>>
>> We don’t yet support pmtu in the stack so tcp uses a fixed 1460 mtu, unless 
>> you changed that, we shouldn’t generate jumbo packets. If we do, I’ll have 
>> to take a look at it :)
>>
>> If you already had your transport protocol, using memif is the natural way 
>> to go. Using the session layer makes sense only if you can implement your 
>> transport within vpp in a way that leverages vectorization or if it can 
>> leverage the existing transports (see for instance th

Re: [vpp-dev] Using custom openssl with vpp #vpp

[Florin Coras]

Hi DucTM, 

Did you try changing src/plugin/tlsopenssl.am to link against openssl 1.1? I’ve 
never tried it, so no idea what the end result may be :-)

Florin

> On May 14, 2018, at 3:52 AM, duct...@viettel.com.vn wrote:
> 
> Hi,
> I'm trying to customize the openssl plugin that needs to work with openssl 
> 1.1 (with some modification also).
> Applying the new openssl version to the system is not possible since there 
> are some other apps rely on openssl, and they do not work with openssl 1.1.
> Is there any configuration I can make to use vpp with a relative build 
> openssl? Or just some idea about how to achieve that.
> Any help will be highly appreciated.
> 
> DucTM
> 

Re: [vpp-dev] TCP performance - TSO - HW offloading in general.

[Florin Coras]

Hi Luca, 

We don’t yet support pmtu in the stack so tcp uses a fixed 1460 mtu, unless you 
changed that, we shouldn’t generate jumbo packets. If we do, I’ll have to take 
a look at it :)

If you already had your transport protocol, using memif is the natural way to 
go. Using the session layer makes sense only if you can implement your 
transport within vpp in a way that leverages vectorization or if it can 
leverage the existing transports (see for instance the TLS implementation).

Until today [1] the stack did allow for excessive batching (generation of 
multiple frames in one dispatch loop) but we’re now restricting that to one. 
This is still far from proper pacing which is on our todo list. 

Florin

[1] https://gerrit.fd.io/r/#/c/12439/ <https://gerrit.fd.io/r/#/c/12439/>


> On May 9, 2018, at 4:21 AM, Luca Muscariello (lumuscar) <lumus...@cisco.com> 
> wrote:
> 
> Florin,
>
> Thanks for the slide deck, I’ll check it soon.
>
> BTW, VPP/DPDK test was using jumbo frames by default so the TCP stack had a 
> little
> advantage wrt the Linux TCP stack which was using 1500B by default.
>
> By manually setting DPDK MTU to 1500B the goodput goes down to 8.5Gbps which 
> compares
> to 4.5Gbps for Linux w/o TSO. Also congestion window adaptation is not the 
> same.
>
> BTW, for what we’re doing it is difficult to reuse the VPP session layer as 
> it is.
> Our transport stack uses a different kind of namespace and mux/demux is also 
> different.
>
> We are using memif as underlying driver which does not seem to be a
> bottleneck as we can also control batching there. Also, we have our own
> shared memory downstream memif inside VPP through a plugin.
>
> What we observed is that delay-based congestion control does not like
> much VPP batching (batching in general) and we are using DBCG.
>
> Linux TSO has the same problem but has TCP pacing to limit bad effects of 
> bursts
> on RTT/losses and flow control laws.
>
> I guess you’re aware of these issues already.
>
> Luca
>
>
> From: Florin Coras <fcoras.li...@gmail.com>
> Date: Monday 7 May 2018 at 22:23
> To: Luca Muscariello <lumus...@cisco.com>
> Cc: Luca Muscariello <lumuscar+f...@cisco.com>, "vpp-dev@lists.fd.io" 
> <vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] TCP performance - TSO - HW offloading in general.
>
> Yes, the whole host stack uses shared memory segments and fifos that the 
> session layer manages. For a brief description of the session layer see [1, 
> 2]. Apart from that, unfortunately, we don’t have any other dev 
> documentation. src/vnet/session/segment_manager.[ch] has some good examples 
> of how to allocate segments and fifos. Under application_interface.h check 
> app_[send|recv]_[stream|dgram]_raw for examples on how to read/write to the 
> fifos.  <>
>
> Now, regarding the the writing to the fifos: they are lock free but size 
> increments are atomic since the assumption is that we’ll always have one 
> reader and one writer. Still, batching helps. VCL doesn’t do it but iperf 
> probably does it. 
>
> Hope this helps, 
> Florin
>
> [1] https://wiki.fd.io/view/VPP/HostStack/SessionLayerArchitecture 
> <https://wiki.fd.io/view/VPP/HostStack/SessionLayerArchitecture>
> [2] https://wiki.fd.io/images/1/15/Vpp-hoststack-kc-eu-18.pdf 
> <https://wiki.fd.io/images/1/15/Vpp-hoststack-kc-eu-18.pdf>
> 
> 
>> On May 7, 2018, at 11:35 AM, Luca Muscariello (lumuscar) <lumus...@cisco.com 
>> <mailto:lumus...@cisco.com>> wrote:
>>
>> Florin,
>>
>> So the TCP stack does not connect to VPP using memif.
>> I’ll check the shared memory you mentioned.
>>
>> For our transport stack we’re using memif. Nothing to 
>> do with TCP though.
>>
>> Iperf3 to VPP there must be copies anyway. 
>> There must be some batching with timing though 
>> while doing these copies.
>>
>> Is there any doc of svm_fifo usage?
>>
>> Thanks
>> Luca 
>> 
>> On 7 May 2018, at 20:00, Florin Coras <fcoras.li...@gmail.com 
>> <mailto:fcoras.li...@gmail.com>> wrote:
>> 
>>> Hi Luca,
>>>
>>> I guess, as you did, that it’s vectorization. VPP is really good at pushing 
>>> packets whereas Linux is good at using all hw optimizations. 
>>>
>>> The stack uses it’s own shared memory mechanisms (check svm_fifo_t) but 
>>> given that you did the testing with iperf3, I suspect the edge is not 
>>> there. That is, I guess they’re not abusing syscalls with lots of small 
>>> writes. Moreover, the fifos are not zero-copy, apps do have to write to the 
>>> fifo and vpp has to packetize th

Re: [vpp-dev] TCP performance - TSO - HW offloading in general.

[Florin Coras]

Hi Luca, 

We don’t yet support TSO because it requires support within all of vpp (think 
tunnels). Still, it’s on our list. 

As for crypto offload, we do have support for IPSec offload with QAT cards and 
we’re now working with Ping and Ray from Intel on accelerating the TLS OpenSSL 
engine also with QAT cards. 

Regards, 
Florin

> On May 7, 2018, at 7:53 AM, Luca Muscariello  wrote:
> 
> Hi,
>
> A few questions about the TCP stack and HW offloading.
> Below is the experiment under test.
>
>   ++  +---+
>   |  +-+ DPDK-10GE|   |
>   |Iperf3| TCP |  ++  |TCP   Iperf3
>   |  ++Nexus Switch+--+   +
>   |LXC   | VPP||  ++  |VPP |LXC   |
>   ++  DPDK-10GE   +---+
>
>
> Using the Linux kernel w/ or w/o TSO I get an iperf3 goodput of 9.5Gbps or 
> 4.5Gbps.
> Using VPP TCP stack I get 9.2Gbps, say max goodput as Linux w/ TSO.
>
> Is there any TSO implementation already in VPP one can take advantage of?
>
> Side question. Is there any crypto offloading service available in VPP?
> Essentially  for the computation of RSA-1024/2048, EDCSA 192/256 signatures.
> 
> Thanks
> Luca
>
> 

Re: [vpp-dev] question about the VCL

[Florin Coras]

Xyxue,

VCL hasn’t yet been updated to work in dgram mode. Try the builtin udp echo 
client/server or tests/vnet/session/udp_echo. Note however that you can’t 
expect udp to deliver all the bytes from one end to the other because of packet 
drops so try half-duplex testing. For some examples see [1].

Florin

[1] https://wiki.fd.io/view/VPP/HostStack/EchoClientServer 


> On May 14, 2018, at 11:59 PM, xyxue  wrote:
> 
> 
> Hi Florin， Ed，
> 
> I'm testing VCL , and the IPPROTO_RAW is a test case .Since it is not 
> supported ,I'm testing the UDP mode:
> 
> server:./vcl_test_server -D 2
> client:./vcl_test_client -D 2.1.1.1 2 
> 
> An assert occure when client startup. More info is shown below:
> DBGvpp# 0: /home/vpp/build-data/../src/vnet/session/session_node.c:214 
> (session_tx_fill_buffer) assertion `n_bytes_read > 0' fails
> 
> Thread 1 "vpp_main" received signal SIGABRT, Aborted.
> 0x75c39428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x75c39428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x75c3b02a in __GI_abort () at abort.c:89
> #2  0x004074de in os_panic () at 
> /home/vpp/build-data/../src/vpp/vnet/main.c:310
> #3  0x764202be in debugger () at 
> /home/vpp/build-data/../src/vppinfra/error.c:84
> #4  0x764206f6 in _clib_error (how_to_die=2, function_name=0x0, 
> line_number=0, fmt=0x774e8b18 "%s:%d (%s) assertion `%s' fails")
> at /home/vpp/build-data/../src/vppinfra/error.c:143
> #5  0x771d2d48 in session_tx_fill_buffer (vm=0x77b8a980 
> , ctx=0x7fffb61e1100, b=0x7ffe87338a80, 
> n_bufs=0x7fffb6aaf996, 
> peek_data=0 '\000') at 
> /home/vpp/build-data/../src/vnet/session/session_node.c:214
> #6  0x771d3e34 in session_tx_fifo_read_and_snd_i (vm=0x77b8a980 
> , node=0x7fffb6bb2900, e=0x7fffb63b1dd0, 
> s=0x7fffb6149c80, n_tx_packets=0x7fffb6aafb4c, peek_data=0 '\000') at 
> /home/vpp/build-data/../src/vnet/session/session_node.c:449
> #7  0x771d4847 in session_tx_fifo_dequeue_and_snd (vm=0x77b8a980 
> , node=0x7fffb6bb2900, e0=0x7fffb63b1dd0, 
> s0=0x7fffb6149c80, n_tx_pkts=0x7fffb6aafb4c) at 
> /home/vpp/build-data/../src/vnet/session/session_node.c:536
> #8  0x771d567c in session_queue_node_fn (vm=0x77b8a980 
> , node=0x7fffb6bb2900, frame=0x0)
> at /home/vpp/build-data/../src/vnet/session/session_node.c:789
> #9  0x778de072 in dispatch_node (vm=0x77b8a980 
> , node=0x7fffb6bb2900, type=VLIB_NODE_TYPE_INPUT, 
> dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x0, 
> last_time_stamp=2385171693806) at /home/vpp/build-data/../src/vlib/main.c:988
> #10 0x778dff5f in vlib_main_or_worker_loop (vm=0x77b8a980 
> , is_main=1) at /home/vpp/build-data/../src/vlib/main.c:1505
> #11 0x778e0a12 in vlib_main_loop (vm=0x77b8a980 
> ) at /home/vpp/build-data/../src/vlib/main.c:1633
> #12 0x778e1438 in vlib_main (vm=0x77b8a980 , 
> input=0x7fffb6aaffb0) at /home/vpp/build-data/../src/vlib/main.c:1787
> #13 0x7794e264 in thread0 (arg=140737349462400) at 
> /home/vpp/build-data/../src/vlib/unix/main.c:568
> #14 0x76445090 in clib_calljmp () at 
> /home/vpp/build-data/../src/vppinfra/longjmp.S:110
> #15 0x7fffd1c0 in ?? ()
> #16 0x7794e6e5 in vlib_unix_main (argc=3, argv=0x7fffe418) at 
> /home/vpp/build-data/../src/vlib/unix/main.c:632
> #17 0x00406f22 in main (argc=3, argv=0x7fffe418) at 
> /home/vpp/build-data/../src/vpp/vnet/main.c:249
> (gdb) 
> 
> Is there anything I can do to fix it?
> 
> Thanks,
> Xyxue
> 
> 

Re: [vpp-dev] How to actively close the client connections in http server? #vnet

[Florin Coras]

That http server is just example code that executes the contents of a get 
request as a cli commands within a spawned vpp process. So, if you want to 
disconnect _after_ the the reply is sent, call vnet_disconnect_session () at 
the end of http_cli_process.

Florin

> On May 17, 2018, at 10:52 PM, muziding  wrote:
> 
> Hi
> 
> I want to make the example of http server  actively close the client 
> connection, instead of waiting for the client to close connection, after http 
> server has responded  to the client request. What should I do?
> 

[vpp-dev] git.fd.io not updating

[Florin Coras]

Hi, 

It would seem that git.fd.io  [1] thinks that we last 
committed a patch to vpp almost 1 week ago. Any idea what might’ve triggered 
this? 

Thanks, 
Florin

[1] https://git.fd.io/vpp/log/ 

Re: [vpp-dev] git.fd.io not updating

[Florin Coras]

We have that already: [FD.io Helpdesk #56282] [linuxfoundation.org #56282]

Florin


> On May 22, 2018, at 8:38 AM, Edward Warnicke <hagb...@gmail.com> wrote:
> 
> Could we get this to a helpdesk ticket to drive to close? :)
> 
> Ed
> 
> On Tue, May 22, 2018 at 9:08 AM Ed Kern <e...@cisco.com 
> <mailto:e...@cisco.com>> wrote:
> well it certainly has…we just need it to accept the new key.
> 
> Ed
> 
> 
>> On May 22, 2018, at 7:42 AM, Thomas F Herbert <therb...@redhat.com 
>> <mailto:therb...@redhat.com>> wrote:
>> 
>> I noticed this with an attempted git pull.
>> 
>> The ECDSA host key for [gerrit.fd.io <http://gerrit.fd.io/>]:29418 has 
>> changed,
>> Surrounded by nasty warnings.
>> 
>> 
>> On 05/22/2018 02:58 AM, Marco Varlese wrote:
>>> Roughly a week ago, I noticed there was a DNS/IP change when cloning a new 
>>> VPP repo... I wonder if what I saw is somehow connected to this issue.
>>> 
>>> On Mon, 2018-05-21 at 16:34 -0700, Florin Coras wrote:
>>>> Hi, 
>>>> 
>>>> It would seem that git.fd.io <http://git.fd.io/> [1] thinks that we last 
>>>> committed a patch to vpp almost 1 week ago. Any idea what might’ve 
>>>> triggered this? 
>>>> 
>>>> Thanks, 
>>>> Florin
>>>> 
>>>> [1] https://git.fd.io/vpp/log/ <https://git.fd.io/vpp/log/>
>>>> 
>>> -- 
>>> Marco V
>>> 
>>> SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton
>>> HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg 
>>> <https://maps.google.com/?q=Maxfeldstr.+5,+D-90409,+N%C3%BCrnberg=gmail=g>
>> -- 
>> Thomas F Herbert 
>> NFV and Fast Data Planes 
>> Networking Group Office of the CTO 
>> Red Hat
> 
> 
> 
> 
> 

Re: [vpp-dev] gerrit.fd.io froblem access

[Florin Coras]

I’m getting in Chrome NET::ERR_CERT_COMMON_NAME_INVALID

And dig says: 

;; ANSWER SECTION:
gerrit.fd.io.   5   IN  CNAME   dev.fd.io.
dev.fd.io.  5   IN  A   162.253.54.31

Florin


> On May 15, 2018, at 2:50 PM, Dave Barach  wrote:
> 
> You might check your DNS result for gerrit.fd.io . 
> Here's what I see, as of a minute ago: 
> 
> $ dig gerrit.fd.io 
> 
> ; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> gerrit.fd.io 
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2545
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 65494
> ;; QUESTION SECTION:
> ;gerrit.fd.io . IN  A
> 
> ;; ANSWER SECTION:
> gerrit.fd.io .  203 IN  CNAME   
> awscloud.fd.io .
> awscloud.fd.io .  7103IN  A   
> 52.10.107.188
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.53#53(127.0.0.53)
> ;; WHEN: Tue May 15 17:48:54 EDT 2018
> ;; MSG SIZE  rcvd: 80
> 
> I see no issue with the certificate being offered by [the above version of] 
> gerrit.fd.io .
> 
> HTH... Dave
> 
> -Original Message-
> From: vpp-dev@lists.fd.io   > On Behalf Of Alexey
> Sent: Tuesday, May 15, 2018 5:17 PM
> To: vpp-dev >
> Subject: [vpp-dev] gerrit.fd.io  froblem access
> 
> The source code repositaries is problem access. 
> 
> 
> Your connection is not secure
> 
> The owner of gerrit.fd.io has configured their website improperly. To protect 
> your information from being stolen, Firefox has not connected to this website.
> 
> This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox 
> may only connect to it securely. As a result, it is not possible to add an 
> exception for this certificate.
> 
> 
> 
> gerrit.fd.io uses an invalid security certificate.
> 
> The certificate is only valid for docs.fd.io
> 
> Error code: SSL_ERROR_BAD_CERT_DOMAIN
> 
> The bypass error is returned blank page.
> 
> 
> 
> 
> 

Re: [vpp-dev] gerrit.fd.io froblem access

[Florin Coras]

Depending on the DNS server, the answer is different … 

$ dig +nocmd +noall +answer gerrit.fd.io
gerrit.fd.io.   5   IN  CNAME   dev.fd.io.
dev.fd.io.  5   IN  A   162.253.54.31
$ dig +nocmd +noall +answer gerrit.fd.io @8.8.8.8
gerrit.fd.io.   5   IN  CNAME   awscloud.fd.io.
awscloud.fd.io. 5   IN  A   52.10.107.188

Florin

> On May 15, 2018, at 3:03 PM, Florin Coras <fcoras.li...@gmail.com> wrote:
> 
> I’m getting in Chrome NET::ERR_CERT_COMMON_NAME_INVALID
> 
> And dig says: 
> 
> ;; ANSWER SECTION:
> gerrit.fd.io <http://gerrit.fd.io/>.  5   IN  CNAME   
> dev.fd.io <http://dev.fd.io/>.
> dev.fd.io <http://dev.fd.io/>.5   IN  A   
> 162.253.54.31
> 
> Florin
> 
> 
>> On May 15, 2018, at 2:50 PM, Dave Barach <dbar...@cisco.com 
>> <mailto:dbar...@cisco.com>> wrote:
>> 
>> You might check your DNS result for gerrit.fd.io <http://gerrit.fd.io/>. 
>> Here's what I see, as of a minute ago: 
>> 
>> $ dig gerrit.fd.io <http://gerrit.fd.io/>
>> 
>> ; <<>> DiG 9.11.3-1ubuntu1-Ubuntu <<>> gerrit.fd.io <http://gerrit.fd.io/>
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2545
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 65494
>> ;; QUESTION SECTION:
>> ;gerrit.fd.io <http://gerrit.fd.io/>.IN  A
>> 
>> ;; ANSWER SECTION:
>> gerrit.fd.io <http://gerrit.fd.io/>. 203 IN  CNAME   
>> awscloud.fd.io <http://awscloud.fd.io/>.
>> awscloud.fd.io <http://awscloud.fd.io/>. 7103IN  A   
>> 52.10.107.188
>> 
>> ;; Query time: 0 msec
>> ;; SERVER: 127.0.0.53#53(127.0.0.53)
>> ;; WHEN: Tue May 15 17:48:54 EDT 2018
>> ;; MSG SIZE  rcvd: 80
>> 
>> I see no issue with the certificate being offered by [the above version of] 
>> gerrit.fd.io <http://gerrit.fd.io/>.
>> 
>> HTH... Dave
>> 
>> -Original Message-
>> From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io 
>> <mailto:vpp-dev@lists.fd.io>> On Behalf Of Alexey
>> Sent: Tuesday, May 15, 2018 5:17 PM
>> To: vpp-dev <vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>>
>> Subject: [vpp-dev] gerrit.fd.io <http://gerrit.fd.io/> froblem access
>> 
>> The source code repositaries is problem access. 
>> 
>> 
>> Your connection is not secure
>> 
>> The owner of gerrit.fd.io <http://gerrit.fd.io/> has configured their 
>> website improperly. To protect your information from being stolen, Firefox 
>> has not connected to this website.
>> 
>> This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox 
>> may only connect to it securely. As a result, it is not possible to add an 
>> exception for this certificate.
>> 
>> 
>> 
>> gerrit.fd.io <http://gerrit.fd.io/> uses an invalid security certificate.
>> 
>> The certificate is only valid for docs.fd.io <http://docs.fd.io/>
>> 
>> Error code: SSL_ERROR_BAD_CERT_DOMAIN
>> 
>> The bypass error is returned blank page.
>> 
>> 
>> 
>> 
> 
> 

Re: [vpp-dev] VLIB_BUFFER_TOTAL_LENGTH_VALID set but invalid total_length_not_including_first_buffer

[Florin Coras]

Hi Yoann, 

Shouldn’t the clone code only read s->total_length_not_including_first_buffer 
only if VLIB_BUFFER_NEXT_PRESENT flag is set for s? I’m thinking about this 
line in particular:

  d->total_length_not_including_first_buffer =
s->total_length_not_including_first_buffer + s->current_length -
head_end_offset;

If you only add s->total_length_not_including_first_buffer if 
VLIB_BUFFER_NEXT_PRESENT is set, do you still see the issue?

Florin


> On May 23, 2018, at 8:13 AM, Yoann Desmouceaux  wrote:
> 
> Hello,
> 
> I noticed that dpdk devices set the VLIB_BUFFER_TOTAL_LENGTH_VALID flag when 
> receiving packets, regardless of the value of 
> total_length_not_including_first_buffer. Since dpdk only copies one cacheline 
> from its vlib_buffer template into the buffer upon receipt of a packet, 
> b->total_length_not_including_first_buffer is left unitialized (because it's 
> in the second cacheline). 
> 
> In most cases, this doesn't cause issues — for non-chained buffers the 
> vlib_buffer_length_in_chain() function will still return the correct value 
> because it only looks at b->current_length. 
> 
> However, if the buffer is later vlib_buffer_clone()d, the stale 
> total_length_not_including_first_buffer value will propagate to the new head 
> of the chain, for which vlib_buffer_length_in_chain() will now return a wrong 
> value. This can be observed for instance when using BIER, with which 
> replicated packets will sometimes have oversized lengths.
> 
> An obvious fix for that is to remove the VLIB_BUFFER_TOTAL_LENGTH_VALID flag 
> from the buffer_flags_template in dpdk_init(). I'm concerned about the 
> performance of this approach though, because vlib_buffer_length_in_chain() 
> will then have to go through the slow path for all chained packets, causing 
> branches. The other solution would be to, in addition, add something along 
> the lines of the following in dpdk_process_rx_burst():
>   b[0]->flags |= (!b[0]->total_length_not_including_first_buffer) << 
> VLIB_BUFFER_LOG2_TOTAL_LENGTH_VALID;
> so as to set the flag in correct packets as early as possible. 
> This would be branchless code, but would cost a few cycles for every packet 
> received by dpdk. Any thoughts?
> 
> Also, does anyone know if this can happen with other devices than dpdk?
> 
> Best,
> Yoann
> 

Re: [vpp-dev] [FD.io Helpdesk #56282] git.fd.io not updating

[Florin Coras]

It is! Thank you, Vanessa!

Florin

> On May 22, 2018, at 11:41 AM, Vanessa Valderrama via RT 
> <fdio-helpd...@rt.linuxfoundation.org> wrote:
> 
> This issue should be resolved.
> 
> Thank you,
> Vanessa
> 
> On Tue May 22 02:59:02 2018, mvarl...@suse.de wrote:
>> Roughly a week ago, I noticed there was a DNS/IP change when cloning a
>> new VPP
>> repo... I wonder if what I saw is somehow connected to this issue.
>> On Mon, 2018-05-21 at 16:34 -0700, Florin Coras wrote:
>>> Hi,
>>> It would seem that git.fd.io [1] thinks that we last committed a
>>> patch to vpp
>>> almost 1 week ago. Any idea what might’ve triggered this?
>>> Thanks, Florin
>>> [1] https://git.fd.io/vpp/log/
>>> 
>>> 
>>> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links:

You receive all messages sent to this group.

View/Reply Online (#9353): https://lists.fd.io/g/vpp-dev/message/9353
View All Messages In Topic (1): https://lists.fd.io/g/vpp-dev/topic/19743812
Mute This Topic: https://lists.fd.io/mt/19743812/21656
New Topic: https://lists.fd.io/g/vpp-dev/post

Change Your Subscription: https://lists.fd.io/g/vpp-dev/editsub/21656
Group Home: https://lists.fd.io/g/vpp-dev
Contact Group Owner: vpp-dev+ow...@lists.fd.io
Terms of Service: https://lists.fd.io/static/tos
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Is there a plan to support the udp mode in vcl?

[Florin Coras]

Xyxue, 

It’s on our todo list. In the mean time, you can use the raw session layer 
apis. For examples see src/tests/vnet/session/udp_echo.c

Florin


> On May 21, 2018, at 11:08 PM, xyxue  wrote:
> 
> Hi Florin， Ed，
> 
> I'm testing the vcl in udp mode. After our debug  vpp can receive the udp 
> packets , but the packets will be dropped . Trace info is shown below:
> 
> Packet 1 
> 
> 01:46:56:707843: af-packet-input 
> af_packet: hw_if_index 1 next-index 4 
> tpacket2_hdr: 
> status 0x81 len 106 snaplen 106 mac 66 net 80 
> sec 0x5b03780d nsec 0x3498f0be vlan 0 vlan_tpid 0 
> 01:47:04:449319: ethernet-input 
> IP4: 02:fe:3f:8d:97:a4 -> 02:fe:6e:ca:46:82 
> 01:47:04:449340: ip4-input 
> UDP: 2.1.1.1 -> 2.1.1.2 
> tos 0x00, ttl 255, length 92, checksum 0x758c 
> fragment id 0x, flags DONT_FRAGMENT 
> UDP: 3536 -> 2111 
> length 72, checksum 0x8106 
> 01:47:04:449349: ip4-lookup 
> fib 0 dpo-idx 7 flow hash: 0x 
> UDP: 2.1.1.1 -> 2.1.1.2 
> tos 0x00, ttl 255, length 92, checksum 0x758c 
> fragment id 0x, flags DONT_FRAGMENT 
> UDP: 3536 -> 2111 
> length 72, checksum 0x8106 
> 01:47:04:449360: ip4-local 
> UDP: 2.1.1.1 -> 2.1.1.2 
> tos 0x00, ttl 255, length 92, checksum 0x758c 
> fragment id 0x, flags DONT_FRAGMENT 
> UDP: 3536 -> 2111 
> length 72, checksum 0x8106 
> 01:47:04:449367: ip4-udp-lookup 
> UDP: src-port 3536 dst-port 2111 
> 01:47:04:449379: udp4-input 
> UDP_INPUT: connection 0, disposition 4, thread 0 
> 01:47:04:449415: error-drop 
> udp4-input: UDP packets enqueued 
> 
> Is there a plan to support the udp mode in vcl?
> 
> Thanks,
> Xyxue
> 

Re: [vpp-dev] segfault due to movaps unaligned access

[Florin Coras]

Hi Radu, 

The problem was that the vector was expected to have cacheline size aligned 
data, but the elements in the vector were not a multiple of a cache line (size 
was 54). As a result, the first element was aligned and the rest were not. The 
vector infra just allocates an aligned chunk of memory, it does not guarantee 
anything with respect to individual element placement.

Hope it helps!

Cheers,
Florin

> On Apr 26, 2018, at 1:53 AM, Nicolau, Radu <radu.nico...@intel.com> wrote:
> 
> Hi Florin,
>
> Thanks! The patch fixes the issue.
> Any idea why is it happening?
>
> Regards,
> Radu
>   <>
>  <>From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>] On Behalf Of Florin 
> Coras
> Sent: Tuesday, April 24, 2018 11:25 PM
> To: Nicolau, Radu <radu.nico...@intel.com <mailto:radu.nico...@intel.com>>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Radu, 
>
> Making the crypto_worker_main_t a full cache line in size (see patch [1]) 
> seems to solve the issue. Could you confirm?
>
> Florin
>
> [1] https://gerrit.fd.io/r/#/c/12086/ <https://gerrit.fd.io/r/#/c/12086/>
> 
> 
> On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com 
> <mailto:radu.nico...@intel.com>> wrote:
>
> Hello all,
>
> We’re seeing a weird issue, that is a segfault that looks to be caused by a 
> movaps instruction that is trying to access an address that is not 16 byte 
> aligned.
> The call originates from a vec_validate_init_empty_aligned that has the 
> argument aligned to 16 bytes.
> I have seen something like this in the past, we couldn’t find a root cause 
> and considered it a GCC bug (version 5 then), but now it pops up again on 
> version 7, so probably it isn’t.
> Any idea? A snapshot of the gdb screen below.
>
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> https://postimg.cc/image/9jy4p38at/ <https://postimg.cc/image/9jy4p38at/>
>
> thanks and I will appreciate any help,
> Radu
>
> 

Re: [vpp-dev] segfault due to movaps unaligned access

[Florin Coras]

Yup, it surely seems so. 

Florin

> On Apr 26, 2018, at 8:40 AM, Nicolau, Radu <radu.nico...@intel.com> wrote:
> 
> Hi,
>
> If elements of the vector are 54 bytes and first is aligned, accessing the 
> second one should not generate instructions that assume it is aligned as 
> well. So based on that and your description, this is a gcc bug, right? The 
> issue does not occur on gcc 6.3, 6.4 but occurs on 7.2.0 and 7.3.1 (and I’ve 
> seen it a while ago on 5.x).
>   <>
> Regards,
> Radu
>  <>From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>] On Behalf Of Florin 
> Coras
> Sent: Thursday, April 26, 2018 4:13 PM
> To: Nicolau, Radu <radu.nico...@intel.com <mailto:radu.nico...@intel.com>>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Radu, 
>
> The problem was that the vector was expected to have cacheline size aligned 
> data, but the elements in the vector were not a multiple of a cache line 
> (size was 54). As a result, the first element was aligned and the rest were 
> not. The vector infra just allocates an aligned chunk of memory, it does not 
> guarantee anything with respect to individual element placement.
>
> Hope it helps!
>
> Cheers,
> Florin
> 
> 
> On Apr 26, 2018, at 1:53 AM, Nicolau, Radu <radu.nico...@intel.com 
> <mailto:radu.nico...@intel.com>> wrote:
>
> Hi Florin,
>
> Thanks! The patch fixes the issue.
> Any idea why is it happening?
>
> Regards,
> Radu
>
> From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>] On Behalf Of Florin 
> Coras
> Sent: Tuesday, April 24, 2018 11:25 PM
> To: Nicolau, Radu <radu.nico...@intel.com <mailto:radu.nico...@intel.com>>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Radu, 
>
> Making the crypto_worker_main_t a full cache line in size (see patch [1]) 
> seems to solve the issue. Could you confirm?
>
> Florin
>
> [1] https://gerrit.fd.io/r/#/c/12086/ <https://gerrit.fd.io/r/#/c/12086/>
> 
> 
> 
> On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com 
> <mailto:radu.nico...@intel.com>> wrote:
>
> Hello all,
>
> We’re seeing a weird issue, that is a segfault that looks to be caused by a 
> movaps instruction that is trying to access an address that is not 16 byte 
> aligned.
> The call originates from a vec_validate_init_empty_aligned that has the 
> argument aligned to 16 bytes.
> I have seen something like this in the past, we couldn’t find a root cause 
> and considered it a GCC bug (version 5 then), but now it pops up again on 
> version 7, so probably it isn’t.
> Any idea? A snapshot of the gdb screen below.
>
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> https://postimg.cc/image/9jy4p38at/ <https://postimg.cc/image/9jy4p38at/>
>
> thanks and I will appreciate any help,
> Radu
>
>
> 

[vpp-dev] VPP 17.10 Released

[Florin Coras]

Dear VPP community, 

The VPP 17.10 release is complete. The release artefacts are now available on 
the nexus server and the repos have been updated.

I’d like to take this opportunity to thank you all for your continued support 
for VPP.

Regards,
Florin
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] compilation issue on branch origin/stable/1710

[Florin Coras]

Hi Shachar, 

Did you try cleaning the workspace? If not, from build-root try:

make distclean
./bootstrap.sh

and build again.

HTH,
Florin

> On Oct 22, 2017, at 11:58 PM, Shachar Beiser  wrote:
> 
> Hi ,
>  
>  I see a compilation issue while working on origin/stable/1710 .
>   
>   -Shachar Beiser
>  
>  
>  
> In file included from 
> /home/ubuntu/vpp.shacharbe/build-data/../src/vpp-api/java/jvpp-core/jvpp_core.c:47:0:
> jvpp-core/jvpp_core_gen.h: In function 
> ‘Java_io_fd_vpp_jvpp_core_JVppCoreImpl_geneveAddDelTunnel0’:
> jvpp-core/jvpp_core_gen.h:16032:5: error: unknown type name 
> ‘vl_api_geneve_add_del_tunnel_t’
>  vl_api_geneve_add_del_tunnel_t * mp;
>  ^
> jvpp-core/jvpp_core_gen.h:16066:7: error: request for member ‘_vl_msg_id’ in 
> something not a structure or union
>  mp->_vl_msg_id = ntohs (get_message_id(env, 
> "geneve_add_del_tunnel_7a0f7fcb"));
>^
> In file included from 
> /home/ubuntu/vpp.shacharbe/build-data/../src/vpp-api/java/jvpp-core/jvpp_core.c:47:0:
> jvpp-core/jvpp_core_gen.h:16067:7: error: request for member ‘client_index’ 
> in something not a structure or union
>  mp->client_index = plugin_main->my_client_index;
>^
> jvpp-core/jvpp_core_gen.h:16068:7: error: request for member ‘context’ in 
> something not a structure or union
>  mp->context = clib_host_to_net_u32 (my_context_id);
>^
> jvpp-core/jvpp_core_gen.h:16071:7: error: request for member ‘is_add’ in 
> something not a structure or union
>  mp->is_add = isAdd;
>^
> jvpp-core/jvpp_core_gen.h:16072:7: error: request for member ‘is_ipv6’ in 
> something not a structure or union
>  mp->is_ipv6 = isIpv6;
>^
> jvpp-core/jvpp_core_gen.h:16078:74: error: request for member ‘local_address’ 
> in something not a structure or union
>  (*env)->GetByteArrayRegion(env, localAddress, 0, cnt, (jbyte 
> *)mp->local_address);
>   ^
> jvpp-core/jvpp_core_gen.h:16086:75: error: request for member 
> ‘remote_address’ in something not a structure or union
>  (*env)->GetByteArrayRegion(env, remoteAddress, 0, cnt, (jbyte 
> *)mp->remote_address);
>^
> jvpp-core/jvpp_core_gen.h:16089:7: error: request for member 
> ‘mcast_sw_if_index’ in something not a structure or union
>  mp->mcast_sw_if_index = clib_host_to_net_u32(mcastSwIfIndex);
>^
> jvpp-core/jvpp_core_gen.h:16090:7: error: request for member ‘encap_vrf_id’ 
> in something not a structure or union
>  mp->encap_vrf_id = clib_host_to_net_u32(encapVrfId);
>^
> jvpp-core/jvpp_core_gen.h:16091:7: error: request for member 
> ‘decap_next_index’ in something not a structure or union
>  mp->decap_next_index = clib_host_to_net_u32(decapNextIndex);
>^
> jvpp-core/jvpp_core_gen.h:16092:7: error: request for member ‘vni’ in 
> something not a structure or union
>  mp->vni = clib_host_to_net_u32(vni);
>^
> In file included from 
> /home/ubuntu/vpp.shacharbe/build-data/../src/vpp-api/java/jvpp-core/jvpp_core.c:47:0:
> jvpp-core/jvpp_core_gen.h: In function 
> ‘Java_io_fd_vpp_jvpp_core_JVppCoreImpl_geneveTunnelDump0’:
> jvpp-core/jvpp_core_gen.h:16116:5: error: unknown type name 
> ‘vl_api_geneve_tunnel_dump_t’
>  vl_api_geneve_tunnel_dump_t * mp;
>  ^
> jvpp-core/jvpp_core_gen.h:16129:7: error: request for member ‘_vl_msg_id’ in 
> something not a structure or union
>  mp->_vl_msg_id = ntohs (get_message_id(env, 
> "geneve_tunnel_dump_5dc96241"));
>^
> In file included from 
> /home/ubuntu/vpp.shacharbe/build-data/../src/vpp-api/java/jvpp-core/jvpp_core.c:47:0:
> jvpp-core/jvpp_core_gen.h:16130:7: error: request for member ‘client_index’ 
> in something not a structure or union
>  mp->client_index = plugin_main->my_client_index;
>^
> jvpp-core/jvpp_core_gen.h:16131:7: error: request for member ‘context’ in 
> something not a structure or union
>  mp->context = clib_host_to_net_u32 (my_context_id);
>^
> jvpp-core/jvpp_core_gen.h:16134:7: error: request for member ‘sw_if_index’ in 
> something not a structure or union
>  mp->sw_if_index = clib_host_to_net_u32(swIfIndex);
>^
> In file included from 
> /home/ubuntu/vpp.shacharbe/build-data/../src/vpp-api/java/jvpp-core/jvpp_core.c:47:0:
> jvpp-core/jvpp_core_gen.h: In function 
> ‘Java_io_fd_vpp_jvpp_core_JVppCoreImpl_swInterfaceSetGeneveBypass0’:
> jvpp-core/jvpp_core_gen.h:16158:5: error: unknown type name 
> ‘vl_api_sw_interface_set_geneve_bypass_t’
>  vl_api_sw_interface_set_geneve_bypass_t * mp;
>  ^
> jvpp-core/jvpp_core_gen.h:16177:7: error: request for member ‘_vl_msg_id’ in 
> something not a structure or union
>  mp->_vl_msg_id = ntohs (get_message_id(env, 
> "sw_interface_set_geneve_bypass_b1f82cba"));
>^
> In file