date:20170820

Re: [vpp-dev] Set up MPLS via jvpp

2017-08-20 Thread Andrej Mak


Hi Neale,

I’ve tested it without Honeycomb, I’ve just created simple jvpp app with 
IpAddDelRoute request as stated bellow.

Here is the entry created via jvpp:

vpp# sh ip fib index 2 10.10.2.3/32 detail
ipv4-VRF:2, fib_index:2, flow hash:[src dst sport dport proto ] locks:1
10.10.2.3/32 fib:2 index:40 locks:2
  src:API  refs:1
index:42 locks:2 flags:shared, uPRF-list:44 len:1 itfs:[1, ]
  index:42 pl-index:42 MPLS weight=1 attached-nexthop:  oper-flags:resolved,
   10.10.1.2 host-veth11
  [@0]: arp-mpls: via 10.10.1.2 host-veth11
Extensions:
 path:-1 labels:2003
 forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:44 buckets:1 uRPF:44 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.1.2 host-veth11
Delegates:
Children:

And here is the entry created via CLI:

vpp# sh ip fib index 1 10.10.2.3/32 detail
ipv4-VRF:1, fib_index:1, flow hash:[src dst sport dport proto ] locks:2
10.10.2.3/32 fib:1 index:24 locks:4
  src:CLI  refs:1
index:21 locks:4 flags:shared, uPRF-list:19 len:1 itfs:[1, ]
  index:21 pl-index:21 ipv4 weight=1 attached-nexthop:  oper-flags:resolved,
   10.10.1.2 host-veth11
  [@0]: arp-ipv4: via 10.10.1.2 host-veth11
Extensions:
 path:21 labels:1003
  src:recursive-resolution cover:-1 refs:1

forwarding:   unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:27 buckets:1 uRPF:19 to:[0:0]]
[0] [@10]: mpls-label:[1]:[1003:255:0:eos]
[@1]: arp-mpls: via 10.10.1.2 host-veth11
Delegates:
  mpls-neos-chain
  [@0]: dpo-load-balance: [proto:mpls index:32 buckets:1 uRPF:19 to:[0:0]]
[0] [@7]: mpls-label:[2]:[1003:255:0:neos]
[@1]: arp-mpls: via 10.10.1.2 host-veth11
Children:{path:31}

Thanks
Andrej
From: Neale Ranns (nranns) [mailto:nra...@cisco.com]
Sent: Friday, August 18, 2017 11:13 AM
To: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) 
; Andrej Mak ; vpp-dev@lists.fd.io
Subject: Re: Set up MPLS via jvpp


Hi Marek,

I don’t see anything wrong with the construction of the request.

Can you please show me the HC logs of the message sent and also
  sh ip fib index 2 10.10.2.3/32 detail

this API is used a lot in the unit-tests so I have some confidence that works 
under normal circumstances

regards,
neale

From: "Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)" 
mailto:mgrad...@cisco.com>>
Date: Friday, 18 August 2017 at 06:00
To: Andrej Mak mailto:andrej@pantheon.tech>>, 
"vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Cc: "Neale Ranns (nranns)" mailto:nra...@cisco.com>>
Subject: RE: Set up MPLS via jvpp

Hi,

So I was wrong. I haven’t noticed next_hop_n_out_labels is u8…
Neal: any idea why labels are not added?

Regards,
Marek

From: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco)
Sent: 17 sierpnia 2017 12:17
To: 'Andrej Mak' mailto:andrej@pantheon.tech>>; 
vpp-dev@lists.fd.io
Cc: Neale Ranns (nranns) mailto:nra...@cisco.com>>
Subject: RE: Set up MPLS via jvpp

Hi,

I think it is a bug in the C handler of the ip_add_del_route message.
Byte order for next_hop_n_out_labels is not flipped.

Please check if this fixes the issue:
https://gerrit.fd.io/r/#/c/8080/


Regards,
Marek


From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Andrej Mak
Sent: 17 sierpnia 2017 11:03
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Set up MPLS via jvpp

Hi all,

I would like to set mpls via java api, but I have some problems with it.
I want to do java calls equal to this

ip route add 10.10.2.3/32 table 1 via 10.10.1.2 host-veth out-label 1003

which creates this entry in show ip fib index 1

10.10.2.3/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:27 buckets:1 uRPF:19 to:[0:0]]
[0] [@10]: mpls-label:[1]:[1003:255:0:eos]
[@1]: arp-mpls: via 10.10.1.2 host-veth11

so I create DTO, which sets fields matching parameters in CLI command:

IpAddDelRoute addRoute = new IpAddDelRoute();
addRoute.isAdd = 1;
addRoute.tableId = 2;
final Ipv4Prefix prefix = new Ipv4Prefix((„10.10.2.3/32“);
addRoute.dstAddress = 
Ipv4Translator.INSTANCE.ipv4AddressPrefixToArray(prefix);
addRoute.dstAddressLength = 
Ipv4Translator.INSTANCE.extractPrefix(prefix);
addRoute.nextHopAddress = 
Ipv4Translator.INSTANCE.ipv4AddressNoZoneToArray(„10.10.1.2“);
addRoute.nextHopSwIfIndex = 1;
int[] labels = new int[1];
labels[0] = 1003;
addRoute.nextHopNOutLabels = (byte) labels.length;
addRoute.nextHopOutLabelStack = labels;
api.ipAddDelRoute(addRoute).toCompletableFuture().get()

but show ip fib index 2 shows different result
10.10.2.3/32
  unicast-ip4-chain
  [@0]: dpo-load-balance: [proto:ip4 index:44 buckets:1 uRPF:44 to:[0:0]]
[0] [@3]: arp-ipv4: via 10.10.1.2 host-veth11

Is it a bug, or am I doing something wron

Re: [vpp-dev] VPP Communications library and LD_PRELOAD

2017-08-20 Thread Dave Wallace


Danny,

You are correct that the current testing has been focused on 
inter-container testing on the same host.  I will be working on 
verifying that the inter-host communication path is fully function using 
the vppcom library this week.


Thanks,
-daw-

On 08/20/2017 11:53 PM, Zhou, Danny wrote:


Hi Keith,

This is really interesting work!

Does the vppcom library underneath the VCL supports inter-host 
communication? The iperf3 throughput data below is for the 
inter-container (essentially IPC over FIFO) on the same host, right?


-Danny

*From:*vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] *On Behalf Of *Keith Burns

*Sent:* Friday, August 18, 2017 4:35 AM
*To:* vpp-dev 
*Cc:* shrinivasanganapa...@gmail.com
*Subject:* [vpp-dev] VPP Communications library and LD_PRELOAD

Folks,

Happy to be able to share the latest on where we are at with the VPP 
communications library (VCL) and a matching POSIX Socket LD_PRELOAD 
library for container networking.


On a Haswell 3.5GHz machine, running Brent Salisbury's 
"networkstatic/iperf3" Docker image:


- running using default kernel networking == 7.8 Gbps

- running using LD_PRELOAD with VCL (VPP Communications Library) == 
132.0 Gbps


To demo:

1. Clone LD_PRELOAD from the VPPSB project

a) git clone https://gerrit.fd.io/r/vppsb 

b) Follow instructions in

 .../vcl-ldpreload/README.md

2. For your convenience, Dave Wallace has created a test script in in 
the fd.io  VPP Master branch in 
.../vpp/test/scripts/socket_test.sh


make build-release

IMPORTANT! You will not get desired results with a DEBUG image (i.e. 
make build).


c) Run .../vpp/test/scripts/socket_test.sh with no parameters will 
give a menu of options.


- for iperf3 Docker test run with native kernel networking

./socket_test.sh -tbi docker-kernel

- for testing with LD_PRELOAD and VCL:

./socket_test.sh -tbi docker-preload

I'd like to submit a project proposal for the VPPSB VCL-Preload 
library, so folks can contribute and modify it to suit their usecases 
etc. If anyone is interested in participating, drop me an email.




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


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

Re: [vpp-dev] VPP Communications library and LD_PRELOAD

2017-08-20 Thread Zhou, Danny

Hi Keith,

This is really interesting work!

Does the vppcom library underneath the VCL supports inter-host communication? 
The iperf3 throughput data below is for the inter-container (essentially IPC 
over FIFO) on the same host, right?

-Danny

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Keith Burns
Sent: Friday, August 18, 2017 4:35 AM
To: vpp-dev 
Cc: shrinivasanganapa...@gmail.com
Subject: [vpp-dev] VPP Communications library and LD_PRELOAD

Folks,

Happy to be able to share the latest on where we are at with the VPP 
communications library (VCL) and a matching POSIX Socket LD_PRELOAD library for 
container networking.

On a Haswell 3.5GHz machine, running Brent Salisbury's "networkstatic/iperf3" 
Docker image:
- running using default kernel networking == 7.8 Gbps
- running using LD_PRELOAD with VCL (VPP Communications Library) == 132.0 Gbps


To demo:
1. Clone LD_PRELOAD from the VPPSB project
a) git clone https://gerrit.fd.io/r/vppsb
b) Follow instructions in
   .../vcl-ldpreload/README.md

2. For your convenience, Dave Wallace has created a test script in in the 
fd.io VPP Master branch in .../vpp/test/scripts/socket_test.sh
make build-release
IMPORTANT! You will not get desired results with a DEBUG image (i.e. make 
build).

c) Run .../vpp/test/scripts/socket_test.sh with no parameters will give a menu 
of options.
- for iperf3 Docker test run with native kernel networking
./socket_test.sh -tbi docker-kernel
- for testing with LD_PRELOAD and VCL:
./socket_test.sh -tbi docker-preload

I'd like to submit a project proposal for the VPPSB VCL-Preload library, so 
folks can contribute and modify it to suit their usecases etc. If anyone is 
interested in participating, drop me an email.






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

[vpp-dev] 答复: [discuss] Question about VPP support for ARM 64

2017-08-20 Thread George Zhao

Hi Damian,

IT is Applied Micro overdrive 1000, here are the uname -a output:

$>> uname -a
Linux OD1K 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:10:33 UTC 2017 
aarch64 aarch64 aarch64 GNU/Linux

thanks
George
发件人：Damjan Marion (damarion)
收件人：George Zhao
抄送：dbarach,discuss,csit-dev,vpp-dev
时间：2017-08-20 10:03:27
主题:Re: [vpp-dev] [discuss] Question about VPP support for ARM 64



George, are you using ThunderX platform?

I spent few hours today trying to install latest ubuntu on my ThunderX system 
but no luck, kernel hangs at some point, both ubuntu provided and manually 
compiled.

Can you share about more details about your system?

Thanks,

Damjan



> On 19 Aug 2017, at 22:48, George Zhao  wrote:
>
> If a bug is filed, may I have the bug number, I would be love to trace this 
> patch.
>
> BTW, how do I file a bug for VPP, I did a quick wiki search with no luck.
>
> Thanks,
> George
>
> -Original Message-
> From: Dave Barach (dbarach) [mailto:dbar...@cisco.com]
> Sent: Saturday, August 19, 2017 7:42 AM
> To: George Zhao 
> Cc: vpp-dev@lists.fd.io; disc...@lists.fd.io; csit-...@lists.fd.io; Damjan 
> Marion (damarion) 
> Subject: RE: [discuss] Question about VPP support for ARM 64
>
> +1, pls add the typedef...
>
> Thanks… Dave
>
> -Original Message-
> From: Damjan Marion (damarion)
> Sent: Saturday, August 19, 2017 9:09 AM
> To: Dave Barach (dbarach) 
> Cc: George Zhao ; vpp-dev@lists.fd.io; 
> disc...@lists.fd.io; csit-...@lists.fd.io
> Subject: Re: [discuss] Question about VPP support for ARM 64
>
>
> GCC is able to compile ARM64 code with 256-bit vectors even if target 
> platform have only 128-bit registers.
>
> I.e. for the u8x32 version of that function it generates:
>
> ARM64:
> dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
>ld1 {v0.16b - v1.16b}, [x4], 32
>st1 {v0.16b - v1.16b}, [x3], 32
>st1 {v0.16b - v1.16b}, [x2], 32
>st1 {v0.16b - v1.16b}, [x1], 32
>st1 {v0.16b - v1.16b}, [x0], 32
>ld1 {v0.16b - v1.16b}, [x4]
>st1 {v0.16b - v1.16b}, [x3]
>st1 {v0.16b - v1.16b}, [x2]
>st1 {v0.16b - v1.16b}, [x1]
>st1 {v0.16b - v1.16b}, [x0]
>ret
>
> intel x86-64 without AVX2:
>
> dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
> push   %rbp
> mov%rsp,%rbp
> and$0xffe0,%rsp
> lea0x10(%rsp),%rsp
> movdqa (%r8),%xmm1
> movdqa 0x10(%r8),%xmm0
> movdqa %xmm0,0x10(%rcx)
> movdqa %xmm1,(%rcx)
> movdqa %xmm1,(%rdx)
> movdqa %xmm0,0x10(%rdx)
> movdqa %xmm1,(%rsi)
> movdqa %xmm0,0x10(%rsi)
> movdqa %xmm1,(%rdi)
> movdqa %xmm0,0x10(%rdi)
> movdqa 0x20(%r8),%xmm1
> movdqa 0x30(%r8),%xmm0
> movdqa %xmm0,0x30(%rcx)
> movdqa %xmm1,0x20(%rcx)
> movdqa %xmm1,0x20(%rdx)
> movdqa %xmm0,0x30(%rdx)
> movdqa %xmm1,0x20(%rsi)
> movdqa %xmm0,0x30(%rsi)
> movdqa %xmm1,0x20(%rdi)
> movdqa %xmm0,0x30(%rdi)
> leaveq
> retq
>
>
> So i think here it is only about missing typedef….
>
>
>> On 19 Aug 2017, at 14:51, Dave Barach (dbarach)  wrote:
>>
>> Dear George,
>>
>> This specific issue isn’t anywhere near as bad as you might think. As given, 
>> the code confuses 128-bit vectors with 256-bit vectors, and 64-bit vectors 
>> with 128-bit vectors.
>>
>> Question: does the hardware involved support 256-bit vectors? Probably 
>> not... It almost certainly does support 128-bit vectors.
>>
>> To make progress, use the known-good u8x16 / 128-bit vector code:
>>
>> static_always_inline void
>> dpdk_buffer_init_from_template (void *d0, void *d1, void *d2, void *d3,
>>  void *s)
>> {
>> #if defined(CLIB_HAVE_VEC128)
>>  int i;
>>  for (i = 0; i < 4; i++)
>>{
>>  *(u8x16 *) (((u8 *) d0) + i * 16) =
>> *(u8x16 *) (((u8 *) d1) + i * 16) =
>> *(u8x16 *) (((u8 *) d2) + i * 16) =
>> *(u8x16 *) (((u8 *) d3) + i * 16) = *(u8x16 *) (((u8 *) s) + i * 16);
>>}
>> #else
>> #error "CLIB_HAVE_VEC128 has to be defined"
>> #endif
>> }
>>
>> Responsible parties - they know who they are - will be back from PTO 
>> shortly. We need to clean up / create CLIB_HAVE_VEC_256 and move the 256-bit 
>> vector engine code...
>>
>> You could also try adding “typedef u8 u8x32 _vector_size(32)” but I somehow 
>> doubt that will produce anything other than a compiler error.
>>
>> HTH… Dave
>>
>> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
>> Behalf Of George Zhao
>> Sent: Friday, August 18, 2017 7:32 PM
>> To: 'vpp-dev@lists.fd.io' ; 'disc...@lists.fd.io' 
>> ; 'csit-...@lists.fd.io' 
>> Subject: [vpp-dev] Question about VPP support for ARM 64
>>
>> We encounter following issues while trying to build VPP over ARM 64. It 
>> seems right now only ARM32 are supported in the code. I list the steps we 
>> tried and hope VPP folks can help us work around this issue.
>>
>> Steps:
>> 1. install Ubuntu 16.04 on OD1K
>> $>> uname -a
>> Linux OD1K 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:10:33 UTC 2017

Re: [vpp-dev] APIs frozen date , 2017-09-13

2017-08-20 Thread Florin Coras

Hi Shachar, 

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

Florin

> On Aug 19, 2017, at 11:50 PM, Shachar Beiser  wrote:
> 
> Hi ,
>I have just joined this community. I would like to verify my current 
> understanding.
>The due date for APIs frozen is : 2017-09-13.
>Is that right ?
> 
>  -Shachar Beiser.
>  
>  
> 2017-09-13 
> APIs frozen. Only low-risk changes accepted on main branch.
>  
>  
>  
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io 
> https://lists.fd.io/mailman/listinfo/vpp-dev 
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [discuss] Question about VPP support for ARM 64

2017-08-20 Thread Damjan Marion (damarion)



George, are you using ThunderX platform?

I spent few hours today trying to install latest ubuntu on my ThunderX system 
but no luck, kernel hangs at some point, both ubuntu provided and manually 
compiled.

Can you share about more details about your system?

Thanks,

Damjan



> On 19 Aug 2017, at 22:48, George Zhao  wrote:
> 
> If a bug is filed, may I have the bug number, I would be love to trace this 
> patch.
> 
> BTW, how do I file a bug for VPP, I did a quick wiki search with no luck.
> 
> Thanks,
> George
> 
> -Original Message-
> From: Dave Barach (dbarach) [mailto:dbar...@cisco.com] 
> Sent: Saturday, August 19, 2017 7:42 AM
> To: George Zhao 
> Cc: vpp-dev@lists.fd.io; disc...@lists.fd.io; csit-...@lists.fd.io; Damjan 
> Marion (damarion) 
> Subject: RE: [discuss] Question about VPP support for ARM 64
> 
> +1, pls add the typedef...
> 
> Thanks… Dave
> 
> -Original Message-
> From: Damjan Marion (damarion) 
> Sent: Saturday, August 19, 2017 9:09 AM
> To: Dave Barach (dbarach) 
> Cc: George Zhao ; vpp-dev@lists.fd.io; 
> disc...@lists.fd.io; csit-...@lists.fd.io
> Subject: Re: [discuss] Question about VPP support for ARM 64
> 
> 
> GCC is able to compile ARM64 code with 256-bit vectors even if target 
> platform have only 128-bit registers.
> 
> I.e. for the u8x32 version of that function it generates:
> 
> ARM64:
> dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
>ld1 {v0.16b - v1.16b}, [x4], 32
>st1 {v0.16b - v1.16b}, [x3], 32
>st1 {v0.16b - v1.16b}, [x2], 32
>st1 {v0.16b - v1.16b}, [x1], 32
>st1 {v0.16b - v1.16b}, [x0], 32
>ld1 {v0.16b - v1.16b}, [x4]
>st1 {v0.16b - v1.16b}, [x3]
>st1 {v0.16b - v1.16b}, [x2]
>st1 {v0.16b - v1.16b}, [x1]
>st1 {v0.16b - v1.16b}, [x0]
>ret
> 
> intel x86-64 without AVX2:
> 
> dpdk_buffer_init_from_template(void*, void*, void*, void*, void*):
> push   %rbp
> mov%rsp,%rbp
> and$0xffe0,%rsp
> lea0x10(%rsp),%rsp
> movdqa (%r8),%xmm1
> movdqa 0x10(%r8),%xmm0
> movdqa %xmm0,0x10(%rcx)
> movdqa %xmm1,(%rcx)
> movdqa %xmm1,(%rdx)
> movdqa %xmm0,0x10(%rdx)
> movdqa %xmm1,(%rsi)
> movdqa %xmm0,0x10(%rsi)
> movdqa %xmm1,(%rdi)
> movdqa %xmm0,0x10(%rdi)
> movdqa 0x20(%r8),%xmm1
> movdqa 0x30(%r8),%xmm0
> movdqa %xmm0,0x30(%rcx)
> movdqa %xmm1,0x20(%rcx)
> movdqa %xmm1,0x20(%rdx)
> movdqa %xmm0,0x30(%rdx)
> movdqa %xmm1,0x20(%rsi)
> movdqa %xmm0,0x30(%rsi)
> movdqa %xmm1,0x20(%rdi)
> movdqa %xmm0,0x30(%rdi)
> leaveq 
> retq   
> 
> 
> So i think here it is only about missing typedef….
> 
> 
>> On 19 Aug 2017, at 14:51, Dave Barach (dbarach)  wrote:
>> 
>> Dear George,
>> 
>> This specific issue isn’t anywhere near as bad as you might think. As given, 
>> the code confuses 128-bit vectors with 256-bit vectors, and 64-bit vectors 
>> with 128-bit vectors.
>> 
>> Question: does the hardware involved support 256-bit vectors? Probably 
>> not... It almost certainly does support 128-bit vectors.
>> 
>> To make progress, use the known-good u8x16 / 128-bit vector code:   
>> 
>> static_always_inline void
>> dpdk_buffer_init_from_template (void *d0, void *d1, void *d2, void *d3,
>>  void *s)
>> {
>> #if defined(CLIB_HAVE_VEC128)
>>  int i;
>>  for (i = 0; i < 4; i++)
>>{
>>  *(u8x16 *) (((u8 *) d0) + i * 16) =
>> *(u8x16 *) (((u8 *) d1) + i * 16) =
>> *(u8x16 *) (((u8 *) d2) + i * 16) =
>> *(u8x16 *) (((u8 *) d3) + i * 16) = *(u8x16 *) (((u8 *) s) + i * 16);
>>}
>> #else
>> #error "CLIB_HAVE_VEC128 has to be defined"
>> #endif
>> }
>> 
>> Responsible parties - they know who they are - will be back from PTO 
>> shortly. We need to clean up / create CLIB_HAVE_VEC_256 and move the 256-bit 
>> vector engine code...
>> 
>> You could also try adding “typedef u8 u8x32 _vector_size(32)” but I somehow 
>> doubt that will produce anything other than a compiler error.
>> 
>> HTH… Dave
>> 
>> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
>> Behalf Of George Zhao
>> Sent: Friday, August 18, 2017 7:32 PM
>> To: 'vpp-dev@lists.fd.io' ; 'disc...@lists.fd.io' 
>> ; 'csit-...@lists.fd.io' 
>> Subject: [vpp-dev] Question about VPP support for ARM 64
>> 
>> We encounter following issues while trying to build VPP over ARM 64. It 
>> seems right now only ARM32 are supported in the code. I list the steps we 
>> tried and hope VPP folks can help us work around this issue.
>> 
>> Steps: 
>> 1. install Ubuntu 16.04 on OD1K  
>> $>> uname -a
>> Linux OD1K 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:10:33 UTC 2017 
>> aarch64 aarch64 aarch64 GNU/Linux
>> 
>> 2. git clone VPP 17.04 and build VPP
>> ## Error:
>> make[2]: Entering directory '/home/huawei/GIT/vpp.1704/dpdk'
>> cat: '/sys/bus/pci/devices/:00:01.0/uevent': No such file or directory
>> 
>> **Work around to bypass MakeFile:
>> ###

Re: [vpp-dev] Set up MPLS via jvpp

Re: [vpp-dev] VPP Communications library and LD_PRELOAD

Re: [vpp-dev] VPP Communications library and LD_PRELOAD

[vpp-dev] 答复: [discuss] Question about VPP support for ARM 64

Re: [vpp-dev] APIs frozen date , 2017-09-13

Re: [vpp-dev] [discuss] Question about VPP support for ARM 64

6 matches

Site Navigation

Mail list logo

Footer information