Re: [vpp-dev] Ip fragment reassembly

[薛欣颖]

ok .Thank you very much !

xyxue 

From: Kinsella, Ray
Date: 2017-05-15 19:02
To: 薛欣颖; vpp-dev
Subject: Re: [vpp-dev] Ip fragment reassembly
Hi Xyxue,
 
Please try
 
https://gerrit.fd.io/r/#/c/6695/
 
And see if it resolves your issue.
 
Ray K
 
On 10/05/2017 13:35, 薛欣颖 wrote:
> Hi guys,
>
> Whether vpp support ip fragment reassembly on host-interface?
> Can I use only" set interface mtu 2000 host-eth2 "to set mtu.
>
> Here's my test result:
> vpp+dpdk:
> mtu 1500  when the packet size 1500+  it  dropped;
> mtu 2000  when the packet size 2000+  it  dropped;
> mtu 300  when the packet size < 1500 it passed;
> no fragmentation in my test;
> vpp without dpdk:
> Configuring MTU is not effective.
>
> Thanks,
> xyxue
>
>
> ___
> 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 borked on master

[Neale Ranns (nranns)]

Hi All,

It looks like we have returned to normal operations. The job backlog has now 
cleared.

If you have an outstanding patch that I have not rebased/rechecked as of now, 
and does not have code-review comments, then it was un-intentionally missed – 
so please rebase AYC.

Many thanks to Peter, Maciek and especially Damjan for the RCA and the patch. 
We’ll conduct a post-mortem to understand how we got into this situation – 
report to follow.

Thank-you for your patience.

Regard,
Neale



-Original Message-
From: "Maciek Konstantynowicz (mkonstan)" 
Date: Monday, 15 May 2017 at 19:45
To: "csit-...@lists.fd.io" 
Cc: Ray Kinsella , "Neale Ranns (nranns)" 
, "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] CSIT borked on master

+csit-dev

-Maciek

> On 15 May 2017, at 18:09, Neale Ranns (nranns)  wrote:
> 
> 
> I hope so. We changed the version from 17.05-vpp1 to 17.05-vpp2 today. I 
suspect your build started while we were in flux. If the next one fails, we’ll 
look deeper. 
> 
> Most Jobs are passing again. Some intermittent issues with VXLAN tests, 
which may be infra related.
> 
> We continue to monitor the situation.
> 
> /neale
> 
> -Original Message-
> From:  on behalf of "Kinsella, Ray" 

> Date: Monday, 15 May 2017 at 17:10
> To: "vpp-dev@lists.fd.io" 
> Subject: Re: [vpp-dev] CSIT borked on master
> 
> 
>Does it explain why I am getting a build failure on CentOS ?
> 
>
https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-centos7/5402/console.log.gz
> 
>+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
>+ /usr/lib/rpm/redhat/brp-python-hardlink
>+ /usr/lib/rpm/redhat/brp-java-repack-jars
>Processing files: vpp-dpdk-devel-17.05-vpp1.x86_64
>Provides: vpp-dpdk-devel = 17.05-vpp1 vpp-dpdk-devel(x86-64) = 
17.05-vpp1
>Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 
>rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 
>rpmlib(PayloadFilesHavePrefix) <= 4.0-1
>Requires: /bin/bash /bin/sh /usr/bin/env ld-linux-x86-64.so.2()(64bit) 
>ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) libc.so.6()(64bit) 
>libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) 
>libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) 
>libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) 
>libc.so.6(GLIBC_2.7)(64bit) libc.so.6(GLIBC_2.8)(64bit) 
>libcrypto.so.10()(64bit) libcrypto.so.10(libcrypto.so.10)(64bit) 
>libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libm.so.6()(64bit) 
>libm.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit) 
>libpthread.so.0(GLIBC_2.12)(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) 
>libpthread.so.0(GLIBC_2.3.2)(64bit) 
libpthread.so.0(GLIBC_2.3.4)(64bit) 
>librt.so.1()(64bit) librt.so.1(GLIBC_2.2.5)(64bit) rtld(GNU_HASH)
>Checking for unpackaged file(s): /usr/lib/rpm/check-files 
>
/w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILDROOT/vpp-dpdk-17.05-vpp1.x86_64
>Wrote: 
>
/w/workspace/vpp-verify-master-centos7/dpdk/rpm/RPMS/x86_64/vpp-dpdk-devel-17.05-vpp1.x86_64.rpm
>Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.bH2a6n
>+ umask 022
>+ cd /w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILD
>+ /usr/bin/rm -rf 
>
/w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILDROOT/vpp-dpdk-17.05-vpp1.x86_64
>+ exit 0
>mv rpm/RPMS/x86_64/*.rpm .
>git clean -fdx rpm
>Removing rpm/BUILD/
>Removing rpm/BUILDROOT/
>Removing rpm/RPMS/
>Removing rpm/SOURCES/
>Removing rpm/SPECS/
>Removing rpm/SRPMS/
>Removing rpm/tmp/
>make[2]: Leaving directory 
`/w/workspace/vpp-verify-master-centos7/dpdk'
>sudo rpm -Uih vpp-dpdk-devel-17.05-vpp1.x86_64.rpm
>
>   package vpp-dpdk-devel-17.05-vpp2.x86_64 (which is newer than 
>vpp-dpdk-devel-17.05-vpp1.x86_64) is already installed
>make[1]: *** [install-rpm] Error 2
>make[1]: Leaving directory 
`/w/workspace/vpp-verify-master-centos7/dpdk'
>make: *** [dpdk-install-dev] Error 2
>Build step 'Execute shell' marked build as failure
> 
> 
>Ray K
> 
>On 15/05/2017 11:54, Damjan Marion (damarion) wrote:
>> 
>> This issue is caused by bug in DPDK 17.05 caused by following commit:
>> 
>> http://dpdk.org/browse/dpdk/commit/?id=ee1843b
>> 
>> It happens only with old QEMU emulation (I repro it with “pc-1.0”) which
>> VIRL uses.
>> 
>> Fix (revert) is in gerrit:
>> 
>> https://gerrit.fd.io/r/#/c/6690/
>> 
>> Regards,
>> 
>> Damjan
>> 
>> 
>>> On 13 May 2017, at 20:34, Neale Ranns (nranns) >> 

Re: [vpp-dev] CSIT borked on master

[Maciek Konstantynowicz (mkonstan)]

+csit-dev

-Maciek

> On 15 May 2017, at 18:09, Neale Ranns (nranns)  wrote:
> 
> 
> I hope so. We changed the version from 17.05-vpp1 to 17.05-vpp2 today. I 
> suspect your build started while we were in flux. If the next one fails, 
> we’ll look deeper. 
> 
> Most Jobs are passing again. Some intermittent issues with VXLAN tests, which 
> may be infra related.
> 
> We continue to monitor the situation.
> 
> /neale
> 
> -Original Message-
> From:  on behalf of "Kinsella, Ray" 
> 
> Date: Monday, 15 May 2017 at 17:10
> To: "vpp-dev@lists.fd.io" 
> Subject: Re: [vpp-dev] CSIT borked on master
> 
> 
>Does it explain why I am getting a build failure on CentOS ?
> 
>
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-centos7/5402/console.log.gz
> 
>+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
>+ /usr/lib/rpm/redhat/brp-python-hardlink
>+ /usr/lib/rpm/redhat/brp-java-repack-jars
>Processing files: vpp-dpdk-devel-17.05-vpp1.x86_64
>Provides: vpp-dpdk-devel = 17.05-vpp1 vpp-dpdk-devel(x86-64) = 17.05-vpp1
>Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 
>rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 
>rpmlib(PayloadFilesHavePrefix) <= 4.0-1
>Requires: /bin/bash /bin/sh /usr/bin/env ld-linux-x86-64.so.2()(64bit) 
>ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) libc.so.6()(64bit) 
>libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) 
>libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) 
>libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) 
>libc.so.6(GLIBC_2.7)(64bit) libc.so.6(GLIBC_2.8)(64bit) 
>libcrypto.so.10()(64bit) libcrypto.so.10(libcrypto.so.10)(64bit) 
>libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libm.so.6()(64bit) 
>libm.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit) 
>libpthread.so.0(GLIBC_2.12)(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) 
>libpthread.so.0(GLIBC_2.3.2)(64bit) libpthread.so.0(GLIBC_2.3.4)(64bit) 
>librt.so.1()(64bit) librt.so.1(GLIBC_2.2.5)(64bit) rtld(GNU_HASH)
>Checking for unpackaged file(s): /usr/lib/rpm/check-files 
>
> /w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILDROOT/vpp-dpdk-17.05-vpp1.x86_64
>Wrote: 
>
> /w/workspace/vpp-verify-master-centos7/dpdk/rpm/RPMS/x86_64/vpp-dpdk-devel-17.05-vpp1.x86_64.rpm
>Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.bH2a6n
>+ umask 022
>+ cd /w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILD
>+ /usr/bin/rm -rf 
>
> /w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILDROOT/vpp-dpdk-17.05-vpp1.x86_64
>+ exit 0
>mv rpm/RPMS/x86_64/*.rpm .
>git clean -fdx rpm
>Removing rpm/BUILD/
>Removing rpm/BUILDROOT/
>Removing rpm/RPMS/
>Removing rpm/SOURCES/
>Removing rpm/SPECS/
>Removing rpm/SRPMS/
>Removing rpm/tmp/
>make[2]: Leaving directory `/w/workspace/vpp-verify-master-centos7/dpdk'
>sudo rpm -Uih vpp-dpdk-devel-17.05-vpp1.x86_64.rpm
>
>   package vpp-dpdk-devel-17.05-vpp2.x86_64 (which is newer than 
>vpp-dpdk-devel-17.05-vpp1.x86_64) is already installed
>make[1]: *** [install-rpm] Error 2
>make[1]: Leaving directory `/w/workspace/vpp-verify-master-centos7/dpdk'
>make: *** [dpdk-install-dev] Error 2
>Build step 'Execute shell' marked build as failure
> 
> 
>Ray K
> 
>On 15/05/2017 11:54, Damjan Marion (damarion) wrote:
>> 
>> This issue is caused by bug in DPDK 17.05 caused by following commit:
>> 
>> http://dpdk.org/browse/dpdk/commit/?id=ee1843b
>> 
>> It happens only with old QEMU emulation (I repro it with “pc-1.0”) which
>> VIRL uses.
>> 
>> Fix (revert) is in gerrit:
>> 
>> https://gerrit.fd.io/r/#/c/6690/
>> 
>> Regards,
>> 
>> Damjan
>> 
>> 
>>> On 13 May 2017, at 20:34, Neale Ranns (nranns) >> > wrote:
>>> 
>>> 
>>> Hi Chris,
>>> 
>>> Yes, every CSIT job on master is borked.
>>> I think I’ve narrowed this down to all VAT sw_interface_dump returning
>>> bogus/garbage MAC addresses. No Idea why, can’t repro yet. I’ve a
>>> speculative DPDK 17.05 bump backout job in the queue, for purposes of
>>> elimination.
>>> 
>>> Regards,
>>> /neale
>>> 
>>> 
>>> 
 *From: *"Luke, Chris" >>> >
 *Date: *Saturday, 13 May 2017 at 19:04
 *To: *"Neale Ranns (nranns)" >>> >, "yug...@telincn.com
 " >>> >, vpp-dev >>> >
 *Subject: *RE: [vpp-dev] Segmentation fault in recursivly lookuping
 fib entry.
 
 CSIT seems to be barfing on every job at the moment :(
 
 *From:* vpp-dev-boun...@lists.fd.io
  [mailto:vpp-dev-boun...@lists.fd.io] 
 *On
 Behalf Of *Neale Ranns (nranns)
 *Sent:* Saturday, May 13, 2017 11:20
 *To:* yug...@telincn.com ; vpp-de

Re: [vpp-dev] CSIT borked on master

[Neale Ranns (nranns)]

I hope so. We changed the version from 17.05-vpp1 to 17.05-vpp2 today. I 
suspect your build started while we were in flux. If the next one fails, we’ll 
look deeper. 

Most Jobs are passing again. Some intermittent issues with VXLAN tests, which 
may be infra related.

We continue to monitor the situation.

/neale

-Original Message-
From:  on behalf of "Kinsella, Ray" 

Date: Monday, 15 May 2017 at 17:10
To: "vpp-dev@lists.fd.io" 
Subject: Re: [vpp-dev] CSIT borked on master


Does it explain why I am getting a build failure on CentOS ?


https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-centos7/5402/console.log.gz

+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
Processing files: vpp-dpdk-devel-17.05-vpp1.x86_64
Provides: vpp-dpdk-devel = 17.05-vpp1 vpp-dpdk-devel(x86-64) = 17.05-vpp1
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: /bin/bash /bin/sh /usr/bin/env ld-linux-x86-64.so.2()(64bit) 
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) libc.so.6()(64bit) 
libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) 
libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) 
libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) 
libc.so.6(GLIBC_2.7)(64bit) libc.so.6(GLIBC_2.8)(64bit) 
libcrypto.so.10()(64bit) libcrypto.so.10(libcrypto.so.10)(64bit) 
libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libm.so.6()(64bit) 
libm.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit) 
libpthread.so.0(GLIBC_2.12)(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) 
libpthread.so.0(GLIBC_2.3.2)(64bit) libpthread.so.0(GLIBC_2.3.4)(64bit) 
librt.so.1()(64bit) librt.so.1(GLIBC_2.2.5)(64bit) rtld(GNU_HASH)
Checking for unpackaged file(s): /usr/lib/rpm/check-files 

/w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILDROOT/vpp-dpdk-17.05-vpp1.x86_64
Wrote: 

/w/workspace/vpp-verify-master-centos7/dpdk/rpm/RPMS/x86_64/vpp-dpdk-devel-17.05-vpp1.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.bH2a6n
+ umask 022
+ cd /w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILD
+ /usr/bin/rm -rf 

/w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILDROOT/vpp-dpdk-17.05-vpp1.x86_64
+ exit 0
mv rpm/RPMS/x86_64/*.rpm .
git clean -fdx rpm
Removing rpm/BUILD/
Removing rpm/BUILDROOT/
Removing rpm/RPMS/
Removing rpm/SOURCES/
Removing rpm/SPECS/
Removing rpm/SRPMS/
Removing rpm/tmp/
make[2]: Leaving directory `/w/workspace/vpp-verify-master-centos7/dpdk'
sudo rpm -Uih vpp-dpdk-devel-17.05-vpp1.x86_64.rpm

package vpp-dpdk-devel-17.05-vpp2.x86_64 (which is newer than 
vpp-dpdk-devel-17.05-vpp1.x86_64) is already installed
make[1]: *** [install-rpm] Error 2
make[1]: Leaving directory `/w/workspace/vpp-verify-master-centos7/dpdk'
make: *** [dpdk-install-dev] Error 2
Build step 'Execute shell' marked build as failure


Ray K

On 15/05/2017 11:54, Damjan Marion (damarion) wrote:
>
> This issue is caused by bug in DPDK 17.05 caused by following commit:
>
> http://dpdk.org/browse/dpdk/commit/?id=ee1843b
>
> It happens only with old QEMU emulation (I repro it with “pc-1.0”) which
> VIRL uses.
>
> Fix (revert) is in gerrit:
>
> https://gerrit.fd.io/r/#/c/6690/
>
> Regards,
>
> Damjan
>
>
>> On 13 May 2017, at 20:34, Neale Ranns (nranns) > > wrote:
>>
>>
>> Hi Chris,
>>
>> Yes, every CSIT job on master is borked.
>> I think I’ve narrowed this down to all VAT sw_interface_dump returning
>> bogus/garbage MAC addresses. No Idea why, can’t repro yet. I’ve a
>> speculative DPDK 17.05 bump backout job in the queue, for purposes of
>> elimination.
>>
>> Regards,
>> /neale
>>
>>
>>
>>> *From: *"Luke, Chris" >> >
>>> *Date: *Saturday, 13 May 2017 at 19:04
>>> *To: *"Neale Ranns (nranns)" >> >, "yug...@telincn.com
>>> " >> >, vpp-dev >> >
>>> *Subject: *RE: [vpp-dev] Segmentation fault in recursivly lookuping
>>> fib entry.
>>>
>>> CSIT seems to be barfing on every job at the moment :(
>>>
>>> *From:* vpp-dev-boun...@lists.fd.io
>>>  
[mailto:vpp-dev-boun...@lists.fd.io] *On
>>> Behalf Of *Neale Ranns (nranns)
>>> *Sent:* Saturday, May 13, 2017 11:20
>>> *To:* yug...@telincn.com ; vpp-dev
>>> mailto:vpp-dev@lists.fd.io>>
>>> *Subj

Re: [vpp-dev] CSIT borked on master

[Kinsella, Ray]

Does it explain why I am getting a build failure on CentOS ?

https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-centos7/5402/console.log.gz

+ /usr/lib/rpm/brp-python-bytecompile /usr/bin/python 1
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
Processing files: vpp-dpdk-devel-17.05-vpp1.x86_64
Provides: vpp-dpdk-devel = 17.05-vpp1 vpp-dpdk-devel(x86-64) = 17.05-vpp1
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 
rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Requires: /bin/bash /bin/sh /usr/bin/env ld-linux-x86-64.so.2()(64bit) 
ld-linux-x86-64.so.2(GLIBC_2.3)(64bit) libc.so.6()(64bit) 
libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) 
libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.2)(64bit) 
libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) 
libc.so.6(GLIBC_2.7)(64bit) libc.so.6(GLIBC_2.8)(64bit) 
libcrypto.so.10()(64bit) libcrypto.so.10(libcrypto.so.10)(64bit) 
libdl.so.2()(64bit) libdl.so.2(GLIBC_2.2.5)(64bit) libm.so.6()(64bit) 
libm.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit) 
libpthread.so.0(GLIBC_2.12)(64bit) libpthread.so.0(GLIBC_2.2.5)(64bit) 
libpthread.so.0(GLIBC_2.3.2)(64bit) libpthread.so.0(GLIBC_2.3.4)(64bit) 
librt.so.1()(64bit) librt.so.1(GLIBC_2.2.5)(64bit) rtld(GNU_HASH)
Checking for unpackaged file(s): /usr/lib/rpm/check-files 
/w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILDROOT/vpp-dpdk-17.05-vpp1.x86_64
Wrote: 
/w/workspace/vpp-verify-master-centos7/dpdk/rpm/RPMS/x86_64/vpp-dpdk-devel-17.05-vpp1.x86_64.rpm

Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.bH2a6n
+ umask 022
+ cd /w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILD
+ /usr/bin/rm -rf 
/w/workspace/vpp-verify-master-centos7/dpdk/rpm/BUILDROOT/vpp-dpdk-17.05-vpp1.x86_64

+ exit 0
mv rpm/RPMS/x86_64/*.rpm .
git clean -fdx rpm
Removing rpm/BUILD/
Removing rpm/BUILDROOT/
Removing rpm/RPMS/
Removing rpm/SOURCES/
Removing rpm/SPECS/
Removing rpm/SRPMS/
Removing rpm/tmp/
make[2]: Leaving directory `/w/workspace/vpp-verify-master-centos7/dpdk'
sudo rpm -Uih vpp-dpdk-devel-17.05-vpp1.x86_64.rpm

	package vpp-dpdk-devel-17.05-vpp2.x86_64 (which is newer than 
vpp-dpdk-devel-17.05-vpp1.x86_64) is already installed

make[1]: *** [install-rpm] Error 2
make[1]: Leaving directory `/w/workspace/vpp-verify-master-centos7/dpdk'
make: *** [dpdk-install-dev] Error 2
Build step 'Execute shell' marked build as failure


Ray K

On 15/05/2017 11:54, Damjan Marion (damarion) wrote:


This issue is caused by bug in DPDK 17.05 caused by following commit:

http://dpdk.org/browse/dpdk/commit/?id=ee1843b

It happens only with old QEMU emulation (I repro it with “pc-1.0”) which
VIRL uses.

Fix (revert) is in gerrit:

https://gerrit.fd.io/r/#/c/6690/

Regards,

Damjan



On 13 May 2017, at 20:34, Neale Ranns (nranns) mailto:nra...@cisco.com>> wrote:


Hi Chris,

Yes, every CSIT job on master is borked.
I think I’ve narrowed this down to all VAT sw_interface_dump returning
bogus/garbage MAC addresses. No Idea why, can’t repro yet. I’ve a
speculative DPDK 17.05 bump backout job in the queue, for purposes of
elimination.

Regards,
/neale




*From: *"Luke, Chris" mailto:chris_l...@comcast.com>>
*Date: *Saturday, 13 May 2017 at 19:04
*To: *"Neale Ranns (nranns)" mailto:nra...@cisco.com>>, "yug...@telincn.com
" mailto:yug...@telincn.com>>, vpp-dev mailto:vpp-dev@lists.fd.io>>
*Subject: *RE: [vpp-dev] Segmentation fault in recursivly lookuping
fib entry.

CSIT seems to be barfing on every job at the moment :(

*From:* vpp-dev-boun...@lists.fd.io
 [mailto:vpp-dev-boun...@lists.fd.io] *On
Behalf Of *Neale Ranns (nranns)
*Sent:* Saturday, May 13, 2017 11:20
*To:* yug...@telincn.com ; vpp-dev
mailto:vpp-dev@lists.fd.io>>
*Subject:* Re: [vpp-dev] Segmentation fault in recursivly lookuping
fib entry.


https://gerrit.fd.io/r/#/c/6674/


/neale


*From: *"yug...@telincn.com "
mailto:yug...@telincn.com>>
*Date: *Saturday, 13 May 2017 at 14:24
*To: *"Neale Ranns (nranns)" mailto:nra...@cisco.com>>, vpp-dev mailto:vpp-dev@lists.fd.io>>
*Subject: *Re: Re: [vpp-dev] Segmentation fault in recursivly
lookuping fib entry.

Hi neale,
Could you leave me a msg then?

Thanks,
Ewan


yug...@telincn.com 


*From:* Neale Ranns (nranns) 
*Date:* 2017-05-13 20:33
*To:* yug...@telincn.com ; vpp-dev

*Subject:* Re: [vpp-dev] Segmentation fault in recursivly lookuping
fib entry.
Hi Ewan,

That’s a bug. I’ll fix it ASAP.

Thanks,
neale


*From: *mailto:vpp-dev-boun...@lists.fd.io>> on behalf of
"yug...@telincn.com "
mailto:yug.

Re: [vpp-dev] any "cloud" facilities for testing VPPs and VNFs at high load ?

[Kinsella, Ray]

Would you consider developing and contributing vSwitch scaling test 
cases to CSIT as one method?


Ray K

On 14/05/2017 15:43, madhu sharma wrote:


I am looking for a way to create a test setup for my VPP-based VNF,
running at 10-100gbps throughput.

Any recommendations ? Short of putting together their own network lab
with in-house hardware, how do folks test their virtual switches, VPPs,
and VNFs ?

At a minimum, I want to run my VNF on say 2-8 cores, and generate
stateful traffic using Trex on a connected VM - via virtual or real NICs.

I came across one such facility. Advantech, also in collaboration with
TwinPrime offers it here:
http://www2.advantech.com/nc/newsletter/NCG/RES/environment.html
I also see references to an Intel/Cisco NFV Quick Start Lab.

Anyone tried AWS or Azure ?

thanks,
- Madhu



___
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 borked on master

[Jon Loeliger]

On Mon, May 15, 2017 at 9:12 AM, Marco Varlese 
wrote:

> Hi Damjan,
> As per your input I waited for your patch to be merged and then rebased
> mine.
> However, the vpp-csit-verify-virl-master still fails...
>
> Shall I try to "recheck" again?
>
>
> Thanks,
> Marco
>

Yeah, my patch seems to have done the same failure, unrelated
to my actual patch contents.

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

Re: [vpp-dev] CSIT borked on master

[Neale Ranns (nranns)]

Hi Marco,

Please wait. I’ll re-submit the jobs when we’ve got everything ready.

Thanks,
neale

From: Marco Varlese 
Date: Monday, 15 May 2017 at 15:12
To: "Damjan Marion (damarion)" , "Neale Ranns (nranns)" 

Cc: "csit-...@lists.fd.io" , vpp-dev 
Subject: Re: [vpp-dev] CSIT borked on master

Hi Damjan,
As per your input I waited for your patch to be merged and then rebased mine.
However, the vpp-csit-verify-virl-master still fails...

Shall I try to "recheck" again?


Thanks,
Marco

On Mon, 2017-05-15 at 11:39 +, Damjan Marion (damarion) wrote:

“recheck" will not be enough. All patches must be rebased so they pick up my 
fix...

On 15 May 2017, at 13:38, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:


Hi Marco,

I’ll restart the jobs once we’ve got them passing again.

For your reference, you can do it manually by typing ‘recheck’ as a code review 
comment in gerrit.

regards,
neale

From: Marco Varlese mailto:marco.varl...@suse.com>>
Date: Monday, 15 May 2017 at 12:17
To: "Damjan Marion (damarion)" mailto:damar...@cisco.com>>, 
"Neale Ranns (nranns)" mailto:nra...@cisco.com>>
Cc: "csit-...@lists.fd.io" 
mailto:csit-...@lists.fd.io>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] CSIT borked on master

Hi Damjan,

Once you're patch is merged, is it possible to kick off the builds which 
currently are all marked as Verified-1 so to have a clean state on them?

If I could do that manually I would do it at least for mine.


Thanks,
Marco

On Mon, 2017-05-15 at 10:54 +, Damjan Marion (damarion) wrote:

This issue is caused by bug in DPDK 17.05 caused by following commit:

http://dpdk.org/browse/dpdk/commit/?id=ee1843b

It happens only with old QEMU emulation (I repro it with “pc-1.0”) which VIRL 
uses.

Fix (revert) is in gerrit:

https://gerrit.fd.io/r/#/c/6690/

Regards,

Damjan


On 13 May 2017, at 20:34, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:


Hi Chris,

Yes, every CSIT job on master is borked.
I think I’ve narrowed this down to all VAT sw_interface_dump returning 
bogus/garbage MAC addresses. No Idea why, can’t repro yet. I’ve a speculative 
DPDK 17.05 bump backout job in the queue, for purposes of elimination.

Regards,
/neale



From: "Luke, Chris" mailto:chris_l...@comcast.com>>
Date: Saturday, 13 May 2017 at 19:04
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, 
"yug...@telincn.com" 
mailto:yug...@telincn.com>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

CSIT seems to be barfing on every job at the moment :(

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Neale Ranns (nranns)
Sent: Saturday, May 13, 2017 11:20
To: yug...@telincn.com; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.


https://gerrit.fd.io/r/#/c/6674/

/neale

From: "yug...@telincn.com" 
mailto:yug...@telincn.com>>
Date: Saturday, 13 May 2017 at 14:24
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

Hi neale,
Could you leave me a msg then?

Thanks,
Ewan


yug...@telincn.com

From: Neale Ranns (nranns)
Date: 2017-05-13 20:33
To: yug...@telincn.com; 
vpp-dev
Subject: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.
Hi Ewan,

That’s a bug. I’ll fix it ASAP.

Thanks,
neale

From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of "yug...@telincn.com" 
mailto:yug...@telincn.com>>
Date: Saturday, 13 May 2017 at 03:24
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

Hi, all
Below are my main configs, others are default.
When i knock into this cmd  "vppctl ip route 0.0.0.0/0 via 10.10.40.1" to add 
one default route,
the vpp crashed, it looks like this func fib_entry_get_resolving_interface call 
itself recursivly  till vpp's crash.
Is there something wrong?





config  info
root@ubuntu:/usr/src/1704/VBRASV100R001/vpp1704/build-root# vppctl show int addr
GigabitEthernet2/6/0 (up):
  192.168.60.1/24
GigabitEthernet2/7/0 (up):
  10.10.55.51/24
host-vGE2_6_0 (up):
host-vGE2_7_0 (up):
local0 (dn):





root@ubuntu:/usr/src/1704/VBRASV100R001/vpp1704/build-root# vppctl show ip fib
ipv4-VRF:0, fib_index 0, flow hash: src dst sport dport proto
0.0.0.0/0
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:0 buckets:1 uRPF:0 to:[142:12002]]
[0] [@0]: dpo-drop ip4
0.0.0.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:1 buckets:1 uRPF:1 to:[0:0]]
[0] 

Re: [vpp-dev] CSIT borked on master

[Marco Varlese]

Hi Damjan,
As per your input I waited for your patch to be merged and then rebased mine.
However, the vpp-csit-verify-virl-master still fails... 

Shall I try to "recheck" again?


Thanks,
Marco

On Mon, 2017-05-15 at 11:39 +, Damjan Marion (damarion) wrote:
> 
> 
> 
> 
> 
> > “recheck" will not be enough. All patches must be rebased so they pick up my
fix...
> 
> 
> 
> 
> > > > On 15 May 2017, at 13:38, Neale Ranns (nranns)  wrote:
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > Hi Marco,
> > 
> > 
> >  
> > 
> > 
> > I’ll restart the jobs once we’ve got them passing again.
> > 
> > 
> >  
> > 
> > 
> > > > For your reference, you can do it manually by typing ‘recheck’ as a code
review comment in gerrit.
> > 
> > 
> >  
> > 
> > 
> > regards,
> > 
> > 
> > neale
> > 
> > 
> >  
> > 
> > > 
> > > 
> > > > > > From: Marco Varlese 
> > > 
> > > Date: Monday, 15 May 2017 at 12:17
> > > 
> > > > > > > > > > > > To: "Damjan Marion (damarion)" , 
> > > > > > > > > > > > "Neale Ranns
(nranns)" 
> > > 
> > > > > > > > > Cc: "csit-...@lists.fd.io" ,
> > > > > >  vpp-dev 
> > > 
> > > Subject: Re: [vpp-dev] CSIT borked on master
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Hi Damjan,
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > > > Once you're patch is merged, is it possible to kick off the builds 
> > > > > > which
currently are all marked as Verified-1 so to have a clean state on them?
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > If I could do that manually I would do it at least for mine.
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Thanks,
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Marco
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > On Mon, 2017-05-15 at 10:54 +, Damjan Marion (damarion) wrote:
> > > 
> > > 
> > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > This issue is caused by bug in DPDK 17.05 caused by following commit:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > http://dpdk.org/browse/dpdk/commit/?id=ee1843b
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > > > > It happens only with old QEMU emulation (I repro it with 
> > > > > > > > “pc-1.0”) which
VIRL uses.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Fix (revert) is in gerrit:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > https://gerrit.fd.io/r/#/c/6690/
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Regards,
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Damjan
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > > > > > > > > > > On 13 May 2017, at 20:34, Neale Ranns (nranns) 
> > > > > > > > > > > > > > > 
wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Hi Chris,
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Yes, every CSIT job on master is borked.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > > > > > > > > > > I think I’ve narrowed this down to all VAT 
> > > > > > > > > > > > > > > sw_interface_dump returning
bogus/garbage MAC addresses. No Idea why, can’t repro yet. I’ve a
speculative DPDK 17.05 bump backout job in the queue, for
> > > > >  purposes of elimination.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > /neale
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > > > > > > From: "Luke, Chris" 
> > > > > > 
> > > > > > Date: Saturday, 13 May 2017 at 19:04
> > > > > > 
> > > > > > > > > > > > > > > > > > To: "Neale Ranns (nranns)" 
> > > > > > > > > > > > > > > > > > , "yug...@telincn.com"
> > > > > > > > > > > > > > > > > >  , vpp-dev 
> > > > > > > > > > > > > > > > > > 
> > > > > > 
> > > > > > > > > > > > Subject: RE: [vpp-dev] Segmentation fault in recursivly 
> > > > > > > > > > > > lookuping
fib entry.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 

Re: [vpp-dev] CSIT borked on master

[Damjan Marion (damarion)]

“recheck" will not be enough. All patches must be rebased so they pick up my 
fix...

On 15 May 2017, at 13:38, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:


Hi Marco,

I’ll restart the jobs once we’ve got them passing again.

For your reference, you can do it manually by typing ‘recheck’ as a code review 
comment in gerrit.

regards,
neale

From: Marco Varlese mailto:marco.varl...@suse.com>>
Date: Monday, 15 May 2017 at 12:17
To: "Damjan Marion (damarion)" mailto:damar...@cisco.com>>, 
"Neale Ranns (nranns)" mailto:nra...@cisco.com>>
Cc: "csit-...@lists.fd.io" 
mailto:csit-...@lists.fd.io>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] CSIT borked on master

Hi Damjan,

Once you're patch is merged, is it possible to kick off the builds which 
currently are all marked as Verified-1 so to have a clean state on them?

If I could do that manually I would do it at least for mine.


Thanks,
Marco

On Mon, 2017-05-15 at 10:54 +, Damjan Marion (damarion) wrote:

This issue is caused by bug in DPDK 17.05 caused by following commit:

http://dpdk.org/browse/dpdk/commit/?id=ee1843b

It happens only with old QEMU emulation (I repro it with “pc-1.0”) which VIRL 
uses.

Fix (revert) is in gerrit:

https://gerrit.fd.io/r/#/c/6690/

Regards,

Damjan


On 13 May 2017, at 20:34, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:


Hi Chris,

Yes, every CSIT job on master is borked.
I think I’ve narrowed this down to all VAT sw_interface_dump returning 
bogus/garbage MAC addresses. No Idea why, can’t repro yet. I’ve a speculative 
DPDK 17.05 bump backout job in the queue, for purposes of elimination.

Regards,
/neale



From: "Luke, Chris" mailto:chris_l...@comcast.com>>
Date: Saturday, 13 May 2017 at 19:04
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, 
"yug...@telincn.com" 
mailto:yug...@telincn.com>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

CSIT seems to be barfing on every job at the moment :(

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Neale Ranns (nranns)
Sent: Saturday, May 13, 2017 11:20
To: yug...@telincn.com; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.


https://gerrit.fd.io/r/#/c/6674/

/neale

From: "yug...@telincn.com" 
mailto:yug...@telincn.com>>
Date: Saturday, 13 May 2017 at 14:24
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

Hi neale,
Could you leave me a msg then?

Thanks,
Ewan


yug...@telincn.com

From: Neale Ranns (nranns)
Date: 2017-05-13 20:33
To: yug...@telincn.com; 
vpp-dev
Subject: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.
Hi Ewan,

That’s a bug. I’ll fix it ASAP.

Thanks,
neale

From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of "yug...@telincn.com" 
mailto:yug...@telincn.com>>
Date: Saturday, 13 May 2017 at 03:24
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

Hi, all
Below are my main configs, others are default.
When i knock into this cmd  "vppctl ip route 0.0.0.0/0 via 10.10.40.1" to add 
one default route,
the vpp crashed, it looks like this func fib_entry_get_resolving_interface call 
itself recursivly  till vpp's crash.
Is there something wrong?




config  info
root@ubuntu:/usr/src/1704/VBRASV100R001/vpp1704/build-root# vppctl show int addr
GigabitEthernet2/6/0 (up):
  192.168.60.1/24
GigabitEthernet2/7/0 (up):
  10.10.55.51/24
host-vGE2_6_0 (up):
host-vGE2_7_0 (up):
local0 (dn):




root@ubuntu:/usr/src/1704/VBRASV100R001/vpp1704/build-root# vppctl show ip fib
ipv4-VRF:0, fib_index 0, flow hash: src dst sport dport proto
0.0.0.0/0
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:0 buckets:1 uRPF:0 to:[142:12002]]
[0] [@0]: dpo-drop ip4
0.0.0.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:1 buckets:1 uRPF:1 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.10.55.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:10 buckets:1 uRPF:9 to:[0:0]]
[0] [@4]: ipv4-glean: GigabitEthernet2/7/0
10.10.55.51/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:11 buckets:1 uRPF:10 to:[0:0]]
[0] [@2]: dpo-receive: 10.10.55.51 on GigabitEthernet2/7/0
192.168.60.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:8 buckets:1 uRPF:7 to:[0:0]]
[0] [@4]: ipv4-glean: GigabitEthernet2/6/0
192.168.60.1/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:9 buckets:1 uRPF:8 to

Re: [vpp-dev] CSIT borked on master

[Neale Ranns (nranns)]

Hi Marco,

I’ll restart the jobs once we’ve got them passing again.

For your reference, you can do it manually by typing ‘recheck’ as a code review 
comment in gerrit.

regards,
neale

From: Marco Varlese 
Date: Monday, 15 May 2017 at 12:17
To: "Damjan Marion (damarion)" , "Neale Ranns (nranns)" 

Cc: "csit-...@lists.fd.io" , vpp-dev 
Subject: Re: [vpp-dev] CSIT borked on master

Hi Damjan,

Once you're patch is merged, is it possible to kick off the builds which 
currently are all marked as Verified-1 so to have a clean state on them?

If I could do that manually I would do it at least for mine.


Thanks,
Marco

On Mon, 2017-05-15 at 10:54 +, Damjan Marion (damarion) wrote:

This issue is caused by bug in DPDK 17.05 caused by following commit:

http://dpdk.org/browse/dpdk/commit/?id=ee1843b

It happens only with old QEMU emulation (I repro it with “pc-1.0”) which VIRL 
uses.

Fix (revert) is in gerrit:

https://gerrit.fd.io/r/#/c/6690/

Regards,

Damjan


On 13 May 2017, at 20:34, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:


Hi Chris,

Yes, every CSIT job on master is borked.
I think I’ve narrowed this down to all VAT sw_interface_dump returning 
bogus/garbage MAC addresses. No Idea why, can’t repro yet. I’ve a speculative 
DPDK 17.05 bump backout job in the queue, for purposes of elimination.

Regards,
/neale



From: "Luke, Chris" mailto:chris_l...@comcast.com>>
Date: Saturday, 13 May 2017 at 19:04
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, 
"yug...@telincn.com" 
mailto:yug...@telincn.com>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

CSIT seems to be barfing on every job at the moment :(

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Neale Ranns (nranns)
Sent: Saturday, May 13, 2017 11:20
To: yug...@telincn.com; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.


https://gerrit.fd.io/r/#/c/6674/

/neale

From: "yug...@telincn.com" 
mailto:yug...@telincn.com>>
Date: Saturday, 13 May 2017 at 14:24
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

Hi neale,
Could you leave me a msg then?

Thanks,
Ewan


yug...@telincn.com

From: Neale Ranns (nranns)
Date: 2017-05-13 20:33
To: yug...@telincn.com; 
vpp-dev
Subject: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.
Hi Ewan,

That’s a bug. I’ll fix it ASAP.

Thanks,
neale

From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of "yug...@telincn.com" 
mailto:yug...@telincn.com>>
Date: Saturday, 13 May 2017 at 03:24
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

Hi, all
Below are my main configs, others are default.
When i knock into this cmd  "vppctl ip route 0.0.0.0/0 via 10.10.40.1" to add 
one default route,
the vpp crashed, it looks like this func fib_entry_get_resolving_interface call 
itself recursivly  till vpp's crash.
Is there something wrong?




config  info
root@ubuntu:/usr/src/1704/VBRASV100R001/vpp1704/build-root# vppctl show int addr
GigabitEthernet2/6/0 (up):
  192.168.60.1/24
GigabitEthernet2/7/0 (up):
  10.10.55.51/24
host-vGE2_6_0 (up):
host-vGE2_7_0 (up):
local0 (dn):




root@ubuntu:/usr/src/1704/VBRASV100R001/vpp1704/build-root# vppctl show ip fib
ipv4-VRF:0, fib_index 0, flow hash: src dst sport dport proto
0.0.0.0/0
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:0 buckets:1 uRPF:0 to:[142:12002]]
[0] [@0]: dpo-drop ip4
0.0.0.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:1 buckets:1 uRPF:1 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.10.55.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:10 buckets:1 uRPF:9 to:[0:0]]
[0] [@4]: ipv4-glean: GigabitEthernet2/7/0
10.10.55.51/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:11 buckets:1 uRPF:10 to:[0:0]]
[0] [@2]: dpo-receive: 10.10.55.51 on GigabitEthernet2/7/0
192.168.60.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:8 buckets:1 uRPF:7 to:[0:0]]
[0] [@4]: ipv4-glean: GigabitEthernet2/6/0
192.168.60.1/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:9 buckets:1 uRPF:8 to:[60:3600]]
[0] [@2]: dpo-receive: 192.168.60.1 on GigabitEthernet2/6/0
192.168.60.30/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:12 buckets:1 uRPF:11 to:[60:3600]]
[0] [@5]: ipv4 via 192.168.60.30 GigabitEthernet2/6/0: 
f44d3016eac1000c2904f74e0800
224.0.0.0/4
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:3 buc

Re: [vpp-dev] CSIT borked on master

[Marco Varlese]

Hi Damjan,

Once you're patch is merged, is it possible to kick off the builds which
currently are all marked as Verified-1 so to have a clean state on them?

If I could do that manually I would do it at least for mine.


Thanks,
Marco

On Mon, 2017-05-15 at 10:54 +, Damjan Marion (damarion) wrote:
> 
> 
> 
> 
> 
> This issue is caused by bug in DPDK 17.05 caused by following commit:
> 
> 
> 
> 
> 
> http://dpdk.org/browse/dpdk/commit/?id=ee1843b
> 
> 
> 
> 
> 
> > It happens only with old QEMU emulation (I repro it with “pc-1.0”) which 
> > VIRL
uses.
> 
> 
> 
> 
> 
> Fix (revert) is in gerrit:
> 
> 
> 
> 
> 
> https://gerrit.fd.io/r/#/c/6690/
> 
> 
> 
> 
> 
> Regards,
> 
> 
> 
> 
> 
> Damjan
> 
> 
> 
> 
> 
> 
> 
> 
> > > > On 13 May 2017, at 20:34, Neale Ranns (nranns)  wrote:
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > Hi Chris,
> > 
> > 
> >  
> > 
> > 
> > Yes, every CSIT job on master is borked.
> > 
> > 
> > > > > > I think I’ve narrowed this down to all VAT sw_interface_dump 
> > > > > > returning
bogus/garbage MAC addresses. No Idea why, can’t repro yet. I’ve a
speculative DPDK 17.05 bump backout job in the queue, for
> >  purposes of elimination.
> > 
> > 
> >  
> > 
> > 
> > Regards,
> > 
> > 
> > /neale
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> > 
> >  
> > 
> > > 
> > > 
> > > > > > From: "Luke, Chris" 
> > > 
> > > Date: Saturday, 13 May 2017 at 19:04
> > > 
> > > > > > > > > To: "Neale Ranns (nranns)" , 
> > > > > > > > > "yug...@telincn.com"
> > > > > > > > >  , vpp-dev 
> > > 
> > > > > > Subject: RE: [vpp-dev] Segmentation fault in recursivly lookuping 
> > > > > > fib
entry.
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > CSIT seems to be barfing on every job at the moment :(
> > > 
> > > 
> > >  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > > > > > > > From: vpp-dev-boun...@lists.fd.io 
> > > > > > > > > [mailto:vpp-dev-boun...@lists.fd.io] On
> > >  Behalf Of Neale Ranns (nranns)
> > > 
> > > Sent: Saturday, May 13, 2017 11:20
> > > 
> > > > > > > > > To: yug...@telincn.com; vpp-dev 
> > > 
> > > > > > Subject: Re: [vpp-dev] Segmentation fault in recursivly lookuping 
> > > > > > fib
entry.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >  
> > > 
> > > 
> > >  
> > > 
> > > 
> > > https://gerrit.fd.io/r/#/c/6674/
> > > 
> > > 
> > >  
> > > 
> > > 
> > > /neale
> > > 
> > > 
> > >  
> > > 
> > > > 
> > > > 
> > > > > > > > From: "yug...@telincn.com"
> > > > > > > >  
> > > > 
> > > > Date: Saturday, 13 May 2017 at 14:24
> > > > 
> > > > > > > > > > > > To: "Neale Ranns (nranns)" , vpp-dev 
> > > > > > > > > > > > 
> > > > 
> > > > > > > > Subject: Re: Re: [vpp-dev] Segmentation fault in recursivly 
> > > > > > > > lookuping
fib entry.
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Hi neale,
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Could you leave me a msg then?
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Thanks,
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Ewan
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > yug...@telincn.com
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > From: Neale
> > > > >  Ranns (nranns)
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Date: 2017-05-13 20:33
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > > > > > To: yug...@telincn.com; vpp-dev
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > > > > > Subject: Re: [vpp-dev] Segmentation fault in recursivly 
> > > > > > > > > > lookuping fib
entry.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > Hi Ewan,
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > That’s a bug. I’ll fix it ASAP.
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > 
> > > > > neale
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > > > > > > From: 
> > > > > > > > > > > > > > > > > >  on behalf of "yug...@telincn.com" 
> > > > > > > > > > > > > > > > > > 
> > > > > > 
> > > > > > Date: Saturday, 13 May 2017 at 03:24
> > > > > > 
> > > > > > > > > > > > To: vpp-dev 
> > > > > > 
> > > > > > > > > > > > Subject: [vpp-dev] Segmentation fault in recursivly 
> > > > > > > > > > > > lookuping fib
entry.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hi, all
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Below are my main config

Re: [vpp-dev] Ip fragment reassembly

[Kinsella, Ray]

Hi Xyxue,

Please try

https://gerrit.fd.io/r/#/c/6695/

And see if it resolves your issue.

Ray K

On 10/05/2017 13:35, 薛欣颖 wrote:

Hi guys,

Whether vpp support ip fragment reassembly on host-interface?
Can I use only" set interface mtu 2000 host-eth2 "to set mtu.

Here's my test result:
vpp+dpdk:
mtu 1500  when the packet size 1500+  it  dropped;
mtu 2000  when the packet size 2000+  it  dropped;
mtu 300  when the packet size < 1500 it passed;
no fragmentation in my test;
vpp without dpdk:
Configuring MTU is not effective.

Thanks,
xyxue


___
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 borked on master

[Damjan Marion (damarion)]

This issue is caused by bug in DPDK 17.05 caused by following commit:

http://dpdk.org/browse/dpdk/commit/?id=ee1843b

It happens only with old QEMU emulation (I repro it with “pc-1.0”) which VIRL 
uses.

Fix (revert) is in gerrit:

https://gerrit.fd.io/r/#/c/6690/

Regards,

Damjan


On 13 May 2017, at 20:34, Neale Ranns (nranns) 
mailto:nra...@cisco.com>> wrote:


Hi Chris,

Yes, every CSIT job on master is borked.
I think I’ve narrowed this down to all VAT sw_interface_dump returning 
bogus/garbage MAC addresses. No Idea why, can’t repro yet. I’ve a speculative 
DPDK 17.05 bump backout job in the queue, for purposes of elimination.

Regards,
/neale



From: "Luke, Chris" mailto:chris_l...@comcast.com>>
Date: Saturday, 13 May 2017 at 19:04
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, 
"yug...@telincn.com" 
mailto:yug...@telincn.com>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: RE: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

CSIT seems to be barfing on every job at the moment :(

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Neale Ranns (nranns)
Sent: Saturday, May 13, 2017 11:20
To: yug...@telincn.com; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.


https://gerrit.fd.io/r/#/c/6674/

/neale

From: "yug...@telincn.com" 
mailto:yug...@telincn.com>>
Date: Saturday, 13 May 2017 at 14:24
To: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>, vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Subject: Re: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

Hi neale,
Could you leave me a msg then?

Thanks,
Ewan


yug...@telincn.com

From: Neale Ranns (nranns)
Date: 2017-05-13 20:33
To: yug...@telincn.com; 
vpp-dev
Subject: Re: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.
Hi Ewan,

That’s a bug. I’ll fix it ASAP.

Thanks,
neale

From: mailto:vpp-dev-boun...@lists.fd.io>> on 
behalf of "yug...@telincn.com" 
mailto:yug...@telincn.com>>
Date: Saturday, 13 May 2017 at 03:24
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] Segmentation fault in recursivly lookuping fib entry.

Hi, all
Below are my main configs, others are default.
When i knock into this cmd  "vppctl ip route 0.0.0.0/0 via 10.10.40.1" to add 
one default route,
the vpp crashed, it looks like this func fib_entry_get_resolving_interface call 
itself recursivly  till vpp's crash.
Is there something wrong?



config  info
root@ubuntu:/usr/src/1704/VBRASV100R001/vpp1704/build-root# vppctl show int addr
GigabitEthernet2/6/0 (up):
  192.168.60.1/24
GigabitEthernet2/7/0 (up):
  10.10.55.51/24
host-vGE2_6_0 (up):
host-vGE2_7_0 (up):
local0 (dn):



root@ubuntu:/usr/src/1704/VBRASV100R001/vpp1704/build-root# vppctl show ip fib
ipv4-VRF:0, fib_index 0, flow hash: src dst sport dport proto
0.0.0.0/0
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:0 buckets:1 uRPF:0 to:[142:12002]]
[0] [@0]: dpo-drop ip4
0.0.0.0/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:1 buckets:1 uRPF:1 to:[0:0]]
[0] [@0]: dpo-drop ip4
10.10.55.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:10 buckets:1 uRPF:9 to:[0:0]]
[0] [@4]: ipv4-glean: GigabitEthernet2/7/0
10.10.55.51/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:11 buckets:1 uRPF:10 to:[0:0]]
[0] [@2]: dpo-receive: 10.10.55.51 on GigabitEthernet2/7/0
192.168.60.0/24
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:8 buckets:1 uRPF:7 to:[0:0]]
[0] [@4]: ipv4-glean: GigabitEthernet2/6/0
192.168.60.1/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:9 buckets:1 uRPF:8 to:[60:3600]]
[0] [@2]: dpo-receive: 192.168.60.1 on GigabitEthernet2/6/0
192.168.60.30/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:12 buckets:1 uRPF:11 to:[60:3600]]
[0] [@5]: ipv4 via 192.168.60.30 GigabitEthernet2/6/0: 
f44d3016eac1000c2904f74e0800
224.0.0.0/4
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:3 buckets:1 uRPF:3 to:[0:0]]
[0] [@0]: dpo-drop ip4
240.0.0.0/4
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:2 buckets:1 uRPF:2 to:[0:0]]
[0] [@0]: dpo-drop ip4
255.255.255.255/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [index:4 buckets:1 uRPF:4 to:[0:0]]
[0] [@0]: dpo-drop ip4

root@ubuntu:/usr/src/1704/VBRASV100R001/vpp1704/build-root#






Thread 1 "vpp_main" received signal SIGSEGV, Segmentation fault.
fib_entry_get_resolving_interface (entry_index=12) at 
/usr/src/1704/VBRASV100R001/vpp1704/build-data/../src/vnet/fib/fib_entry.c:1325
1325 fib_entry = fib_entry_get(entry_index);
(gdb)





#97831 0x7fe5435a36a8 in fib_path_get_resolving_interface 
(p

Re: [vpp-dev] VPP kni related query

[Damjan Marion (damarion)]

Please avoid unicast emails. Adding vpp-dev@
lists.fd.io
> On 15 May 2017, at 10:33, bindiya Kurle  wrote:
> 
> 
> Hi,
> 
> Was going through KNI code in VPP. As part of below change set, ki support 
> was removed from VPP.Any specific reasons to remove it.

Code was incomplete and outdated. Nobody was maintaining it.

> In our program applications listens on standard sockets.Hence we need this so 
> that application code will not change. Was this use case considered or there 
> is an alternative approach to this ?

Have you considered using linux packet interface (af-packet). Debug cli command 
is “create host-interface name ” ?

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

Re: [vpp-dev] VPP and SR-IOV(?): No packets reaching VPP interfaces

[Damjan Marion (damarion)]

Yes, they are, That’s why it starts working….

On 15 May 2017, at 08:58, Tomas Brännström 
mailto:tomas.a.brannst...@tieto.com>> wrote:

Would the MTU settings be related to the max_rx_pktlen? Since as I mentioned in 
the other mail when I lowered it to 1500 as per Avinash's advice the packets 
are no longer dropped.

/T

On 12 May 2017 at 20:05, Damjan Marion (damarion) 
mailto:damar...@cisco.com>> wrote:



On 12 May 2017, at 17:34, Tomas Brännström 
mailto:tomas.a.brannst...@tieto.com>> wrote:

Hm, OK.

I did a search for the HW CRC message earlier and it sounded like the message 
was just for information and had no real functional impact, but maybe it does.. 
(http://dpdk.org/dev/patchwork/patch/12080/)

Looks like on ixgbevf it is informational but on i40evf config fails.



Would there be a workaround outside  VPP for 2. somehow?

I’m still trying to understand what’s wrong. I have simple dpdk application 
which just dumps rx packets and by simply increasing .max_rx_pkt_len it stops 
working.
On the same time rte_eth_dev_info_get() says:

(gdb) p dev_info
$1 = {
 pci_dev = 0x55873740,
 driver_name = 0x7fffb4c51b67 "net_ixgbe_vf",
 if_index = 0,
 min_rx_bufsize = 1024,
 max_rx_pktlen = 9728,

So max_rx_pktlen is even bigger than what I set in .max_rx_pkt_len….


/Tomas

On 12 May 2017 at 16:30, Damjan Marion (damarion) 
mailto:damar...@cisco.com>> wrote:

There are 2 problems:

1. HW CRC strip needs to be enabled for VFs, that’s why DPDK is failing to init 
device
2. VFs are dropping packets when .max_rx_pkt_len is set to 9216

Problem 1. is easy fixable by changing .hw_strip_crc to 1 in 
src/plugins/dpdk/device/init.c

Problem 2. seems to be outside of VPP control, but it can be workarounded by 
setting .max_rx_pkt_len to 1518. consequence of doing this is that we will  
(likely) loose jumbo frame support on VFs.

I’m going to submit patch which fixes both issues soon (actually workarounds 2. 
), I need to play a bit more with 2. first...



On 12 May 2017, at 12:08, Tomas Brännström 
mailto:tomas.a.brannst...@tieto.com>> wrote:

Unfortunately my MTU seems to be at 1500 already.

I did an upgrade to release 1704 and now none of the interfaces are discovered 
anymore. But it seems suspicious since there are basically no log printouts at 
startup either, below are 1701 vs 1704 for comparision. This isn't exclusive 
for this "SR-IOV" machine either I think, when running later VPP in for example 
virtual box I get the same problems, so I guess there's something additional 
that must be done that's maybe not documented on the wiki yet.

17.01:
--
vlib_plugin_early_init:213: plugin path /usr/lib/vpp_plugins
vpp[5066]: vlib_pci_bind_to_uio: Skipping PCI device :00:03.0 as host 
interface eth0 is up
EAL: Detected 4 lcore(s)
EAL: No free hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using unreliable 
clock cycles !
EAL: PCI device :00:03.0 on NUMA socket -1
EAL:   Device is blacklisted, not initializing
EAL: PCI device :00:06.0 on NUMA socket -1
EAL:   probe driver: 8086:10ed net_ixgbe_vf
EAL: PCI device :00:07.0 on NUMA socket -1
EAL:   probe driver: 8086:10ed net_ixgbe_vf
DPDK physical memory layout:
Segment 0: phys:0x5cc0, len:2097152, virt:0x7f7e0b80, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
Segment 1: phys:0x5d00, len:266338304, virt:0x7f7db160, socket_id:0, 
hugepage_sz:2097152, nchannel:0, nrank:0
PMD: ixgbevf_dev_configure(): VF can't disable HW CRC Strip
PMD: ixgbevf_dev_configure(): VF can't disable HW CRC Strip

17.04:
--
vlib_plugin_early_init:360: plugin path /usr/lib/vpp_plugins

/Tomas

On 12 May 2017 at 11:49, Gonsalves, Avinash (Nokia - IN/Bangalore) 
mailto:avinash.gonsal...@nokia.com>> wrote:

I faced a similar issue with SR-IOV, and for some reason setting the MTU size 
to 1500 on the interface helped with ARP resolution.



Thanks,
Avinash







Thanks. I can try to use a later VPP version. A thing to note is that when

we did try to use the master release before, VPP failed to discover

interfaces, even when they were whitelisted. Not sure if something has

changed in the way VPP discover interfaces in later versions. I will try

with 1704 though.



Ah OK sorry, should have realized what PF was in this context. Not sure of

all the info that might be needed but here's what I could think of:



root at node-4:~# lspci -t -v

[...]

 +-03.0-[0b-0c]--+-00.0  Intel Corporation 82599ES 10-Gigabit

SFI/SFP+ Network Connection

 |   +-00.1  Intel Corporation 82599ES 10-Gigabit

SFI/SFP+ Network Connection

 |   +-10.0  Intel Corporation 82599 Ethernet

Controller Virtual Function

 |   +-10.1  Intel Corporation 82599 Ethernet

Controller Virtual F