date:20170820

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 
>>

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

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

2017-08-20 Thread Shachar Beiser

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

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

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

6 matches

Site Navigation

Mail list logo

Footer information