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

2017-11-09 Thread Florin Coras

> On Nov 9, 2017, at 2:51 PM, Jon Loeliger  wrote:
> 
> On Thu, Nov 9, 2017 at 4:29 PM, Florin Coras  > 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] Missing udp.api.h header file?

2017-11-09 Thread Jon Loeliger
On Thu, Nov 9, 2017 at 4:29 PM, Florin Coras  wrote:

> Hi Jon,
>
> This dates back to a couple of days ago.
>

Hey, I don't pull *every* day... :-)


> Fix is on the way …
>
> Florin
>

Thank you!

jdl
___
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?

2017-11-09 Thread 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  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 >
> Date:   Thu Nov 9 10:05:42 2017 -0800
> 
> session: fix app index in unbind
> 
> Change-Id: Iff1a665b6cf9ca2def0fcdacf02d7f8c579c0f4e
> Signed-off-by: Florin Coras  >
> 
> 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

[vpp-dev] FW: Coverity build failed with 18 errors

2017-11-09 Thread Chris Luke
FYI, Coverity has just failed to build because of issues in BIER (and maybe
VOM); some of these may have existed a while, because these all seem to be
warnings and Coverity fails a build based on number of rejected build units
exceeding a % threshold. Likely BIER was merged and triggered the threshold.

I note that BIER is using C99 stdint types; Coverity appears to be fussy
about how these get defined (missing include?); also we agreed here on this
list just a few weeks ago that VPP uses its own typedefs for specified-width
integers (u64 etc) so we should not be using such C99 types anyway.

For those interested, the Coverity build log is available at
https://vpp.flirble.org/coverity/20171109/build-log.txt though please don't
ask me to interpret it!

Chris.

-Original Message-
From: VPP [mailto:v...@brae.flirble.org] 
Sent: Thursday, November 9, 2017 15:29
To: chr...@flirble.org
Subject: Coverity build failed with 18 errors

Coverity build failed with 18 errors.

Latest commit: v18.01-rc0-251-g75e974b

Error counts from cov-int/build-log.txt:
84205:[ERROR] [104291] EXECUTING: /bin/sed s|:*$||
84459:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/fib/fib_path.c".
91374:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask.c".
91462:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask_db.c".
91532:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_entry.c".
91700:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_output.c".
91775:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_table.c".
91828:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_lookup.c".
91840:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask.c".
91847:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_fmask_db.c".
91954:[ERROR] 5 errors detected in the compilation of
"../../../src/vnet/bier/bier_types.c".
91982:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_entry.c".
92104:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_output.c".
92160:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_table.c".
92396:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_lookup.c".
92796:[ERROR] 5 errors detected in the compilation of
"../../../src/vnet/bier/bier_types.c".
93191:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_test.c".
93644:[ERROR] 1 error detected in the compilation of
"../../../src/vnet/bier/bier_test.c".

Probable error information from the compiler:
84180:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_fmas
k.h",
84181-  line 57: error #20: identifier "uint32_t" is undefined
84182-  uint32_t bfmb_count;
84183-  ^
--
84428:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_fmas
k.h",
84429-  line 57: error #20: identifier "uint32_t" is undefined
84430-  uint32_t bfmb_count;
84431-  ^
--
87392:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87393-  .h", line 56: warning #20: identifier "uint16_t" is
undefined
87394-  uint16_t index;
87395-  ^
--
87397:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87398-  .h", line 72: warning #20: identifier "uint16_t" is
undefined
87399-  uint16_t index;
87400-  ^
--
87402:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87403-  .h", line 87: warning #20: identifier "uint16_t" is
undefined
87404-  uint16_t index;
87405-  ^
--
87423:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87424-  .h", line 54: warning #1563: function
"bier_bit_string_is_zero" not
87425-  emitted, consider modeling it or review parse diagnostics to
improve
87426-  fidelity
--
87430:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87431-  .h", line 69: warning #1563: function
"bier_bit_string_clear_string"
87432-  not emitted, consider modeling it or review parse
diagnostics to
87433-  improve fidelity
--
87437:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_
string
87438-  .h", line 84: warning #1563: function
87439-  "bier_bit_string_logical_and_string" not emitted, consider
modeling
87440-  it or review parse diagnostics to improve fidelity
--
87868:"/home/vpp/dev/fdio/coverit

[vpp-dev] FW: Coverity build failed with 18 errors

2017-11-09 Thread Luke, Chris
Doh. Repost. I sent the original from the wrong account. 

(mods, pls ignore the one held for moderation!)

-Original Message-
From: Chris Luke [mailto:chr...@flirble.org] 
Sent: Thursday, November 9, 2017 16:06
To: 'vpp-dev@lists.fd.io' <vpp-dev@lists.fd.io>
Subject: FW: Coverity build failed with 18 errors

FYI, Coverity has just failed to build because of issues in BIER (and maybe 
VOM); some of these may have existed a while, because these all seem to be 
warnings and Coverity fails a build based on number of rejected build units 
exceeding a % threshold. Likely BIER was merged and triggered the threshold.

I note that BIER is using C99 stdint types; Coverity appears to be fussy about 
how these get defined (missing include?); also we agreed here on this list just 
a few weeks ago that VPP uses its own typedefs for specified-width integers 
(u64 etc) so we should not be using such C99 types anyway.

For those interested, the Coverity build log is available at 
https://vpp.flirble.org/coverity/20171109/build-log.txt though please don't ask 
me to interpret it!

Chris.

-Original Message-
From: VPP [mailto:v...@brae.flirble.org] 
Sent: Thursday, November 9, 2017 15:29
To: mailto:chr...@flirble.org
Subject: Coverity build failed with 18 errors

Coverity build failed with 18 errors.

Latest commit: v18.01-rc0-251-g75e974b

Error counts from cov-int/build-log.txt:
84205:[ERROR] [104291] EXECUTING: /bin/sed s|:*$||
84459:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/fib/fib_path.c".
91374:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_fmask.c".
91462:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_fmask_db.c".
91532:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_entry.c".
91700:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_output.c".
91775:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_table.c".
91828:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_lookup.c".
91840:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_fmask.c".
91847:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_fmask_db.c".
91954:[ERROR] 5 errors detected in the compilation of 
"../../../src/vnet/bier/bier_types.c".
91982:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_entry.c".
92104:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_output.c".
92160:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_table.c".
92396:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_lookup.c".
92796:[ERROR] 5 errors detected in the compilation of 
"../../../src/vnet/bier/bier_types.c".
93191:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_test.c".
93644:[ERROR] 1 error detected in the compilation of 
"../../../src/vnet/bier/bier_test.c".

Probable error information from the compiler:
84180:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_fmask.h",
84181-  line 57: error #20: identifier "uint32_t" is undefined
84182-  uint32_t bfmb_count;
84183-  ^
--
84428:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_fmask.h",
84429-  line 57: error #20: identifier "uint32_t" is undefined
84430-  uint32_t bfmb_count;
84431-  ^
--
87392:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_string
87393-  .h", line 56: warning #20: identifier "uint16_t" is undefined
87394-  uint16_t index;
87395-  ^
--
87397:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_string
87398-  .h", line 72: warning #20: identifier "uint16_t" is undefined
87399-  uint16_t index;
87400-  ^
--
87402:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_string
87403-  .h", line 87: warning #20: identifier "uint16_t" is undefined
87404-  uint16_t index;
87405-  ^
--
87423:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_string
87424-  .h", line 54: warning #1563: function "bier_bit_string_is_zero" 
not
87425-  emitted, consider modeling it or review parse diagnostics to 
improve
87426-  fidelity
--
87430:"/home/vpp/dev/fdio/coverity/vpp/build-data/../src/vnet/bier/bier_bit_string
87431-  .h", line 69: warning #1563: function 
"bier_bit_string_clear_string"
87432-  not emitted, consider modeling it or review parse diagnostics to
87433-  improve fidelity
--
8

Re: [vpp-dev] dpdk external

2017-11-09 Thread Marco Varlese
Dear Beiser,
I currently build (and actually create a package for SUSE distro) for VPP 17.10
compiling against a shared DPDK installation without any issues.
First of all, I apply the below patch:--- build-data/platforms/vpp.mk.old   
2017-08-21 16:05:45.202038250 +0200+++ build-data/platforms/vpp.mk  2017-
08-21 16:05:59.794798235 +0200@@ -40,10 +40,10 @@  # DPDK configuration
parameters # vpp_uses_dpdk_mlx5_pmd = yes-# vpp_uses_external_dpdk = yes-#
vpp_dpdk_inc_dir = /usr/include/dpdk-# vpp_dpdk_lib_dir = /usr/lib-#
vpp_dpdk_shared_lib = yes+vpp_uses_external_dpdk = yes+vpp_dpdk_inc_dir =
/usr/include/dpdk+vpp_dpdk_lib_dir = /usr/lib+vpp_dpdk_shared_lib = yes  # load
balancer plugin is not portable on 32 bit platform ifeq ($(MACHINE),i686)
After doing that, the steps I follow are pretty straight forward:$ make V=1
bootstrap$ make V=1 build-release
Can you try the above?
Cheers,Marco
On Thu, 2017-11-09 at 15:10 +, Shachar Beiser wrote:
> Hi ,
>   I am trying to compile with DPDK external . it fails to compile.
>  
>  -Shachar Beiser
> 
>  
> Both on master branch and on origin/stable/1710 the following procedure is not
> working
> --
> --
> export CFLAGS="-g -DFORTIFY_SOURCE=2 -fstack-protector -fPIC
> -march=sandybridge -O2 -I/home/ubuntu/dpdk.org/x86_64-native-linuxapp-
> gcc/include  -L/home/ubuntu/dpdk.org/x86_64-native-linuxapp-gcc/lib"
> sudo autoreconf -fis
> sudo ./configure -disable-japi
> sudo make -j32
>  
> Failure
> 
>  
> CC   vnet/interface_cli.lo
> (null):48 syntax error
> Makefile:8077: recipe for target 'vnet/geneve/geneve.api.h' failed
> make[2]: *** [vnet/geneve/geneve.api.h] Error 1
> make[2]: *** Waiting for unfinished jobs
>   CC   vnet/interface_format.lo
> (null):48 syntax error
> Makefile:8077: recipe for target 'vnet/dns/dns.api.h' failed
> make[2]: *** [vnet/dns/dns.api.h] Error 1
> make[2]: Leaving directory '/home/ubuntu/vpp.bin/src'
> Makefile:7068: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/home/ubuntu/vpp.bin/src'
> Makefile:3597: recipe for target 'all' failed
> make: *** [all] Error 2
>  
>  
>  
>  
> 
> 
> 
> 
> ___
> 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] dpdk external

2017-11-09 Thread Shachar Beiser
Hi ,
  I am trying to compile with DPDK external . it fails to compile.

 -Shachar Beiser

Both on master branch and on origin/stable/1710 the following procedure is not 
working

export CFLAGS="-g -DFORTIFY_SOURCE=2 -fstack-protector -fPIC -march=sandybridge 
-O2 -I/home/ubuntu/dpdk.org/x86_64-native-linuxapp-gcc/include  
-L/home/ubuntu/dpdk.org/x86_64-native-linuxapp-gcc/lib"
sudo autoreconf -fis
sudo ./configure -disable-japi
sudo make -j32

Failure


CC   vnet/interface_cli.lo
(null):48 syntax error
Makefile:8077: recipe for target 'vnet/geneve/geneve.api.h' failed
make[2]: *** [vnet/geneve/geneve.api.h] Error 1
make[2]: *** Waiting for unfinished jobs
  CC   vnet/interface_format.lo
(null):48 syntax error
Makefile:8077: recipe for target 'vnet/dns/dns.api.h' failed
make[2]: *** [vnet/dns/dns.api.h] Error 1
make[2]: Leaving directory '/home/ubuntu/vpp.bin/src'
Makefile:7068: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/ubuntu/vpp.bin/src'
Makefile:3597: recipe for target 'all' failed
make: *** [all] Error 2




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

Re: [vpp-dev] [FD.io Helpdesk #47942] Re: Merge jobs faiing

2017-11-09 Thread lorand.jakab+f...@gmail.com via RT
Thanks!

On Thu, Nov 9, 2017 at 3:48 PM, Ed Warnicke  wrote:

> https://gerrit.fd.io/r/#/c/9329/ fixed it.
>
> Ed
>
> On Wed, Nov 8, 2017 at 3:39 PM Vanessa Valderrama via RT <
> fdio-helpd...@rt.linuxfoundation.org> wrote:
>
>> Change https://gerrit.fd.io/r/#/c/9327/ was submitted and merged to
>> resolve this issue but the builds are still failing with the same error.
>>
>> On Wed Nov 08 10:16:01 2017, hagbard wrote:
>> > So the more interesting question is... why are we building the vpp-
>> > dpdk-dev
>> > package at all given that the version in nexus matches the version in
>> > the
>> > repo which means we should simply be installing it from the repo
>> > rather
>> > than building it...
>> >
>> > Ed
>> >
>> > On Wed, Nov 8, 2017 at 7:52 AM Vanessa Valderrama via RT <
>> > fdio-helpd...@rt.linuxfoundation.org> wrote:
>> >
>> > > This error typically occurs when an artifact that already exists is
>> > > trying
>> > > to be deployed.  Would you like to remove the artifacts that were
>> > > deployed
>> > > on 10/10? I believe that will resolve this error.
>> > >
>> > > vpp-dpdk-dev-17.08-vpp2_amd64-deb.deb
>> > >
>> > > Thank you,
>> > > Vanessa
>> > >
>> > > On Wed Nov 08 08:49:28 2017, hagbard wrote:
>> > > > This appears to be something going wrong pushing to the nexus
>> > > > server... it
>> > > > looks like the nexus server is rejecting the push, from:
>> > > >
>> > > > https://jenkins.fd.io/view/vpp/job/vpp-merge-master-
>> > > > ubuntu1604/3174/consoleFull
>> > > >
>> > > > 13:07:08 [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]
>> > > > 13:07:08 [ERROR]
>> > > > 13:07:08 [ERROR] To see the full stack trace of the errors, re-run
>> > > > Maven
>> > > > with the -e switch.
>> > > > 13:07:08 [ERROR] Re-run Maven using the -X switch to enable full
>> > > > debug
>> > > > logging.
>> > > > 13:07:08 [ERROR]
>> > > > 13:07:08 [ERROR] For more information about the errors and possible
>> > > > solutions, please read the following articles:
>> > > > 13:07:08 [ERROR] [Help 1]
>> > > > http://cwiki.apache.org/confluence/display/MAVEN/
>> MojoExecutionException
>> > > > 13:07:08 Build step 'Execute shell' marked build as failure
>> > > >
>> > > >
>> > > > On Tue, Nov 7, 2017 at 11:50 PM Lori Jakab
>> > > > 
>> > > > wrote:
>> > > >
>> > > > > Hello,
>> > > > >
>> > > > > Any update on this? We can't get the latest patches via the
>> > > > > Ubuntu
>> > > > > package
>> > > > > manager and that hurts certain test scenarios.
>> > > > >
>> > > > > -Lori
>> > > > >
>> > > > >
>> > > > > On Mon, Nov 6, 2017 at 6:31 PM, Ed Warnicke 
>> > > > > wrote:
>> > > > >
>> > > > >> This looks like we are hitting the limit on storage at
>> > > > >> packagecloud.
>> > > > >>
>> > > > >> I've manually trimmed some old packages, but we really really
>> > > > >> need
>> > > > >> to get
>> > > > >> the script going that autotrims for us.
>> > > > >>
>> > > > >> Vanessa,
>> > > > >>
>> > > > >> How are we doing on that?
>> > > > >>
>> > > > >> Ed
>> > > > >>
>> > > > >> On Mon, Nov 6, 2017 at 9:17 AM Luke, Chris
>> > > > >> 
>> > > > >> wrote:
>> > > > >>
>> > > > >>> The post-merge jobs are failing with errors like this:
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> *16:04:05* [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]
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> (from
>> > > > >>> https://jenkins.fd.io/job/vpp-merge-master-
>> > > > >>> ubuntu1604/3148/consoleFull)
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> This is sufficiently voodoo for me to not 

Re: [vpp-dev] [FD.io Helpdesk #47942] Re: Merge jobs faiing

2017-11-09 Thread Lori Jakab
Thanks!

On Thu, Nov 9, 2017 at 3:48 PM, Ed Warnicke  wrote:

> https://gerrit.fd.io/r/#/c/9329/ fixed it.
>
> Ed
>
> On Wed, Nov 8, 2017 at 3:39 PM Vanessa Valderrama via RT <
> fdio-helpd...@rt.linuxfoundation.org> wrote:
>
>> Change https://gerrit.fd.io/r/#/c/9327/ was submitted and merged to
>> resolve this issue but the builds are still failing with the same error.
>>
>> On Wed Nov 08 10:16:01 2017, hagbard wrote:
>> > So the more interesting question is... why are we building the vpp-
>> > dpdk-dev
>> > package at all given that the version in nexus matches the version in
>> > the
>> > repo which means we should simply be installing it from the repo
>> > rather
>> > than building it...
>> >
>> > Ed
>> >
>> > On Wed, Nov 8, 2017 at 7:52 AM Vanessa Valderrama via RT <
>> > fdio-helpd...@rt.linuxfoundation.org> wrote:
>> >
>> > > This error typically occurs when an artifact that already exists is
>> > > trying
>> > > to be deployed.  Would you like to remove the artifacts that were
>> > > deployed
>> > > on 10/10? I believe that will resolve this error.
>> > >
>> > > vpp-dpdk-dev-17.08-vpp2_amd64-deb.deb
>> > >
>> > > Thank you,
>> > > Vanessa
>> > >
>> > > On Wed Nov 08 08:49:28 2017, hagbard wrote:
>> > > > This appears to be something going wrong pushing to the nexus
>> > > > server... it
>> > > > looks like the nexus server is rejecting the push, from:
>> > > >
>> > > > https://jenkins.fd.io/view/vpp/job/vpp-merge-master-
>> > > > ubuntu1604/3174/consoleFull
>> > > >
>> > > > 13:07:08 [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]
>> > > > 13:07:08 [ERROR]
>> > > > 13:07:08 [ERROR] To see the full stack trace of the errors, re-run
>> > > > Maven
>> > > > with the -e switch.
>> > > > 13:07:08 [ERROR] Re-run Maven using the -X switch to enable full
>> > > > debug
>> > > > logging.
>> > > > 13:07:08 [ERROR]
>> > > > 13:07:08 [ERROR] For more information about the errors and possible
>> > > > solutions, please read the following articles:
>> > > > 13:07:08 [ERROR] [Help 1]
>> > > > http://cwiki.apache.org/confluence/display/MAVEN/
>> MojoExecutionException
>> > > > 13:07:08 Build step 'Execute shell' marked build as failure
>> > > >
>> > > >
>> > > > On Tue, Nov 7, 2017 at 11:50 PM Lori Jakab
>> > > > 
>> > > > wrote:
>> > > >
>> > > > > Hello,
>> > > > >
>> > > > > Any update on this? We can't get the latest patches via the
>> > > > > Ubuntu
>> > > > > package
>> > > > > manager and that hurts certain test scenarios.
>> > > > >
>> > > > > -Lori
>> > > > >
>> > > > >
>> > > > > On Mon, Nov 6, 2017 at 6:31 PM, Ed Warnicke 
>> > > > > wrote:
>> > > > >
>> > > > >> This looks like we are hitting the limit on storage at
>> > > > >> packagecloud.
>> > > > >>
>> > > > >> I've manually trimmed some old packages, but we really really
>> > > > >> need
>> > > > >> to get
>> > > > >> the script going that autotrims for us.
>> > > > >>
>> > > > >> Vanessa,
>> > > > >>
>> > > > >> How are we doing on that?
>> > > > >>
>> > > > >> Ed
>> > > > >>
>> > > > >> On Mon, Nov 6, 2017 at 9:17 AM Luke, Chris
>> > > > >> 
>> > > > >> wrote:
>> > > > >>
>> > > > >>> The post-merge jobs are failing with errors like this:
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> *16:04:05* [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]
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> (from
>> > > > >>> https://jenkins.fd.io/job/vpp-merge-master-
>> > > > >>> ubuntu1604/3148/consoleFull)
>> > > > >>>
>> > > > >>>
>> > > > >>>
>> > > > >>> This is sufficiently voodoo for me to not 

Re: [vpp-dev] [FD.io Helpdesk #47942] Re: Merge jobs faiing

2017-11-09 Thread Ed Warnicke via RT
https://gerrit.fd.io/r/#/c/9329/ fixed it.

Ed

On Wed, Nov 8, 2017 at 3:39 PM Vanessa Valderrama via RT <
fdio-helpd...@rt.linuxfoundation.org> wrote:

> Change https://gerrit.fd.io/r/#/c/9327/ was submitted and merged to
> resolve this issue but the builds are still failing with the same error.
>
> On Wed Nov 08 10:16:01 2017, hagbard wrote:
> > So the more interesting question is... why are we building the vpp-
> > dpdk-dev
> > package at all given that the version in nexus matches the version in
> > the
> > repo which means we should simply be installing it from the repo
> > rather
> > than building it...
> >
> > Ed
> >
> > On Wed, Nov 8, 2017 at 7:52 AM Vanessa Valderrama via RT <
> > fdio-helpd...@rt.linuxfoundation.org> wrote:
> >
> > > This error typically occurs when an artifact that already exists is
> > > trying
> > > to be deployed.  Would you like to remove the artifacts that were
> > > deployed
> > > on 10/10? I believe that will resolve this error.
> > >
> > > vpp-dpdk-dev-17.08-vpp2_amd64-deb.deb
> > >
> > > Thank you,
> > > Vanessa
> > >
> > > On Wed Nov 08 08:49:28 2017, hagbard wrote:
> > > > This appears to be something going wrong pushing to the nexus
> > > > server... it
> > > > looks like the nexus server is rejecting the push, from:
> > > >
> > > > https://jenkins.fd.io/view/vpp/job/vpp-merge-master-
> > > > ubuntu1604/3174/consoleFull
> > > >
> > > > 13:07:08 [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]
> > > > 13:07:08 [ERROR]
> > > > 13:07:08 [ERROR] To see the full stack trace of the errors, re-run
> > > > Maven
> > > > with the -e switch.
> > > > 13:07:08 [ERROR] Re-run Maven using the -X switch to enable full
> > > > debug
> > > > logging.
> > > > 13:07:08 [ERROR]
> > > > 13:07:08 [ERROR] For more information about the errors and possible
> > > > solutions, please read the following articles:
> > > > 13:07:08 [ERROR] [Help 1]
> > > >
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> > > > 13:07:08 Build step 'Execute shell' marked build as failure
> > > >
> > > >
> > > > On Tue, Nov 7, 2017 at 11:50 PM Lori Jakab
> > > > 
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Any update on this? We can't get the latest patches via the
> > > > > Ubuntu
> > > > > package
> > > > > manager and that hurts certain test scenarios.
> > > > >
> > > > > -Lori
> > > > >
> > > > >
> > > > > On Mon, Nov 6, 2017 at 6:31 PM, Ed Warnicke 
> > > > > wrote:
> > > > >
> > > > >> This looks like we are hitting the limit on storage at
> > > > >> packagecloud.
> > > > >>
> > > > >> I've manually trimmed some old packages, but we really really
> > > > >> need
> > > > >> to get
> > > > >> the script going that autotrims for us.
> > > > >>
> > > > >> Vanessa,
> > > > >>
> > > > >> How are we doing on that?
> > > > >>
> > > > >> Ed
> > > > >>
> > > > >> On Mon, Nov 6, 2017 at 9:17 AM Luke, Chris
> > > > >> 
> > > > >> wrote:
> > > > >>
> > > > >>> The post-merge jobs are failing with errors like this:
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> *16:04:05* [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]
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> (from
> > > > >>> https://jenkins.fd.io/job/vpp-merge-master-
> > > > >>> ubuntu1604/3148/consoleFull)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> This is sufficiently voodoo for me to not know how to proceed.
> > > > >>> (The
> > > > >>> Nexus stuff consistently annoys and baffles me, not least the
> > > > >>> overly-verbose chatter in build logs)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Could someone take a 

Re: [vpp-dev] [FD.io Helpdesk #47942] Re: Merge jobs faiing

2017-11-09 Thread Ed Warnicke
https://gerrit.fd.io/r/#/c/9329/ fixed it.

Ed

On Wed, Nov 8, 2017 at 3:39 PM Vanessa Valderrama via RT <
fdio-helpd...@rt.linuxfoundation.org> wrote:

> Change https://gerrit.fd.io/r/#/c/9327/ was submitted and merged to
> resolve this issue but the builds are still failing with the same error.
>
> On Wed Nov 08 10:16:01 2017, hagbard wrote:
> > So the more interesting question is... why are we building the vpp-
> > dpdk-dev
> > package at all given that the version in nexus matches the version in
> > the
> > repo which means we should simply be installing it from the repo
> > rather
> > than building it...
> >
> > Ed
> >
> > On Wed, Nov 8, 2017 at 7:52 AM Vanessa Valderrama via RT <
> > fdio-helpd...@rt.linuxfoundation.org> wrote:
> >
> > > This error typically occurs when an artifact that already exists is
> > > trying
> > > to be deployed.  Would you like to remove the artifacts that were
> > > deployed
> > > on 10/10? I believe that will resolve this error.
> > >
> > > vpp-dpdk-dev-17.08-vpp2_amd64-deb.deb
> > >
> > > Thank you,
> > > Vanessa
> > >
> > > On Wed Nov 08 08:49:28 2017, hagbard wrote:
> > > > This appears to be something going wrong pushing to the nexus
> > > > server... it
> > > > looks like the nexus server is rejecting the push, from:
> > > >
> > > > https://jenkins.fd.io/view/vpp/job/vpp-merge-master-
> > > > ubuntu1604/3174/consoleFull
> > > >
> > > > 13:07:08 [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]
> > > > 13:07:08 [ERROR]
> > > > 13:07:08 [ERROR] To see the full stack trace of the errors, re-run
> > > > Maven
> > > > with the -e switch.
> > > > 13:07:08 [ERROR] Re-run Maven using the -X switch to enable full
> > > > debug
> > > > logging.
> > > > 13:07:08 [ERROR]
> > > > 13:07:08 [ERROR] For more information about the errors and possible
> > > > solutions, please read the following articles:
> > > > 13:07:08 [ERROR] [Help 1]
> > > >
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> > > > 13:07:08 Build step 'Execute shell' marked build as failure
> > > >
> > > >
> > > > On Tue, Nov 7, 2017 at 11:50 PM Lori Jakab
> > > > 
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > Any update on this? We can't get the latest patches via the
> > > > > Ubuntu
> > > > > package
> > > > > manager and that hurts certain test scenarios.
> > > > >
> > > > > -Lori
> > > > >
> > > > >
> > > > > On Mon, Nov 6, 2017 at 6:31 PM, Ed Warnicke 
> > > > > wrote:
> > > > >
> > > > >> This looks like we are hitting the limit on storage at
> > > > >> packagecloud.
> > > > >>
> > > > >> I've manually trimmed some old packages, but we really really
> > > > >> need
> > > > >> to get
> > > > >> the script going that autotrims for us.
> > > > >>
> > > > >> Vanessa,
> > > > >>
> > > > >> How are we doing on that?
> > > > >>
> > > > >> Ed
> > > > >>
> > > > >> On Mon, Nov 6, 2017 at 9:17 AM Luke, Chris
> > > > >> 
> > > > >> wrote:
> > > > >>
> > > > >>> The post-merge jobs are failing with errors like this:
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> *16:04:05* [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]
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> (from
> > > > >>> https://jenkins.fd.io/job/vpp-merge-master-
> > > > >>> ubuntu1604/3148/consoleFull)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> This is sufficiently voodoo for me to not know how to proceed.
> > > > >>> (The
> > > > >>> Nexus stuff consistently annoys and baffles me, not least the
> > > > >>> overly-verbose chatter in build logs)
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Could someone take a 

[vpp-dev] how to compile vpp with external dpdk

2017-11-09 Thread Shachar Beiser
Hi ,

 What is the best way to compile the vpp with external dpdk ?
I tried to change the build-data/platforms/vpp.mk : vpp_uses_external_dpdk 
, vpp_dpdk_inc_dir , vpp_dpdk_lib_dir but it fails to compile .
 There is a compilation error :" rte_config.h: No such file or directory" , 
but the rte_config.h is under /home/ubuntu/install/include/dpdk/
 and the vpp.mk is changed like : vpp_dpdk_inc_dir = 
/home/ubuntu/install/include/dpdk/ ?!
 -Shachar Beiser.

Error:
/home/ubuntu/vpp.bin/build-data/../src/plugins/dpdk/thread.c:16:24: fatal 
error: rte_config.h: No such file or directory
compilation terminated.
Makefile:2172: recipe for target 'dpdk/dpdk_plugin_la-thread.lo' failed

The rte_config.h file location :
The rte_config.h is under /home/ubuntu/install/include/dpdk/ and the 
vpp_dpdk_inc_dir = /home/ubuntu/install/include/dpdk/ ?!

The patch I did:
diff --git a/build-data/platforms/vpp.mk b/build-data/platforms/vpp.mk
index 7745717..69249f6 100644
--- a/build-data/platforms/vpp.mk
+++ b/build-data/platforms/vpp.mk
@@ -39,10 +39,10 @@ vpp_uses_dpdk = yes
vpp_root_packages = vpp

# DPDK configuration parameters
-# vpp_uses_dpdk_mlx5_pmd = yes
-# vpp_uses_external_dpdk = yes
-# vpp_dpdk_inc_dir = /usr/include/dpdk
-# vpp_dpdk_lib_dir = /usr/lib
+vpp_uses_dpdk_mlx5_pmd = yes
+vpp_uses_external_dpdk = yes
+vpp_dpdk_inc_dir = /home/ubuntu/install/include/dpdk/
+vpp_dpdk_lib_dir = /home/ubuntu/install/lib


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

Re: [vpp-dev] And Boost Log too?

2017-11-09 Thread Thomas F Herbert

boost and boost-devel should suffice.


On 11/08/2017 03:30 PM, Jon Loeliger wrote:
On Wed, Nov 8, 2017 at 2:29 PM, Neale Ranns (nranns) > wrote:


Hi Jon,

It doesn’t need it. I must have left that in by mistake. I’ll take
it out.

Awesome.  Thanks!

jdl


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


--
*Thomas F Herbert*
NFV and Fast Data Planes
Networking Group Office of the CTO
*Red Hat*
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] gtpu tunneling decap-next ip4 issue

2017-11-09 Thread Ryota Yushina

Hi, Neale-san,

Thank you for your great advice.
Once I configured IPv4 address at both gtpu_tunnels, it worked with "ip4" 
option.

---
Best Regards,

Ryota Yushina,


> -Original Message-
> From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
> Sent: Monday, November 06, 2017 6:57 PM
> To: Yushina Ryota(油科 亮太) ; Ni, Hongjun 
> ; vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] gtpu tunneling decap-next ip4 issue
> 
> 
> Hi Ryota-san,
> 
> I glad it works now. I couple of comments, marked [nr], on your setup are 
> inline below.
> 
> Regards,
> neale
> 
> -Original Message-
> From: Ryota Yushina 
> Date: Monday, 6 November 2017 at 10:12
> To: "Ni, Hongjun" , "Neale Ranns (nranns)" 
> , "vpp-dev@lists.fd.io"
> 
> Subject: RE: [vpp-dev] gtpu tunneling decap-next ip4 issue
> 
> 
> To Hongjon-san, Neale-san
> 
> Thank you so much for your great help. This patch solved the problem!
> ICMP packets were encapped and routed to target.
> As your discussion, vpp crashed at accessing gtpu_tunnel soruce mac 
> address pointer(=null).
> 
> 
> Below is just my memo.
> 
> I faced a new issue.
> An decapped IP4 packet(inner ip4 packet) was through to "ip4-drop" via 
> "ip4-input" from "gtpu4-input" on
> GTPu-endpoint(recv).
> My expected graph flow was "gtpu4-input" -> "ip4-input" -> "ip4-lookup" 
> -> ...
> 
> So I created gtpu tunnel with following uses "node ip4-lookup" option 
> instead of "ip4".
> # create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  
> encap-vrf-id 152 decap-next node ip4-lookup
> 
> It worked fine.
> 
> Followngs are my final configurations. Ping from vpp#3 returned from 
> vpp#4 via vpp#7.
> 
>   set interface ip address TenGigabitEthernet82/0/1 10.9.0.3/16
>   ip route 11.9.0.0/16 via 10.9.0.1
>   set interface state TenGigabitEthernet82/0/1 up
> 
> 
>   set interface ip address TenGigabitEthernet82/0/1 10.9.0.1/16
>   set interface ip table TenGigabitEthernet82/0/0 152
>   set interface ip address TenGigabitEthernet82/0/0 192.168.152.70/24
>   create gtpu tunnel src 192.168.152.70 dst 192.168.152.40 teid  
> encap-vrf-id 152 decap-next node ip4-lookup
>   set interface ip address gtpu_tunnel0 11.9.0.1/16
>   ip route 11.9.0.0/16 via gtpu_tunnel0
> 
> [nr] Having applied the subnet 11.9.0.0/16 to the GTPu interface, this route 
> is unnecessary and in fact unused, since
> the interface configuration takes precedence. If you do ‘sh ip fib 
> 11.9.0.0/16’ you should see both the ‘src:interface’
> and ‘src:CLI’.
> 
>   ip route 10.9.0.0/16 via TenGigabitEthernet82/0/1
>   set interface state TenGigabitEthernet82/0/1 up
>   set interface state TenGigabitEthernet82/0/0 up
> 
> 
>   set interface ip table TenGigabitEthernet82/0/0 152
>   set interface ip address TenGigabitEthernet82/0/0 192.168.152.40/24
>   create gtpu tunnel src 192.168.152.40 dst 192.168.152.70 teid  
> encap-vrf-id 152 decap-next node ip4-lookup
>   create loopback interaface
>   set interface ip address loop0 11.9.0.0.4/16
> 
> [nr] because you applied the 11.9.0.0/16 subnet to the loopback interface, 
> there is no subnet configured on the GTP-u
> interface. Any interface type that does not have a configured IPv4 address 
> cannot accept IPv4 traffic – that’s a basic
> security feature. Packets arriving on such an interface will be dropped just 
> after ip4-input. If you were to apply the
> subnet on the GTP-u interface instead, then you would be able to revert your 
> GTP-u tunnel decap-node configuration to
> perform ip4-input. This would be preferred since the decapsulated IP packets 
> would then be subject to the usual input
> checks (i.e. TTL, chksum, etc).
> 
>   ip route 10.9.0.0/16 via gtpu_tunnel0
>   set interface state TenGigabitEthernet82/0/0 up
>   set interface state loop0 up
> 
> > +- VPP#3 -
> > |
> > | [TenGigabitEthernet82/0/1: 10.9.0.3]
> > +-- | 
> > |
> > +-VPP#7 | 
> > | [TenGigabitEthernet82/0/1: 10.9.0.1]
> > |
> > | [gtpu_tunnel0: 11.9.0.1]
> > |   |
> > | [TenGigabitEthernet82/0/0: 192.168.152.70] --> vrf:152
> > +-- || ---
> > ||
> > +-- || ---
> > | [TenGigabitEthernet82/0/0: 192.168.152.40] --> vrf:152
> > |
> > | [loop0: 11.9.0.4]
> > +- VPP#4 -
> 
> ---
> Best Regards,
> 
> Ryota Yushina,
> NEC
> 
> 
> 
> 
> > -Original Message-
> > From: Ni, Hongjun [mailto:hongjun...@intel.com]
> > Sent: Friday, November 03, 2017 10:50 AM
> > 

[vpp-dev] VPP map fragmentation issue

2017-11-09 Thread Jacek Siuda
Hi,

We have a problem with fragmentation in map while running the following
test:

1. Create an IPv4 packet that won't fit into MTU (but is smaller than
2*MTU).
2. Send it through interface that will do automatic fragmentation - this
produces two fragments - one that fits exactly MTU and another that is
smaller.
3. VPP seems to receive both and is expected to encapsulate them into IPv6
then forward further. However what we see forwarded is only a smaller
packet (encapsulated properly, though).

What I suspect is that the larger fragment gets encapsulated too, but it
does not fit MTU then and gets dropped.

This happens regardless of any map fragmentation/reassembly setting.

Any Idea how I could debug it further? Any logs? Maybe we still need to
configure something more - not on map level?

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