[vpp-dev] Welcome to VSAP project

2020-06-01 Thread Yu, Ping 
Hello, all

Glad to announce that the project VSAP(VPP Stack Acceleration Project) is 
online and this project aims to establish an industry user space application 
ecosystem based on VPP host stack. VSAP has done much work to optimize VPP host 
stack for Nginx, and we can see some exciting numbers comparing with kernel 
space stack.

The detailed project is below:
https://wiki.fd.io/view/VSAP

Welcome to join our mailing-list from below page.
https://lists.fd.io/g/vsap-dev


The VSAP project meeting time will be scheduled in as bi-weekly meeting in 
Friday 9:00 am PRC time( PT:  and next incoming meeting is Jun 12. Please join 
in this meeting via webex: https://intel.webex.com/meet/pyu4


Look forward to meeting with you.

Ping

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16595): https://lists.fd.io/g/vpp-dev/message/16595
Mute This Topic: https://lists.fd.io/mt/74599949/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP crash in TCP FIFO allocation

2019-10-28 Thread Yu, Ping 
We have some test for VCL based on application too, and it looks fine. To 
understand more, you’d check what line in mspace_malloc trigger the signal.

Attached is our vcl.conf for you to try if it is okay.

vcl {
rx-fifo-size 5000
tx-fifo-size 5000
app-scope-local
app-scope-global
api-socket-name /root/run/vpp/vpp-api.sock
event-queue-size 100
segment-size 102400
add-segment-size 102400
vpp-api-q-length 65536
max-workers 36
#use-mq-eventfd
}

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Akshaya 
Nadahalli
Sent: Thursday, October 24, 2019 4:38 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP crash in TCP FIFO allocation

Hi,

While testing VPP hoststack with large number of TCP connections, I see VPP 
crash in fifo allocation. Always crash is seen between 11k to 12k TCP 
connections. Changing vcl config - 
segment-size/add-segment-size/rx-fifo-size/tx-fifo-size doesn't change the 
behaviour - crash is always seen after establishing around 11k to 12k tcp 
sessions.

Test client is using vppcom APIs. Callstack for crash is attached. I am using 
19.08 code with non-blocking patch cherry-picked. All sessions are 
non-blocking. Anyone aware of any issues/defect fixes related to this?

Regards,
Akshaya N
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14372): https://lists.fd.io/g/vpp-dev/message/14372
Mute This Topic: https://lists.fd.io/mt/36994945/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] how to update openssl in the vpp

2019-10-28 Thread Yu, Ping 
You can install any OpenSSL version as you wish, and you can use the following 
command to tell vpp cmake to get the right OpenSSL

For example:

# export OPENSSL_ROOT_DIR=/usr/local/lib64/
# export LD_LIBRARY_PATH=/usr/local/lib64/



From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Damjan 
Marion via Lists.Fd.Io
Sent: Monday, October 28, 2019 6:36 PM
To: zhangsh...@chinatelecom.cn
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] how to update openssl in the vpp




On 24 Oct 2019, at 04:46, 
zhangsh...@chinatelecom.cn wrote:

Hello:
how to update openssl in the vpp?

We uses system openssl, so whatever you have installed VPP will use…


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14371): https://lists.fd.io/g/vpp-dev/message/14371
Mute This Topic: https://lists.fd.io/mt/37703296/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] VPP Hoststack CPS

2019-10-12 Thread Yu, Ping 
Hi, Nataraj

We have done some work for VCL performance evaluation and integration, and 
currently due to VPP does not support port-reuse yet, some test tools such as 
wrk which initializes client close could not give us good CPS number, thus we 
are focusing on RPS. From our testing, the performance based on VCL will 
increase much. For example, the RPS for 64B in Nginx kernel is 178k, while the 
VCL can hit around 500k.

From: vpp-dev@lists.fd.io  On Behalf Of Nataraj Batchu
Sent: Friday, October 11, 2019 9:31 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP Hoststack CPS

Hi Florin:

Thanks for the quick reply. By any chance, do you have latest CPS numbers? Or 
any document to look at that you/your team published?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#14171): https://lists.fd.io/g/vpp-dev/message/14171
Mute This Topic: https://lists.fd.io/mt/34465863/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] false verified + 1 for gerrit jobs

2019-05-08 Thread Yu, Ping 
Recently centOS build always fail and patch review is blocked even retrying 
several times. 


16:17:11 -- Configuring done
16:17:12 -- Generating done
16:17:12 -- Build files have been written to: 
/w/workspace/vpp-verify-master-centos7/build-root/rpmbuild/vpp-19.08/build-root/build-vpp-native/vpp
16:17:12 ninja: error: manifest 'build.ninja' still dirty after 100 tries
16:17:12 
16:17:12 make[4]: *** [Makefile:695: vpp-build] Error 1
16:17:12 make[4]: Leaving directory 
'/w/workspace/vpp-verify-master-centos7/build-root/rpmbuild/vpp-19.08/build-root'
16:17:12 make[3]: *** [Makefile:931: install-packages] Error 1
16:17:12 make[3]: Leaving directory 
'/w/workspace/vpp-verify-master-centos7/build-root/rpmbuild/vpp-19.08/build-root'
16:17:12 error: Bad exit status from /var/tmp/rpm-tmp.8TtZeQ (%build)
16:17:12 
16:17:12 
16:17:12 RPM build errors:
16:17:12 Bad exit status from /var/tmp/rpm-tmp.8TtZeQ (%build)
16:17:12 make[2]: *** [RPM] Error 1
16:17:12 make[2]: Leaving directory 
`/w/workspace/vpp-verify-master-centos7/extras/rpm'
16:17:12 make[1]: *** [pkg-rpm] Error 2
16:17:12 make[1]: Leaving directory `/w/workspace/vpp-verify-master-centos7'
16:17:12 make: *** [verify] Error 2
16:17:12 Build step 'Execute shell' marked build as failure


-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Vratko 
Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io
Sent: Tuesday, May 7, 2019 4:21 PM
To: Ed Kern (ejk) ; Klement Sekera -X (ksekera - PANTHEON 
TECHNOLOGIES at Cisco) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] false verified + 1 for gerrit jobs

> reduce the number of retries (or possibly completely)

+1 for completely.

Vratko.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Ed Kern via 
Lists.Fd.Io
Sent: Tuesday, 2019-May-07 00:34
To: Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco) 

Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] false verified + 1 for gerrit jobs

This is a known issue with how the retry mechanic interacts (badly) with gerrit 
occasionally.  This odds of this happening were a bit higher over the last
couple of days specific to centos retries.   This is tied to the JNLP changes
made to csit and how the initial connection is made.   While the change
has improved JNLP issues across the board there are a couple new nits
that ill have to debug.

At this point though I’m not going to touch/debug further until the csit 
jobs/reports are completed.

Im actually hopeful that ill be able to reduce the number of retries (or 
possibly completely) in the long run with the HAProxy bypass in place.

Ed




> On May 6, 2019, at 11:18 AM, Klement Sekera -X (ksekera - PANTHEON 
> TECHNOLOGIES at Cisco)  wrote:
> 
> Hi all,
> 
> I noticed a job getting a +1 even though some of the builds failed ...
> 
> https://gerrit.fd.io/r/#/c/18444/
> 
> please note patch set 9 
> 
> fd.io JJB
> Patch Set 9: Verified-1 Build Failed
> https://jenkins.fd.io/job/vpp-arm-verify-master-ubuntu1804/2459/ :
> FAILURE No problems were identified. If you know why this problem 
> occurred, please add a suitable Cause for it. ( 
> https://jenkins.fd.io/job/vpp-arm-verify-master-ubuntu1804/2459/ )
> Logs:
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-arm-verify-mas
> ter-ubuntu1804/2459
> https://jenkins.fd.io/job/vpp-beta-verify-master-ubuntu1804/6891/ :
> FAILURE No problems were identified. If you know why this problem 
> occurred, please add a suitable Cause for it. ( 
> https://jenkins.fd.io/job/vpp-beta-verify-master-ubuntu1804/6891/ )
> Logs:
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-beta-verify-ma
> ster-ubuntu1804/6891
> https://jenkins.fd.io/job/vpp-csit-verify-device-master-1n-skx/788/ :
> SUCCESS (skipped) Logs:
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-csit-verify-de
> vice-master-1n-skx/788
> https://jenkins.fd.io/job/vpp-make-test-docs-verify-master/13041/ :
> SUCCESS Logs:
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-make-test-docs
> -verify-master/13041
> https://jenkins.fd.io/job/vpp-verify-master-ubuntu1604/19027/ :
> SUCCESS Logs:
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-
> ubuntu1604/19027
> https://jenkins.fd.io/job/vpp-verify-master-clang/6731/ : SUCCESS
> Logs:
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-
> clang/6731 https://jenkins.fd.io/job/vpp-docs-verify-master/15343/ : 
> SUCCESS
> Logs:
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-docs-verify-ma
> ster/15343 https://jenkins.fd.io/job/vpp-verify-master-centos7/18764/
> : NOT_BUILT
> Logs:
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-
> centos7/18764
> 7:11 PM
> fd.io JJB
> Patch Set 9: Verified+1 Build Successful 
> https://jenkins.fd.io/job/vpp-verify-master-centos7/18764/ : SUCCESS
> Logs:
> https://logs.fd.io/production/vex-yul-rot-jenkins-1/vpp-verify-master-
> centos7/18764
> 7:15 PM
> 
>

[vpp-dev] openssl 3.0.0

2019-01-13 Thread Yu, Ping 
Hello, all

I will use a new API added in openssl 3.0.0 master for a better async 
communication, but I found that some API in openssl 3.0.0 has deprecated, such 
as EC_POINT_get_affine_coordinates_GFp/EC_POINT_set_affine_coordinates_GFp.

I added a patch to fix this problem to make VPP compatible with latest openssl 
3.0.0 master branch.
https://gerrit.fd.io/r/#/c/16798/

Ping
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11907): https://lists.fd.io/g/vpp-dev/message/11907
Mute This Topic: https://lists.fd.io/mt/29077225/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] found some issue in pci vfio

2019-01-01 Thread Yu, Ping 
Hi, Damjan,

The issue existing in the code is container fd is initialized as “-1”, and 
there is no code to update it before trying to read  iommu_group in pci.c, and 
container_fd is the condition required. See below code.


  if (lvm->container_fd != -1)
{
  u8 *tmpstr;
  vec_reset_length (f);
  f = format (f, "%v/iommu_group%c", dev_dir_name, 0);
  tmpstr = clib_sysfs_link_to_name ((char *) f);
  if (tmpstr)
{
  di->iommu_group = atoi ((char *) tmpstr);
  vec_free (tmpstr);
}

From: Damjan Marion [mailto:dmar...@me.com]
Sent: Sunday, December 30, 2018 7:10 PM
To: Yu, Ping 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] found some issue in pci vfio


Fact that you can open vfio container doesn't actually mean that you can use 
vfio-pci module on specific PCI device.

vfio-pci module can be used in 2 cases:
 - when /sys/bus/pci/devices//iommu_group exists
 - when /sys/module/vfio/parameters/enable_unsafe_noiommu_mode is set to Y 
(introduced in kernel 4.4)

That code needs to be fixed, but I don't think your fix is the right one



On 29 Dec 2018, at 04:46, Yu, Ping 
mailto:ping...@intel.com>> wrote:

I submitted a patch to fix it.

https://gerrit.fd.io/r/16640

Ping

From: Yu, Ping
Sent: Saturday, December 29, 2018 10:43 AM
To: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Cc: Yu, Ping mailto:ping...@intel.com>>
Subject: found some issue in pci vfio

Hello, all

Recently I met some issue in vfio, and below is some root cause:

Before running vpp, I will use “dpdk-devbind.py” to bind the NIC to vfio-pci, 
and then use “uio-driver auto” configure, and it once worked well, but it has 
problem recently, so I took a look at this to resolve the problem.
I found that vpp has some problem to “auto” detect the uio-driver to be vfio, 
and the bug info is below:
1)  vlib_pci_bind_to_uio is dependent vlib_pci_get_device_info to tell 
iommu_group
2)  vlib_pci_get_device_info will check whether lvm->container_fd == -1

In my case, lvm->container_fd is initialized to be “-1”, and there is no chance 
to modify it, so in the eye of vlib_pci_bind_to_uio, iommu_group is -1, then it 
will try to enable noiommu mode. If some kernel enabled NOIOMMU, then vfio can 
continue work with noiommu mode, but if not, then this device will be rejected 
due to “no VFIO” support.  (pci.c # 411. )

The solution is to drop “auto” mode, and explicitly configure “vfio-pci” in the 
configuration, but I hope the default “auto” mode can be smarter.

Ping

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11792): https://lists.fd.io/g/vpp-dev/message/11792
Mute This Topic: https://lists.fd.io/mt/28877871/675642
Group Owner: vpp-dev+ow...@lists.fd.io<mailto:vpp-dev+ow...@lists.fd.io>
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  
[dmar...@me.com<mailto:dmar...@me.com>]
-=-=-=-=-=-=-=-=-=-=-=-

--
Damjan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11812): https://lists.fd.io/g/vpp-dev/message/11812
Mute This Topic: https://lists.fd.io/mt/28877871/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] found some issue in pci vfio

2018-12-28 Thread Yu, Ping 
I submitted a patch to fix it.

https://gerrit.fd.io/r/16640

Ping

From: Yu, Ping
Sent: Saturday, December 29, 2018 10:43 AM
To: vpp-dev@lists.fd.io
Cc: Yu, Ping 
Subject: found some issue in pci vfio

Hello, all

Recently I met some issue in vfio, and below is some root cause:

Before running vpp, I will use "dpdk-devbind.py" to bind the NIC to vfio-pci, 
and then use "uio-driver auto" configure, and it once worked well, but it has 
problem recently, so I took a look at this to resolve the problem.
I found that vpp has some problem to "auto" detect the uio-driver to be vfio, 
and the bug info is below:

1)  vlib_pci_bind_to_uio is dependent vlib_pci_get_device_info to tell 
iommu_group

2)  vlib_pci_get_device_info will check whether lvm->container_fd == -1

In my case, lvm->container_fd is initialized to be "-1", and there is no chance 
to modify it, so in the eye of vlib_pci_bind_to_uio, iommu_group is -1, then it 
will try to enable noiommu mode. If some kernel enabled NOIOMMU, then vfio can 
continue work with noiommu mode, but if not, then this device will be rejected 
due to "no VFIO" support.  (pci.c # 411. )

The solution is to drop "auto" mode, and explicitly configure "vfio-pci" in the 
configuration, but I hope the default "auto" mode can be smarter.

Ping

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11792): https://lists.fd.io/g/vpp-dev/message/11792
Mute This Topic: https://lists.fd.io/mt/28877871/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] found some issue in pci vfio

2018-12-28 Thread Yu, Ping 
Hello, all

Recently I met some issue in vfio, and below is some root cause:

Before running vpp, I will use "dpdk-devbind.py" to bind the NIC to vfio-pci, 
and then use "uio-driver auto" configure, and it once worked well, but it has 
problem recently, so I took a look at this to resolve the problem.
I found that vpp has some problem to "auto" detect the uio-driver to be vfio, 
and the bug info is below:

1)  vlib_pci_bind_to_uio is dependent vlib_pci_get_device_info to tell 
iommu_group

2)  vlib_pci_get_device_info will check whether lvm->container_fd == -1

In my case, lvm->container_fd is initialized to be "-1", and there is no chance 
to modify it, so in the eye of vlib_pci_bind_to_uio, iommu_group is -1, then it 
will try to enable noiommu mode. If some kernel enabled NOIOMMU, then vfio can 
continue work with noiommu mode, but if not, then this device will be rejected 
due to "no VFIO" support.  (pci.c # 411. )

The solution is to drop "auto" mode, and explicitly configure "vfio-pci" in the 
configuration, but I hope the default "auto" mode can be smarter.

Ping

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11791): https://lists.fd.io/g/vpp-dev/message/11791
Mute This Topic: https://lists.fd.io/mt/28877871/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Question regarding captive portal

2018-12-27 Thread Yu, Ping 
In this case, you can consider to use vpp nat.

https://wiki.fd.io/view/VPP/NAT

I have not verified it. Please update me if it works. ☺

Ping

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of carlito 
nueno
Sent: Friday, December 28, 2018 12:36 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Question regarding captive portal

Sorry I wasn't clear:

VPP is the gateway in my case.
So when a request comes from client to VPP, how can I get redirect that request 
(in VPP) to an application on the linux host?
Application is listening on a tap device on port 80.

Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11784): https://lists.fd.io/g/vpp-dev/message/11784
Mute This Topic: https://lists.fd.io/mt/28506160/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Question regarding captive portal

2018-12-27 Thread Yu, Ping 
There are two solutions.

1)  DNS level: Set your own DNS server, and hijiak all DNS and point to 
your server.

2)  IP and http: When gateway gets request from client to google.com, and 
you can simulate “man in the middle” to syn/ack to client, and talk with client 
to provide 302 redirect to client. You can either use VPP host stack to get the 
http request.

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of carlito 
nueno
Sent: Friday, December 28, 2018 8:59 AM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Question regarding captive portal

Hi all,

After more research, I found that most devices test connectivity by issuing an 
HTTP GET request, e.g. to captive.apple.com or 
connectivitycheck.gstatic.com/generate_204.
How do I catch this http request and respond with 302 redirect that redirects 
user to lan ip address: 192.168.1.2:80/index.html.

thanks!
Happy holidays :)
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11781): https://lists.fd.io/g/vpp-dev/message/11781
Mute This Topic: https://lists.fd.io/mt/28506160/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] cmake is on

2018-09-05 Thread Yu, Ping 
Thanks Damjan. If cloning a brandnew repo, the build is ok.

Ping

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Damjan 
Marion via Lists.Fd.Io
Sent: Wednesday, September 5, 2018 1:13 AM
To: Yu, Ping 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] cmake is on


Dear Ping,

Can you please clean up your workspace (git clean -fdx) and then capture full 
log...

Thanks,

--
Damjan


On 4 Sep 2018, at 15:40, Yu, Ping mailto:ping...@intel.com>> 
wrote:

Hi, Damjan,

My Ubuntu environment is good. But in FC27, I got the following issue in debug 
mode.


-- Build files have been written to: 
/home/pyu4/git-home/vpp_master/vpp/build-root/build-vpp_debug-native/vpp
 Building vpp in 
/home/pyu4/git-home/vpp_master/vpp/build-root/build-vpp_debug-native/vpp 
[507/1184] Building C object vppinfra/CMakeFiles/vppinfra.dir/mem_dlmalloc.c.o
FAILED: vppinfra/CMakeFiles/vppinfra.dir/mem_dlmalloc.c.o
ccache /usr/lib64/ccache/cc -Dvppinfra_EXPORTS 
-I/home/pyu4/git-home/vpp_master/vpp/src -I. -Iinclude -march=corei7 
-mtune=corei7-avx -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 -fstack-protector-all 
-fPIC -Werror -fPIC   -Wno-address-of-packed-member -Wall -MD -MT 
vppinfra/CMakeFiles/vppinfra.dir/mem_dlmalloc.c.o -MF 
vppinfra/CMakeFiles/vppinfra.dir/mem_dlmalloc.c.o.d -o 
vppinfra/CMakeFiles/vppinfra.dir/mem_dlmalloc.c.o   -c 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem_dlmalloc.c
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem_dlmalloc.c:42:3: error: 
conflicting types for ‘mheap_trace_t’
} mheap_trace_t;
   ^
In file included from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem.h:49:0,
 from /home/pyu4/git-home/vpp_master/vpp/src/vppinfra/vec.h:42,
 from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/format.h:44,
 from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem_dlmalloc.c:16:
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mheap_bootstrap.h:147:3: note: 
previous declaration of ‘mheap_trace_t’ was here
} mheap_trace_t;
   ^
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem_dlmalloc.c:59:3: error: 
conflicting types for ‘mheap_trace_main_t’
} mheap_trace_main_t;
   ^~
In file included from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem.h:49:0,
 from /home/pyu4/git-home/vpp_master/vpp/src/vppinfra/vec.h:42,
 from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/format.h:44,
 from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem_dlmalloc.c:16:
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mheap_bootstrap.h:161:3: note: 
previous declaration of ‘mheap_trace_main_t’ was here
} mheap_trace_main_t;
   ^~
cc1: error: unrecognized command line option ‘-Wno-address-of-packed-member’ 
[-Werror]
cc1: all warnings being treated as errors
[620/1184] Building C object vnet/CMakeFiles/vnet.dir/dhcp/dhcp_api.c.o
ninja: build stopped: subcommand failed.
make[1]: *** [Makefile:691: vpp-build] Error 1
make[1]: Leaving directory '/home/pyu4/git-home/vpp_master/vpp/build-root'
make: *** [Makefile:342: build] Error 2


the following issue in release mode.

[781/1184] Linking C executable bin/sock_test_server
FAILED: bin/sock_test_server
: && ccache /usr/lib64/ccache/cc -march=corei7 -mtune=corei7-avx -g -O2 
-DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Werror   
vcl/CMakeFiles/sock_test_server.dir/sock_test_server.c.o  -o 
bin/sock_test_server  -Wl
,-rpath,/home/pyu4/git-home/vpp_master/vpp/build-root/build-vpp-native/vpp/lib 
lib/libvppcom.so.18.10 lib/libvlibmemoryclient.so.18.10 lib/libvlib.so.18.10 
lib/libsvm.so.18.10 lib/libvppinfra.so.18.10 -lm -ldl -
lrt -lpthread && :
lib/libvppcom.so.18.10: undefined reference to `mheap_put'
lib/libvlibmemoryclient.so.18.10: undefined reference to `mheap_get_aligned'
collect2: error: ld returned 1 exit status
[782/1184] Linking C executable bin/test_vcl_listener_client
FAILED: bin/test_vcl_listener_client
: && ccache /usr/lib64/ccache/cc -march=corei7 -mtune=corei7-avx -g -O2 
-DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Werror   
vcl/CMakeFiles/test_vcl_listener_client.dir/test_vcl_listener_client.c.o  -o 
bin/test_
vcl_listener_client  
-Wl,-rpath,/home/pyu4/git-home/vpp_master/vpp/build-root/build-vpp-native/vpp/lib
 lib/libvppcom.so.18.10 lib/libvlibmemoryclient.so.18.10 lib/libvlib.so.18.10 
lib/libsvm.so.18.10 lib/libvppinfra.so.18.10 -lm -ldl -lrt -lpthread && :
lib/libvppcom.so.18.10: undefined reference to `mheap_put'
lib/libvlibmemoryclient.so.18.10: undefined reference to `mheap_get_aligned'
collect2: error: ld returned 1 exit status



From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Damjan Marion via Lists.Fd.Io
Sent: Sunday, September 2, 2018 8:48 PM
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>

Re: [vpp-dev] cmake is on

2018-09-04 Thread Yu, Ping 
Hi, Damjan,

My Ubuntu environment is good. But in FC27, I got the following issue in debug 
mode.


-- Build files have been written to: 
/home/pyu4/git-home/vpp_master/vpp/build-root/build-vpp_debug-native/vpp
 Building vpp in 
/home/pyu4/git-home/vpp_master/vpp/build-root/build-vpp_debug-native/vpp 
[507/1184] Building C object vppinfra/CMakeFiles/vppinfra.dir/mem_dlmalloc.c.o
FAILED: vppinfra/CMakeFiles/vppinfra.dir/mem_dlmalloc.c.o
ccache /usr/lib64/ccache/cc -Dvppinfra_EXPORTS 
-I/home/pyu4/git-home/vpp_master/vpp/src -I. -Iinclude -march=corei7 
-mtune=corei7-avx -g -O0 -DCLIB_DEBUG -DFORTIFY_SOURCE=2 -fstack-protector-all 
-fPIC -Werror -fPIC   -Wno-address-of-packed-member -Wall -MD -MT 
vppinfra/CMakeFiles/vppinfra.dir/mem_dlmalloc.c.o -MF 
vppinfra/CMakeFiles/vppinfra.dir/mem_dlmalloc.c.o.d -o 
vppinfra/CMakeFiles/vppinfra.dir/mem_dlmalloc.c.o   -c 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem_dlmalloc.c
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem_dlmalloc.c:42:3: error: 
conflicting types for 'mheap_trace_t'
} mheap_trace_t;
   ^
In file included from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem.h:49:0,
 from /home/pyu4/git-home/vpp_master/vpp/src/vppinfra/vec.h:42,
 from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/format.h:44,
 from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem_dlmalloc.c:16:
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mheap_bootstrap.h:147:3: note: 
previous declaration of 'mheap_trace_t' was here
} mheap_trace_t;
   ^
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem_dlmalloc.c:59:3: error: 
conflicting types for 'mheap_trace_main_t'
} mheap_trace_main_t;
   ^~
In file included from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem.h:49:0,
 from /home/pyu4/git-home/vpp_master/vpp/src/vppinfra/vec.h:42,
 from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/format.h:44,
 from 
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mem_dlmalloc.c:16:
/home/pyu4/git-home/vpp_master/vpp/src/vppinfra/mheap_bootstrap.h:161:3: note: 
previous declaration of 'mheap_trace_main_t' was here
} mheap_trace_main_t;
   ^~
cc1: error: unrecognized command line option '-Wno-address-of-packed-member' 
[-Werror]
cc1: all warnings being treated as errors
[620/1184] Building C object vnet/CMakeFiles/vnet.dir/dhcp/dhcp_api.c.o
ninja: build stopped: subcommand failed.
make[1]: *** [Makefile:691: vpp-build] Error 1
make[1]: Leaving directory '/home/pyu4/git-home/vpp_master/vpp/build-root'
make: *** [Makefile:342: build] Error 2


the following issue in release mode.

[781/1184] Linking C executable bin/sock_test_server
FAILED: bin/sock_test_server
: && ccache /usr/lib64/ccache/cc -march=corei7 -mtune=corei7-avx -g -O2 
-DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Werror   
vcl/CMakeFiles/sock_test_server.dir/sock_test_server.c.o  -o 
bin/sock_test_server  -Wl
,-rpath,/home/pyu4/git-home/vpp_master/vpp/build-root/build-vpp-native/vpp/lib 
lib/libvppcom.so.18.10 lib/libvlibmemoryclient.so.18.10 lib/libvlib.so.18.10 
lib/libsvm.so.18.10 lib/libvppinfra.so.18.10 -lm -ldl -
lrt -lpthread && :
lib/libvppcom.so.18.10: undefined reference to `mheap_put'
lib/libvlibmemoryclient.so.18.10: undefined reference to `mheap_get_aligned'
collect2: error: ld returned 1 exit status
[782/1184] Linking C executable bin/test_vcl_listener_client
FAILED: bin/test_vcl_listener_client
: && ccache /usr/lib64/ccache/cc -march=corei7 -mtune=corei7-avx -g -O2 
-DFORTIFY_SOURCE=2 -fstack-protector -fPIC -Werror   
vcl/CMakeFiles/test_vcl_listener_client.dir/test_vcl_listener_client.c.o  -o 
bin/test_
vcl_listener_client  
-Wl,-rpath,/home/pyu4/git-home/vpp_master/vpp/build-root/build-vpp-native/vpp/lib
 lib/libvppcom.so.18.10 lib/libvlibmemoryclient.so.18.10 lib/libvlib.so.18.10 
lib/libsvm.so.18.10 lib/libvppinfra.so.18.10 -lm -ldl -lrt -lpthread && :
lib/libvppcom.so.18.10: undefined reference to `mheap_put'
lib/libvlibmemoryclient.so.18.10: undefined reference to `mheap_get_aligned'
collect2: error: ld returned 1 exit status



From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Damjan 
Marion via Lists.Fd.Io
Sent: Sunday, September 2, 2018 8:48 PM
To: vpp-dev 
Cc: vpp-dev@lists.fd.io
Subject: [vpp-dev] cmake is on


Dear all,

We just switched from autotools to cmake and retired all autotools related 
files in src/.

All verify jobs are ok, and we also tried it on 3 different x86 and 2 different 
ARM Aarch64 machines.

Due to blast radius, i will not be surprised that some small issues pop out, 
but i don't expect anything hard to fix.

Let us know if you hit something...

PS As a part of this change, CentOS 7 build are now using devtoolset-7, so they 
are compiled with gcc-7, which also means images have support for Skylake 
Servers (AVX512).

--
Damjan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent t

Re: [vpp-dev] TLS half open lock

2018-08-28 Thread Yu, Ping 
Yes, this is what I did to fix the code.

Please help review below patch, and besides adding the lock, and I also 
optimize a bit to reduce the lock scope.

https://gerrit.fd.io/r/14534

Ping

From: Florin Coras [mailto:fcoras.li...@gmail.com]
Sent: Tuesday, August 28, 2018 10:58 PM
To: Yu, Ping 
Cc: Florin Coras (fcoras) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] TLS half open lock

Yes, this probably happens because free is called by a different thread. As 
mentioned in my previous reply, could you try protecting with 
clib_rwlock_reader_lock (&tm->half_open_rwlock); the branch that does not 
expand the pool?

Thanks,
Florin


On Aug 28, 2018, at 7:51 AM, Yu, Ping 
mailto:ping...@intel.com>> wrote:

Hello, Florin,

From below info, we can see a real race condition happens.

thread 2 free: 149
thread 3 free: 155
thread 0: alloc: 149
thread 0: alloc: 149


[Time 0]

thread 2 free: 149
Thread 2 free 149 and now 149 is at the pool vec_len (_pool_var 
(p)->free_indices);

[Time 1&Time 2 ]

Now thread 0 wants to get, and thread 3 wants to put at the same time.
Before thread 3 put, thread 0 get current vec_len: 149.
Thread 3 makes:  vec_add1 (_pool_var (p)->free_indices, _pool_var (l));
Thread 0 makes:  _vec_len (_pool_var (p)->free_indices) = _pool_var (l) - 1;


[Time 3]
Due to race condition, current vec_len is the same as time 0, and the old 
element 149 returns again.

Even though performance is important, and we still need to use lock to resolve 
this race condition.


From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Yu, Ping
Sent: Tuesday, August 28, 2018 5:29 PM
To: Florin Coras mailto:fcoras.li...@gmail.com>>
Cc: Florin Coras (fcoras) mailto:fco...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Yu, Ping 
mailto:ping...@intel.com>>
Subject: Re: [vpp-dev] TLS half open lock

Hi, Florin,

Yes, you are right, and all alloc operation is performed by thread 0. An 
interesting thing is that if running “test echo clients nclients 300 uri 
tls://10.10.1.1/” in clients with 4 threads, I can easily catch the case 
one same index be alloc twice by thread 0.

thread 0: alloc: 145
thread 0: alloc: 69
thread 4 free: 151
thread 0: alloc: 151
thread 2 free: 149
thread 3 free: 155
thread 0: alloc: 149
thread 0: alloc: 149
thread 0: alloc: 58
thread 0: alloc: 9
thread 0: alloc: 29
thread 3 free: 146
thread 0: alloc: 146
thread 2 free: 153
thread 0: alloc: 144
thread 0: alloc: 153
thread 0: alloc: 124
thread 3 free: 25
thread 0: alloc: 25

From: Florin Coras [mailto:fcoras.li...@gmail.com]
Sent: Tuesday, August 28, 2018 10:24 AM
To: Yu, Ping mailto:ping...@intel.com>>
Cc: Florin Coras (fcoras) mailto:fco...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] TLS half open lock

Hi Ping,

The expectation is that all connects/listens come on the main thread (with the 
worker barrier held). In other words, we only need to support a one writer, 
multiple readers scenario.

Florin

On Aug 27, 2018, at 6:29 PM, Yu, Ping 
mailto:ping...@intel.com>> wrote:

Hi, Florin,

To check if it is about to expand is also lockless. Is there any issue if two 
threads check the pool simultaneously, and just one slot is available? One code 
will do normal get, and the other thread is expanding the pool?

Thanks
Ping

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, August 28, 2018 12:51 AM
To: Yu, Ping mailto:ping...@intel.com>>
Cc: Florin Coras (fcoras) mailto:fco...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] TLS half open lock

Hi Ping,

The current implementation only locks the half-open pool if the pool is about 
to expand. This is done to increase speed by avoiding unnecessary locking, 
i.e., if pool is not about to expand, it should be safe to get a new element 
from it without affecting readers. Now the thing to figure out is why this is 
happening. Does the slowdown due to the “big lock” avoid some race or is there 
more to it?

First of all, how many workers do you have configured and how many sessions are 
you allocating/connecting? Do you see failed connects?

Your tls_ctx_half_open_get line numbers don’t match my code. Did you by chance 
modify something else?

Thanks,
Florin



On Aug 27, 2018, at 9:22 AM, Yu, Ping 
mailto:ping...@intel.com>> wrote:

Hello, all

Recently I found that the TLS half open lock is not well implemented, and if 
enabling multiple thread, there are chances to get the following core dump info 
in debug mode.

(gdb) where
#0  0x7f7a0848e428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7f7a0849002a in __GI_abort () at abort.c:89
#2  0x00407f0b in os_panic () at 
/home/pyu4/git-home/vpp_clean/vpp/src/vpp/vnet/main.c:331
#3  0x7f

Re: [vpp-dev] TLS half open lock

2018-08-28 Thread Yu, Ping 
Hello, Florin,

From below info, we can see a real race condition happens.

thread 2 free: 149
thread 3 free: 155
thread 0: alloc: 149
thread 0: alloc: 149


[Time 0]

thread 2 free: 149
Thread 2 free 149 and now 149 is at the pool vec_len (_pool_var 
(p)->free_indices);

[Time 1&Time 2 ]

Now thread 0 wants to get, and thread 3 wants to put at the same time.
Before thread 3 put, thread 0 get current vec_len: 149.
Thread 3 makes:  vec_add1 (_pool_var (p)->free_indices, _pool_var (l));
Thread 0 makes:  _vec_len (_pool_var (p)->free_indices) = _pool_var (l) - 1;


[Time 3]
Due to race condition, current vec_len is the same as time 0, and the old 
element 149 returns again.

Even though performance is important, and we still need to use lock to resolve 
this race condition.


From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Yu, Ping
Sent: Tuesday, August 28, 2018 5:29 PM
To: Florin Coras 
Cc: Florin Coras (fcoras) ; vpp-dev@lists.fd.io; Yu, Ping 

Subject: Re: [vpp-dev] TLS half open lock

Hi, Florin,

Yes, you are right, and all alloc operation is performed by thread 0. An 
interesting thing is that if running “test echo clients nclients 300 uri 
tls://10.10.1.1/” in clients with 4 threads, I can easily catch the case 
one same index be alloc twice by thread 0.

thread 0: alloc: 145
thread 0: alloc: 69
thread 4 free: 151
thread 0: alloc: 151
thread 2 free: 149
thread 3 free: 155
thread 0: alloc: 149
thread 0: alloc: 149
thread 0: alloc: 58
thread 0: alloc: 9
thread 0: alloc: 29
thread 3 free: 146
thread 0: alloc: 146
thread 2 free: 153
thread 0: alloc: 144
thread 0: alloc: 153
thread 0: alloc: 124
thread 3 free: 25
thread 0: alloc: 25

From: Florin Coras [mailto:fcoras.li...@gmail.com]
Sent: Tuesday, August 28, 2018 10:24 AM
To: Yu, Ping mailto:ping...@intel.com>>
Cc: Florin Coras (fcoras) mailto:fco...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] TLS half open lock

Hi Ping,

The expectation is that all connects/listens come on the main thread (with the 
worker barrier held). In other words, we only need to support a one writer, 
multiple readers scenario.

Florin

On Aug 27, 2018, at 6:29 PM, Yu, Ping 
mailto:ping...@intel.com>> wrote:

Hi, Florin,

To check if it is about to expand is also lockless. Is there any issue if two 
threads check the pool simultaneously, and just one slot is available? One code 
will do normal get, and the other thread is expanding the pool?

Thanks
Ping

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, August 28, 2018 12:51 AM
To: Yu, Ping mailto:ping...@intel.com>>
Cc: Florin Coras (fcoras) mailto:fco...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] TLS half open lock

Hi Ping,

The current implementation only locks the half-open pool if the pool is about 
to expand. This is done to increase speed by avoiding unnecessary locking, 
i.e., if pool is not about to expand, it should be safe to get a new element 
from it without affecting readers. Now the thing to figure out is why this is 
happening. Does the slowdown due to the “big lock” avoid some race or is there 
more to it?

First of all, how many workers do you have configured and how many sessions are 
you allocating/connecting? Do you see failed connects?

Your tls_ctx_half_open_get line numbers don’t match my code. Did you by chance 
modify something else?

Thanks,
Florin


On Aug 27, 2018, at 9:22 AM, Yu, Ping 
mailto:ping...@intel.com>> wrote:

Hello, all

Recently I found that the TLS half open lock is not well implemented, and if 
enabling multiple thread, there are chances to get the following core dump info 
in debug mode.

(gdb) where
#0  0x7f7a0848e428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7f7a0849002a in __GI_abort () at abort.c:89
#2  0x00407f0b in os_panic () at 
/home/pyu4/git-home/vpp_clean/vpp/src/vpp/vnet/main.c:331
#3  0x7f7a08867bd0 in debugger () at 
/home/pyu4/git-home/vpp_clean/vpp/src/vppinfra/error.c:84
#4  0x7f7a08868008 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0,
fmt=0x7f7a0a0add78 "%s:%d (%s) assertion `%s' fails") at 
/home/pyu4/git-home/vpp_clean/vpp/src/vppinfra/error.c:143
#5  0x7f7a09e10be0 in tls_ctx_half_open_get (ctx_index=48) at 
/home/pyu4/git-home/vpp_clean/vpp/src/vnet/tls/tls.c:126
#6  0x7f7a09e11889 in tls_session_connected_callback (tls_app_index=0, 
ho_ctx_index=48, tls_session=0x7f79c9b6d1c0,
is_fail=0 '\000') at 
/home/pyu4/git-home/vpp_clean/vpp/src/vnet/tls/tls.c:404
#7  0x7f7a09d5ea6e in session_stream_connect_notify (tc=0x7f79c9b655fc, 
is_fail=0 '\000')
at /home/pyu4/git-home/vpp_clean/vpp/src/vnet/session/session.c:648
#8  0x7f7a099cb969 in tcp46_syn_sent_inline (vm=0x7f79c8a25100,

Re: [vpp-dev] TLS half open lock

2018-08-28 Thread Yu, Ping 
Hi, Florin,

Yes, you are right, and all alloc operation is performed by thread 0. An 
interesting thing is that if running “test echo clients nclients 300 uri 
tls://10.10.1.1/” in clients with 4 threads, I can easily catch the case 
one same index be alloc twice by thread 0.

thread 0: alloc: 145
thread 0: alloc: 69
thread 4 free: 151
thread 0: alloc: 151
thread 2 free: 149
thread 3 free: 155
thread 0: alloc: 149
thread 0: alloc: 149
thread 0: alloc: 58
thread 0: alloc: 9
thread 0: alloc: 29
thread 3 free: 146
thread 0: alloc: 146
thread 2 free: 153
thread 0: alloc: 144
thread 0: alloc: 153
thread 0: alloc: 124
thread 3 free: 25
thread 0: alloc: 25

From: Florin Coras [mailto:fcoras.li...@gmail.com]
Sent: Tuesday, August 28, 2018 10:24 AM
To: Yu, Ping 
Cc: Florin Coras (fcoras) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] TLS half open lock

Hi Ping,

The expectation is that all connects/listens come on the main thread (with the 
worker barrier held). In other words, we only need to support a one writer, 
multiple readers scenario.

Florin


On Aug 27, 2018, at 6:29 PM, Yu, Ping 
mailto:ping...@intel.com>> wrote:

Hi, Florin,

To check if it is about to expand is also lockless. Is there any issue if two 
threads check the pool simultaneously, and just one slot is available? One code 
will do normal get, and the other thread is expanding the pool?

Thanks
Ping

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, August 28, 2018 12:51 AM
To: Yu, Ping mailto:ping...@intel.com>>
Cc: Florin Coras (fcoras) mailto:fco...@cisco.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] TLS half open lock

Hi Ping,

The current implementation only locks the half-open pool if the pool is about 
to expand. This is done to increase speed by avoiding unnecessary locking, 
i.e., if pool is not about to expand, it should be safe to get a new element 
from it without affecting readers. Now the thing to figure out is why this is 
happening. Does the slowdown due to the “big lock” avoid some race or is there 
more to it?

First of all, how many workers do you have configured and how many sessions are 
you allocating/connecting? Do you see failed connects?

Your tls_ctx_half_open_get line numbers don’t match my code. Did you by chance 
modify something else?

Thanks,
Florin



On Aug 27, 2018, at 9:22 AM, Yu, Ping 
mailto:ping...@intel.com>> wrote:

Hello, all

Recently I found that the TLS half open lock is not well implemented, and if 
enabling multiple thread, there are chances to get the following core dump info 
in debug mode.

(gdb) where
#0  0x7f7a0848e428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7f7a0849002a in __GI_abort () at abort.c:89
#2  0x00407f0b in os_panic () at 
/home/pyu4/git-home/vpp_clean/vpp/src/vpp/vnet/main.c:331
#3  0x7f7a08867bd0 in debugger () at 
/home/pyu4/git-home/vpp_clean/vpp/src/vppinfra/error.c:84
#4  0x7f7a08868008 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0,
fmt=0x7f7a0a0add78 "%s:%d (%s) assertion `%s' fails") at 
/home/pyu4/git-home/vpp_clean/vpp/src/vppinfra/error.c:143
#5  0x7f7a09e10be0 in tls_ctx_half_open_get (ctx_index=48) at 
/home/pyu4/git-home/vpp_clean/vpp/src/vnet/tls/tls.c:126
#6  0x7f7a09e11889 in tls_session_connected_callback (tls_app_index=0, 
ho_ctx_index=48, tls_session=0x7f79c9b6d1c0,
is_fail=0 '\000') at 
/home/pyu4/git-home/vpp_clean/vpp/src/vnet/tls/tls.c:404
#7  0x7f7a09d5ea6e in session_stream_connect_notify (tc=0x7f79c9b655fc, 
is_fail=0 '\000')
at /home/pyu4/git-home/vpp_clean/vpp/src/vnet/session/session.c:648
#8  0x7f7a099cb969 in tcp46_syn_sent_inline (vm=0x7f79c8a25100, 
node=0x7f79c9a60500, from_frame=0x7f79c8b2a9c0, is_ip4=1)
at /home/pyu4/git-home/vpp_clean/vpp/src/vnet/tcp/tcp_input.c:2306
#9  0x7f7a099cbe00 in tcp4_syn_sent (vm=0x7f79c8a25100, 
node=0x7f79c9a60500, from_frame=0x7f79c8b2a9c0)
at /home/pyu4/git-home/vpp_clean/vpp/src/vnet/tcp/tcp_input.c:2387
#10 0x7f7a08fefa35 in dispatch_node (vm=0x7f79c8a25100, 
node=0x7f79c9a60500, type=VLIB_NODE_TYPE_INTERNAL,
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f79c8b2a9c0, 
last_time_stamp=902372436923868)
at /home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:988
#11 0x7f7a08feffee in dispatch_pending_node (vm=0x7f79c8a25100, 
pending_frame_index=7, last_time_stamp=902372436923868)
at /home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:1138
#12 0x7f7a08ff1bed in vlib_main_or_worker_loop (vm=0x7f79c8a25100, 
is_main=0)
at /home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:1554
#13 0x7f7a08ff240c in vlib_worker_loop (vm=0x7f79c8a25100) at 
/home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:1634
#14 0x7f7a09035541 in vlib_worker_thread_fn (arg=0x7f79ca4a41c0) at 
/home/pyu4/g

Re: [vpp-dev] TLS half open lock

2018-08-27 Thread Yu, Ping 
Hi, Florin,

To check if it is about to expand is also lockless. Is there any issue if two 
threads check the pool simultaneously, and just one slot is available? One code 
will do normal get, and the other thread is expanding the pool?

Thanks
Ping

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Tuesday, August 28, 2018 12:51 AM
To: Yu, Ping 
Cc: Florin Coras (fcoras) ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] TLS half open lock

Hi Ping,

The current implementation only locks the half-open pool if the pool is about 
to expand. This is done to increase speed by avoiding unnecessary locking, 
i.e., if pool is not about to expand, it should be safe to get a new element 
from it without affecting readers. Now the thing to figure out is why this is 
happening. Does the slowdown due to the “big lock” avoid some race or is there 
more to it?

First of all, how many workers do you have configured and how many sessions are 
you allocating/connecting? Do you see failed connects?

Your tls_ctx_half_open_get line numbers don’t match my code. Did you by chance 
modify something else?

Thanks,
Florin


On Aug 27, 2018, at 9:22 AM, Yu, Ping 
mailto:ping...@intel.com>> wrote:

Hello, all

Recently I found that the TLS half open lock is not well implemented, and if 
enabling multiple thread, there are chances to get the following core dump info 
in debug mode.

(gdb) where
#0  0x7f7a0848e428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x7f7a0849002a in __GI_abort () at abort.c:89
#2  0x00407f0b in os_panic () at 
/home/pyu4/git-home/vpp_clean/vpp/src/vpp/vnet/main.c:331
#3  0x7f7a08867bd0 in debugger () at 
/home/pyu4/git-home/vpp_clean/vpp/src/vppinfra/error.c:84
#4  0x7f7a08868008 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0,
fmt=0x7f7a0a0add78 "%s:%d (%s) assertion `%s' fails") at 
/home/pyu4/git-home/vpp_clean/vpp/src/vppinfra/error.c:143
#5  0x7f7a09e10be0 in tls_ctx_half_open_get (ctx_index=48) at 
/home/pyu4/git-home/vpp_clean/vpp/src/vnet/tls/tls.c:126
#6  0x7f7a09e11889 in tls_session_connected_callback (tls_app_index=0, 
ho_ctx_index=48, tls_session=0x7f79c9b6d1c0,
is_fail=0 '\000') at 
/home/pyu4/git-home/vpp_clean/vpp/src/vnet/tls/tls.c:404
#7  0x7f7a09d5ea6e in session_stream_connect_notify (tc=0x7f79c9b655fc, 
is_fail=0 '\000')
at /home/pyu4/git-home/vpp_clean/vpp/src/vnet/session/session.c:648
#8  0x7f7a099cb969 in tcp46_syn_sent_inline (vm=0x7f79c8a25100, 
node=0x7f79c9a60500, from_frame=0x7f79c8b2a9c0, is_ip4=1)
at /home/pyu4/git-home/vpp_clean/vpp/src/vnet/tcp/tcp_input.c:2306
#9  0x7f7a099cbe00 in tcp4_syn_sent (vm=0x7f79c8a25100, 
node=0x7f79c9a60500, from_frame=0x7f79c8b2a9c0)
at /home/pyu4/git-home/vpp_clean/vpp/src/vnet/tcp/tcp_input.c:2387
#10 0x7f7a08fefa35 in dispatch_node (vm=0x7f79c8a25100, 
node=0x7f79c9a60500, type=VLIB_NODE_TYPE_INTERNAL,
dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f79c8b2a9c0, 
last_time_stamp=902372436923868)
at /home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:988
#11 0x7f7a08feffee in dispatch_pending_node (vm=0x7f79c8a25100, 
pending_frame_index=7, last_time_stamp=902372436923868)
at /home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:1138
#12 0x7f7a08ff1bed in vlib_main_or_worker_loop (vm=0x7f79c8a25100, 
is_main=0)
at /home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:1554
#13 0x7f7a08ff240c in vlib_worker_loop (vm=0x7f79c8a25100) at 
/home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:1634
#14 0x7f7a09035541 in vlib_worker_thread_fn (arg=0x7f79ca4a41c0) at 
/home/pyu4/git-home/vpp_clean/vpp/src/vlib/threads.c:1760
#15 0x7f7a0888aa38 in clib_calljmp ()
   from 
/home/pyu4/git-home/vpp_clean/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so
#16 0x7f7761198d70 in ?? ()
#17 0x7f7a090300be in vlib_worker_thread_bootstrap_fn (arg=0x7f79ca4a41c0)
at /home/pyu4/git-home/vpp_clean/vpp/src/vlib/threads.c:684

seemly current code design may have race condition and to make the same index 
returned, and after one free one index, the other will cause core dump.
I did a simple fix to add a big lock as the following, and this kind of core 
dump never happen again.
Do you guys have a better solution for the lock?

+  clib_rwlock_writer_lock (&tm->half_open_rwlock);
   pool_get_aligned_will_expand (tm->half_open_ctx_pool, will_expand, 0);
   if (PREDICT_FALSE (will_expand && vlib_num_workers ()))
 {
-  clib_rwlock_writer_lock (&tm->half_open_rwlock);
   pool_get (tm->half_open_ctx_pool, ctx);
   memset (ctx, 0, sizeof (*ctx));
   ctx_index = ctx - tm->half_open_ctx_pool;
-  clib_rwlock_writer_unlock (&tm->half_open_rwlock);
 }
   else
 {
@@ -104,6 +103,8 @@ tls_ctx_half_open_alloc (void)
   memset (ctx, 0, sizeof (*ctx));
   ctx_ind

[vpp-dev] TLS half open lock

2018-08-27 Thread Yu, Ping 
Hello, all

Recently I found that the TLS half open lock is not well implemented, and if 
enabling multiple thread, there are chances to get the following core dump info 
in debug mode.


(gdb) where

#0  0x7f7a0848e428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54

#1  0x7f7a0849002a in __GI_abort () at abort.c:89

#2  0x00407f0b in os_panic () at 
/home/pyu4/git-home/vpp_clean/vpp/src/vpp/vnet/main.c:331

#3  0x7f7a08867bd0 in debugger () at 
/home/pyu4/git-home/vpp_clean/vpp/src/vppinfra/error.c:84

#4  0x7f7a08868008 in _clib_error (how_to_die=2, function_name=0x0, 
line_number=0,

fmt=0x7f7a0a0add78 "%s:%d (%s) assertion `%s' fails") at 
/home/pyu4/git-home/vpp_clean/vpp/src/vppinfra/error.c:143

#5  0x7f7a09e10be0 in tls_ctx_half_open_get (ctx_index=48) at 
/home/pyu4/git-home/vpp_clean/vpp/src/vnet/tls/tls.c:126

#6  0x7f7a09e11889 in tls_session_connected_callback (tls_app_index=0, 
ho_ctx_index=48, tls_session=0x7f79c9b6d1c0,

is_fail=0 '\000') at 
/home/pyu4/git-home/vpp_clean/vpp/src/vnet/tls/tls.c:404

#7  0x7f7a09d5ea6e in session_stream_connect_notify (tc=0x7f79c9b655fc, 
is_fail=0 '\000')

at /home/pyu4/git-home/vpp_clean/vpp/src/vnet/session/session.c:648

#8  0x7f7a099cb969 in tcp46_syn_sent_inline (vm=0x7f79c8a25100, 
node=0x7f79c9a60500, from_frame=0x7f79c8b2a9c0, is_ip4=1)

at /home/pyu4/git-home/vpp_clean/vpp/src/vnet/tcp/tcp_input.c:2306

#9  0x7f7a099cbe00 in tcp4_syn_sent (vm=0x7f79c8a25100, 
node=0x7f79c9a60500, from_frame=0x7f79c8b2a9c0)

at /home/pyu4/git-home/vpp_clean/vpp/src/vnet/tcp/tcp_input.c:2387

#10 0x7f7a08fefa35 in dispatch_node (vm=0x7f79c8a25100, 
node=0x7f79c9a60500, type=VLIB_NODE_TYPE_INTERNAL,

dispatch_state=VLIB_NODE_STATE_POLLING, frame=0x7f79c8b2a9c0, 
last_time_stamp=902372436923868)

at /home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:988

#11 0x7f7a08feffee in dispatch_pending_node (vm=0x7f79c8a25100, 
pending_frame_index=7, last_time_stamp=902372436923868)

at /home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:1138

#12 0x7f7a08ff1bed in vlib_main_or_worker_loop (vm=0x7f79c8a25100, 
is_main=0)

at /home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:1554

#13 0x7f7a08ff240c in vlib_worker_loop (vm=0x7f79c8a25100) at 
/home/pyu4/git-home/vpp_clean/vpp/src/vlib/main.c:1634

#14 0x7f7a09035541 in vlib_worker_thread_fn (arg=0x7f79ca4a41c0) at 
/home/pyu4/git-home/vpp_clean/vpp/src/vlib/threads.c:1760

#15 0x7f7a0888aa38 in clib_calljmp ()

   from 
/home/pyu4/git-home/vpp_clean/vpp/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so

#16 0x7f7761198d70 in ?? ()

#17 0x7f7a090300be in vlib_worker_thread_bootstrap_fn (arg=0x7f79ca4a41c0)

at /home/pyu4/git-home/vpp_clean/vpp/src/vlib/threads.c:684



seemly current code design may have race condition and to make the same index 
returned, and after one free one index, the other will cause core dump.

I did a simple fix to add a big lock as the following, and this kind of core 
dump never happen again.

Do you guys have a better solution for the lock?



+  clib_rwlock_writer_lock (&tm->half_open_rwlock);

   pool_get_aligned_will_expand (tm->half_open_ctx_pool, will_expand, 0);

   if (PREDICT_FALSE (will_expand && vlib_num_workers ()))

 {

-  clib_rwlock_writer_lock (&tm->half_open_rwlock);

   pool_get (tm->half_open_ctx_pool, ctx);

   memset (ctx, 0, sizeof (*ctx));

   ctx_index = ctx - tm->half_open_ctx_pool;

-  clib_rwlock_writer_unlock (&tm->half_open_rwlock);

 }

   else

 {

@@ -104,6 +103,8 @@ tls_ctx_half_open_alloc (void)

   memset (ctx, 0, sizeof (*ctx));

   ctx_index = ctx - tm->half_open_ctx_pool;

 }

+  clib_rwlock_writer_unlock (&tm->half_open_rwlock);

   return ctx_index;

}








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10302): https://lists.fd.io/g/vpp-dev/message/10302
Mute This Topic: https://lists.fd.io/mt/24975100/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] TCP retransmission

2018-08-23 Thread Yu, Ping 
Thanks Florin, and this fix works pretty well.
Before the fix, it has problem to handle >500 sessions, and in this patch, it 
works fine even >1 sessions. ☺


From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Florin Coras
Sent: Friday, August 24, 2018 9:37 AM
To: Yu, Ping 
Cc: vpp-dev@lists.fd.io; Florin Coras (fcoras) 
Subject: Re: [vpp-dev] TCP retransmission

Ping,

Does this [1] fix the issues you’ve encountered?

Thanks,
Florin

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


On Aug 23, 2018, at 6:54 AM, Yu, Ping 
mailto:ping...@intel.com>> wrote:

By checking these active session, we can see that in client side, these 
sessions has sent out 8192 bytes, and the received < 8192 bytes, so echo client 
is still waiting for packets.

Rx fifo: cursize 0 nitems 65536 has_event 0
head 4284 tail 4284 segment manager 4
vpp session 62 thread 0 app session 237 thread 0
ooo pool 1 active elts newest 4294967295
   [2856, 3908], len 1052, next -1, prev -1
Tx fifo: cursize 0 nitems 65536 has_event 0


While at the server side, we can see even if server has received 8192 bytes 
from clients, and even if the tx tail is set to be 8192, but the head is <8192.


Rx fifo: cursize 0 nitems 65536 has_event 0
head 8192 tail 8192 segment manager 2
vpp session 4 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
Tx fifo: cursize 3908 nitems 65536 has_event 0
head 4284 tail 8192 segment manager 2

thanks
Ping


From: Yu, Ping
Sent: Thursday, August 23, 2018 4:49 PM
To: Florin Coras mailto:fcoras.li...@gmail.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Florin Coras (fcoras) 
mailto:fco...@cisco.com>>; Yu, Ping 
mailto:ping...@intel.com>>
Subject: RE: [vpp-dev] TCP retransmission

Verbose 1 also shows some info below. Interesting to see the session index are 
continuous.

[#0][T] 10.10.1.1:->10.10.1.2:23630   ESTABLISHED0 
63056 71
[#0][T] 10.10.1.1:->10.10.1.2:59371   ESTABLISHED0 
63056 72
[#0][T] 10.10.1.1:->10.10.1.2:20412   ESTABLISHED0 
63056 73
[#0][T] 10.10.1.1:->10.10.1.2:2961ESTABLISHED0 
63056 74
[#0][T] 10.10.1.1:->10.10.1.2:52858   ESTABLISHED0 
63056 75
[#0][T] 10.10.1.1:->10.10.1.2:58311   ESTABLISHED0 
63056 76
[#0][T] 10.10.1.1:->10.10.1.2:49160   ESTABLISHED0 
63056 77
[#0][T] 10.10.1.1:->10.10.1.2:38413   ESTABLISHED0 
63056 78
[#0][T] 10.10.1.1:->10.10.1.2:65510   ESTABLISHED0 
63056 79
[#0][T] 10.10.1.1:->10.10.1.2:3043ESTABLISHED0 
63056 80
[#0][T] 10.10.1.1:->10.10.1.2:15764   ESTABLISHED0 
63056 81
[#0][T] 10.10.1.1:->10.10.1.2:21193   ESTABLISHED0 
63056 82
[#0][T] 10.10.1.1:->10.10.1.2:56466   ESTABLISHED0 
63056 83
[#0][T] 10.10.1.1:->10.10.1.2:64575   ESTABLISHED0 
63056 84
[#0][T] 10.10.1.1:->10.10.1.2:54368   ESTABLISHED0 
63056 85
[#0][T] 10.10.1.1:->10.10.1.2:32197   ESTABLISHED0 
63056 86
[#0][T] 10.10.1.1:->10.10.1.2:36990   ESTABLISHED0 
63056 87
[#0][T] 10.10.1.1:->10.10.1.2:37083   ESTABLISHED0 
63056 88
[#0][T] 10.10.1.1:->10.10.1.2:11431   ESTABLISHED0 
61628 411
[#0][T] 10.10.1.1:->10.10.1.2:49626   ESTABLISHED0 
61628 412
[#0][T] 10.10.1.1:->10.10.1.2:42865   ESTABLISHED0 
61628 413
[#0][T] 10.10.1.1:->10.10.1.2:31260   ESTABLISHED0 
61628 414
[#0][T] 10.10.1.1:->10.10.1.2:20171   ESTABLISHED0 
61628 415
[#0][T] 10.10.1.1:->10.10.1.2:54702   ESTABLISHED0 
61628 416
[#0][T] 10.10.1.1:->10.10.1.2:8501ESTABLISHED0     
61628 417
[#0][T] 10.10.1.1:->10.10.1.2:49424   ESTABLISHED0 
61628 418



From: Yu, Ping
Sent: Thursday, August 23, 2018 4:40 PM
To: Florin Coras mailto:fcoras.li...@gmail.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Florin Coras (fcoras) 
mailto:fco...@cisco.com>>; Yu, Ping 
mailto:ping...@intel.com>>
Subject: RE: [vpp-dev] TCP retransmission

Hi, Florin,

Attached is the some active session live after echo client timeout.


[#0][T] 10.10.1.1:->10.10.1.2:61337   ESTABLISHED
flags: Recovery timers: []
snd_una 4285 snd_nxt 4285 snd_una_max 4285 rcv_nxt 8193 rcv_las 8193
snd_wnd 65536 rcv_wnd 65536 snd_wl1 8193 snd_wl2 4285
flight size 0 out space 2856 cc space 2856 rcv_wnd_av 65536
cong recovery cwnd 2856 ssthresh 2856 rtx_bytes 0 byte

Re: [vpp-dev] TCP retransmission

2018-08-23 Thread Yu, Ping 
By checking these active session, we can see that in client side, these 
sessions has sent out 8192 bytes, and the received < 8192 bytes, so echo client 
is still waiting for packets.

Rx fifo: cursize 0 nitems 65536 has_event 0
head 4284 tail 4284 segment manager 4
vpp session 62 thread 0 app session 237 thread 0
ooo pool 1 active elts newest 4294967295
   [2856, 3908], len 1052, next -1, prev -1
Tx fifo: cursize 0 nitems 65536 has_event 0


While at the server side, we can see even if server has received 8192 bytes 
from clients, and even if the tx tail is set to be 8192, but the head is <8192.


Rx fifo: cursize 0 nitems 65536 has_event 0
head 8192 tail 8192 segment manager 2
vpp session 4 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
Tx fifo: cursize 3908 nitems 65536 has_event 0
head 4284 tail 8192 segment manager 2

thanks
Ping


From: Yu, Ping
Sent: Thursday, August 23, 2018 4:49 PM
To: Florin Coras 
Cc: vpp-dev@lists.fd.io; Florin Coras (fcoras) ; Yu, Ping 

Subject: RE: [vpp-dev] TCP retransmission

Verbose 1 also shows some info below. Interesting to see the session index are 
continuous.

[#0][T] 10.10.1.1:->10.10.1.2:23630   ESTABLISHED0 
63056 71
[#0][T] 10.10.1.1:->10.10.1.2:59371   ESTABLISHED0 
63056 72
[#0][T] 10.10.1.1:->10.10.1.2:20412   ESTABLISHED0 
63056 73
[#0][T] 10.10.1.1:->10.10.1.2:2961ESTABLISHED0 
63056 74
[#0][T] 10.10.1.1:->10.10.1.2:52858   ESTABLISHED0 
63056 75
[#0][T] 10.10.1.1:->10.10.1.2:58311   ESTABLISHED0 
63056 76
[#0][T] 10.10.1.1:->10.10.1.2:49160   ESTABLISHED0 
63056 77
[#0][T] 10.10.1.1:->10.10.1.2:38413   ESTABLISHED0 
63056 78
[#0][T] 10.10.1.1:->10.10.1.2:65510   ESTABLISHED0 
63056 79
[#0][T] 10.10.1.1:->10.10.1.2:3043ESTABLISHED0 
63056 80
[#0][T] 10.10.1.1:->10.10.1.2:15764   ESTABLISHED0 
63056 81
[#0][T] 10.10.1.1:->10.10.1.2:21193   ESTABLISHED0 
63056 82
[#0][T] 10.10.1.1:->10.10.1.2:56466   ESTABLISHED0 
63056 83
[#0][T] 10.10.1.1:->10.10.1.2:64575   ESTABLISHED0 
63056 84
[#0][T] 10.10.1.1:->10.10.1.2:54368   ESTABLISHED0 
63056 85
[#0][T] 10.10.1.1:->10.10.1.2:32197   ESTABLISHED0 
63056 86
[#0][T] 10.10.1.1:->10.10.1.2:36990   ESTABLISHED0 
63056 87
[#0][T] 10.10.1.1:->10.10.1.2:37083   ESTABLISHED0 
63056 88
[#0][T] 10.10.1.1:->10.10.1.2:11431   ESTABLISHED0 
61628 411
[#0][T] 10.10.1.1:->10.10.1.2:49626   ESTABLISHED0 
61628 412
[#0][T] 10.10.1.1:->10.10.1.2:42865   ESTABLISHED0 
61628 413
[#0][T] 10.10.1.1:->10.10.1.2:31260   ESTABLISHED0 
61628 414
[#0][T] 10.10.1.1:->10.10.1.2:20171   ESTABLISHED0 
61628 415
[#0][T] 10.10.1.1:->10.10.1.2:54702   ESTABLISHED0 
61628 416
[#0][T] 10.10.1.1:->10.10.1.2:8501ESTABLISHED0 
61628 417
[#0][T] 10.10.1.1:1111->10.10.1.2:49424   ESTABLISHED0 
61628 418



From: Yu, Ping
Sent: Thursday, August 23, 2018 4:40 PM
To: Florin Coras mailto:fcoras.li...@gmail.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>; Florin Coras (fcoras) 
mailto:fco...@cisco.com>>; Yu, Ping 
mailto:ping...@intel.com>>
Subject: RE: [vpp-dev] TCP retransmission

Hi, Florin,

Attached is the some active session live after echo client timeout.


[#0][T] 10.10.1.1:->10.10.1.2:61337   ESTABLISHED
flags: Recovery timers: []
snd_una 4285 snd_nxt 4285 snd_una_max 4285 rcv_nxt 8193 rcv_las 8193
snd_wnd 65536 rcv_wnd 65536 snd_wl1 8193 snd_wl2 4285
flight size 0 out space 2856 cc space 2856 rcv_wnd_av 65536
cong recovery cwnd 2856 ssthresh 2856 rtx_bytes 0 bytes_acked 0
prev_ssthresh 524288 snd_congestion 8193 dupack 0 limited_transmit 1746905375
tsecr 1714832397 tsecr_last_ack 1714832397
rto 200 rto_boff 0 srtt 6 rttvar 2 rtt_ts 0 rtt_seq 2548066206
tsval_recent 81891189 tsval_recent_age 13028
scoreboard: sacked_bytes 0 last_sacked_bytes 0 lost_bytes 0
last_bytes_delivered 0 high_sacked 2548066206 snd_una_adv 0
cur_rxt_hole 4294967295 high_rxt 0 rescue_rxt 0
Rx fifo: cursize 0 nitems 65536 has_event 0
head 8192 tail 8192 segment manager 2
vpp session 4 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
Tx fifo: cursize 3908 nitems 65536 has_event 0
head 4284 tail 8192 segment manager 2
vpp session 4 thread 0 app session 0 thread 0
ooo pool 0 act

Re: [vpp-dev] TCP retransmission

2018-08-23 Thread Yu, Ping 
Verbose 1 also shows some info below. Interesting to see the session index are 
continuous.

[#0][T] 10.10.1.1:->10.10.1.2:23630   ESTABLISHED0 
63056 71
[#0][T] 10.10.1.1:->10.10.1.2:59371   ESTABLISHED0 
63056 72
[#0][T] 10.10.1.1:->10.10.1.2:20412   ESTABLISHED0 
63056 73
[#0][T] 10.10.1.1:->10.10.1.2:2961ESTABLISHED0 
63056 74
[#0][T] 10.10.1.1:->10.10.1.2:52858   ESTABLISHED0 
63056 75
[#0][T] 10.10.1.1:->10.10.1.2:58311   ESTABLISHED0 
63056 76
[#0][T] 10.10.1.1:->10.10.1.2:49160   ESTABLISHED0 
63056 77
[#0][T] 10.10.1.1:->10.10.1.2:38413   ESTABLISHED0 
63056 78
[#0][T] 10.10.1.1:->10.10.1.2:65510   ESTABLISHED0 
63056 79
[#0][T] 10.10.1.1:->10.10.1.2:3043ESTABLISHED0 
63056 80
[#0][T] 10.10.1.1:->10.10.1.2:15764   ESTABLISHED0 
63056 81
[#0][T] 10.10.1.1:->10.10.1.2:21193   ESTABLISHED0 
63056 82
[#0][T] 10.10.1.1:->10.10.1.2:56466   ESTABLISHED0 
63056 83
[#0][T] 10.10.1.1:->10.10.1.2:64575   ESTABLISHED0 
63056 84
[#0][T] 10.10.1.1:->10.10.1.2:54368   ESTABLISHED0 
63056 85
[#0][T] 10.10.1.1:->10.10.1.2:32197   ESTABLISHED0 
63056 86
[#0][T] 10.10.1.1:->10.10.1.2:36990   ESTABLISHED0 
63056 87
[#0][T] 10.10.1.1:->10.10.1.2:37083   ESTABLISHED0 
63056 88
[#0][T] 10.10.1.1:->10.10.1.2:11431   ESTABLISHED0 
61628 411
[#0][T] 10.10.1.1:->10.10.1.2:49626   ESTABLISHED0 
61628 412
[#0][T] 10.10.1.1:->10.10.1.2:42865   ESTABLISHED0 
61628 413
[#0][T] 10.10.1.1:->10.10.1.2:31260   ESTABLISHED0 
61628 414
[#0][T] 10.10.1.1:->10.10.1.2:20171   ESTABLISHED0 
61628 415
[#0][T] 10.10.1.1:->10.10.1.2:54702   ESTABLISHED0 
61628 416
[#0][T] 10.10.1.1:->10.10.1.2:8501ESTABLISHED0 
61628 417
[#0][T] 10.10.1.1:->10.10.1.2:49424   ESTABLISHED0 
61628 418



From: Yu, Ping
Sent: Thursday, August 23, 2018 4:40 PM
To: Florin Coras 
Cc: vpp-dev@lists.fd.io; Florin Coras (fcoras) ; Yu, Ping 

Subject: RE: [vpp-dev] TCP retransmission

Hi, Florin,

Attached is the some active session live after echo client timeout.


[#0][T] 10.10.1.1:->10.10.1.2:61337   ESTABLISHED
flags: Recovery timers: []
snd_una 4285 snd_nxt 4285 snd_una_max 4285 rcv_nxt 8193 rcv_las 8193
snd_wnd 65536 rcv_wnd 65536 snd_wl1 8193 snd_wl2 4285
flight size 0 out space 2856 cc space 2856 rcv_wnd_av 65536
cong recovery cwnd 2856 ssthresh 2856 rtx_bytes 0 bytes_acked 0
prev_ssthresh 524288 snd_congestion 8193 dupack 0 limited_transmit 1746905375
tsecr 1714832397 tsecr_last_ack 1714832397
rto 200 rto_boff 0 srtt 6 rttvar 2 rtt_ts 0 rtt_seq 2548066206
tsval_recent 81891189 tsval_recent_age 13028
scoreboard: sacked_bytes 0 last_sacked_bytes 0 lost_bytes 0
last_bytes_delivered 0 high_sacked 2548066206 snd_una_adv 0
cur_rxt_hole 4294967295 high_rxt 0 rescue_rxt 0
Rx fifo: cursize 0 nitems 65536 has_event 0
head 8192 tail 8192 segment manager 2
vpp session 4 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
Tx fifo: cursize 3908 nitems 65536 has_event 0
head 4284 tail 8192 segment manager 2
vpp session 4 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
[#0][T] 10.10.1.1:->10.10.1.2:2210ESTABLISHED
flags: Recovery timers: []
snd_una 4285 snd_nxt 4285 snd_una_max 4285 rcv_nxt 8193 rcv_las 8193
snd_wnd 65536 rcv_wnd 65536 snd_wl1 8193 snd_wl2 4285
flight size 0 out space 2856 cc space 2856 rcv_wnd_av 65536
cong recovery cwnd 2856 ssthresh 2856 rtx_bytes 0 bytes_acked 0
prev_ssthresh 524288 snd_congestion 8193 dupack 0 limited_transmit 1746905375
tsecr 1714832397 tsecr_last_ack 1714832397
rto 200 rto_boff 0 srtt 6 rttvar 2 rtt_ts 0 rtt_seq 2548066206
tsval_recent 81891189 tsval_recent_age 13028
scoreboard: sacked_bytes 0 last_sacked_bytes 0 lost_bytes 0
last_bytes_delivered 0 high_sacked 2548066206 snd_una_adv 0
cur_rxt_hole 4294967295 high_rxt 0 rescue_rxt 0
Rx fifo: cursize 0 nitems 65536 has_event 0
head 8192 tail 8192 segment manager 2
vpp session 5 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
Tx fifo: cursize 3908 nitems 65536 has_event 0
head 4284 tail 8192 segment manager 2
vpp session 5 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
[#0][T] 10.10.1.1:->10.10.1.2:30199   ESTABLISHED
flags: Recovery timers

Re: [vpp-dev] TCP retransmission

2018-08-23 Thread Yu, Ping 
Hi, Florin,

Attached is the some active session live after echo client timeout.


[#0][T] 10.10.1.1:->10.10.1.2:61337   ESTABLISHED
flags: Recovery timers: []
snd_una 4285 snd_nxt 4285 snd_una_max 4285 rcv_nxt 8193 rcv_las 8193
snd_wnd 65536 rcv_wnd 65536 snd_wl1 8193 snd_wl2 4285
flight size 0 out space 2856 cc space 2856 rcv_wnd_av 65536
cong recovery cwnd 2856 ssthresh 2856 rtx_bytes 0 bytes_acked 0
prev_ssthresh 524288 snd_congestion 8193 dupack 0 limited_transmit 1746905375
tsecr 1714832397 tsecr_last_ack 1714832397
rto 200 rto_boff 0 srtt 6 rttvar 2 rtt_ts 0 rtt_seq 2548066206
tsval_recent 81891189 tsval_recent_age 13028
scoreboard: sacked_bytes 0 last_sacked_bytes 0 lost_bytes 0
last_bytes_delivered 0 high_sacked 2548066206 snd_una_adv 0
cur_rxt_hole 4294967295 high_rxt 0 rescue_rxt 0
Rx fifo: cursize 0 nitems 65536 has_event 0
head 8192 tail 8192 segment manager 2
vpp session 4 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
Tx fifo: cursize 3908 nitems 65536 has_event 0
head 4284 tail 8192 segment manager 2
vpp session 4 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
[#0][T] 10.10.1.1:->10.10.1.2:2210ESTABLISHED
flags: Recovery timers: []
snd_una 4285 snd_nxt 4285 snd_una_max 4285 rcv_nxt 8193 rcv_las 8193
snd_wnd 65536 rcv_wnd 65536 snd_wl1 8193 snd_wl2 4285
flight size 0 out space 2856 cc space 2856 rcv_wnd_av 65536
cong recovery cwnd 2856 ssthresh 2856 rtx_bytes 0 bytes_acked 0
prev_ssthresh 524288 snd_congestion 8193 dupack 0 limited_transmit 1746905375
tsecr 1714832397 tsecr_last_ack 1714832397
rto 200 rto_boff 0 srtt 6 rttvar 2 rtt_ts 0 rtt_seq 2548066206
tsval_recent 81891189 tsval_recent_age 13028
scoreboard: sacked_bytes 0 last_sacked_bytes 0 lost_bytes 0
last_bytes_delivered 0 high_sacked 2548066206 snd_una_adv 0
cur_rxt_hole 4294967295 high_rxt 0 rescue_rxt 0
Rx fifo: cursize 0 nitems 65536 has_event 0
head 8192 tail 8192 segment manager 2
vpp session 5 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
Tx fifo: cursize 3908 nitems 65536 has_event 0
head 4284 tail 8192 segment manager 2
vpp session 5 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
[#0][T] 10.10.1.1:->10.10.1.2:30199   ESTABLISHED
flags: Recovery timers: []
snd_una 5713 snd_nxt 5713 snd_una_max 5713 rcv_nxt 8193 rcv_las 8193
snd_wnd 65536 rcv_wnd 65536 snd_wl1 8193 snd_wl2 5713
flight size 0 out space 2856 cc space 2856 rcv_wnd_av 65536
cong recovery cwnd 2856 ssthresh 2856 rtx_bytes 0 bytes_acked 0
prev_ssthresh 524288 snd_congestion 8193 dupack 0 limited_transmit 1748569900
tsecr 1714832397 tsecr_last_ack 1714832397
rto 200 rto_boff 0 srtt 6 rttvar 1 rtt_ts 0 rtt_seq 2546405589
tsval_recent 81891189 tsval_recent_age 13028
scoreboard: sacked_bytes 0 last_sacked_bytes 0 lost_bytes 0
last_bytes_delivered 0 high_sacked 2546403109 snd_una_adv 0
cur_rxt_hole 4294967295 high_rxt 0 rescue_rxt 0
Rx fifo: cursize 0 nitems 65536 has_event 0
head 8192 tail 8192 segment manager 2
vpp session 30 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
Tx fifo: cursize 2480 nitems 65536 has_event 0
head 5712 tail 8192 segment manager 2
vpp session 30 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
[#0][T] 10.10.1.1:->10.10.1.2:4   ESTABLISHED
flags: Recovery timers: []
snd_una 5713 snd_nxt 5713 snd_una_max 5713 rcv_nxt 8193 rcv_las 8193
snd_wnd 65536 rcv_wnd 65536 snd_wl1 8193 snd_wl2 5713
flight size 0 out space 2856 cc space 2856 rcv_wnd_av 65536
cong recovery cwnd 2856 ssthresh 2856 rtx_bytes 0 bytes_acked 0
prev_ssthresh 524288 snd_congestion 8193 dupack 0 limited_transmit 1748569900
tsecr 1714832397 tsecr_last_ack 1714832397
rto 200 rto_boff 0 srtt 6 rttvar 1 rtt_ts 0 rtt_seq 2546405589
tsval_recent 81891189 tsval_recent_age 13028
scoreboard: sacked_bytes 0 last_sacked_bytes 0 lost_bytes 0
last_bytes_delivered 0 high_sacked 2546403109 snd_una_adv 0
cur_rxt_hole 4294967295 high_rxt 0 rescue_rxt 0
Rx fifo: cursize 0 nitems 65536 has_event 0
head 8192 tail 8192 segment manager 2
vpp session 31 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295
Tx fifo: cursize 2480 nitems 65536 has_event 0
head 5712 tail 8192 segment manager 2
vpp session 31 thread 0 app session 0 thread 0
ooo pool 0 active elts newest 4294967295

From: Florin Coras [mailto:fcoras.li...@gmail.com]
Sent: Tuesday, August 21, 2018 11:18 PM
To: Yu, Ping 
Cc: vpp-dev@lists.fd.io; Florin Coras (fcoras) 
Subject: Re: [vpp-dev] TCP retransmission

Hi Ping,

Just from this, I can’t tell precisely what the issue is. Once the test hangs, 
do “show session verbose 2” and you should get the detailed status of the 
sessions that froze. I’ll take a look at those once I’m back in the office. 
Retransmissions should work fine but one never knows. On the other hand, the 
echo apps may be missing some io events. Did vpp report any other error message?

Flo

[vpp-dev] TCP retransmission

2018-08-21 Thread Yu, Ping 
Hello, all

I am now debugging an issue observed in echo server/client. If nclients == 
small number, then everything goes smoothly, but if nclients is big, such as 
500, 1000, echo client will hang without printing final report, and debug shows 
that echo client is waiting for response from server as it is expecting server 
to send bytes_to_receive to client.  The problems occurs in both TCP and TLS 
protocol.

if (sp->bytes_to_receive > 0)
{
  delete_session = 0;
}

My assumption is that due to the big traffic, some packet is missing and 
re-transmission does not work well. Below the info for normal case, where 
nclients == 100.


DBGvpp# show error

   CountNode  Reason

   600  session-queue Packets transmitted

   100tcp4-rcv-processPure ACKs received

   100tcp4-rcv-processFINs received

   600tcp4-establishedPackets pushed into rx fifo

   600tcp4-establishedPure ACKs received

32ip4-glean   address overflow drops

 1ip4-glean   ARP requests sent

 1arp-input   ARP request IP4 source 
address learned





Server:

DBGvpp# show error

   CountNode  Reason

   600  session-queue Packets transmitted

   100   tcp4-listen  SYNs received

   200tcp4-rcv-processPure ACKs received

   600tcp4-establishedPackets pushed into rx fifo

   600tcp4-establishedPure ACKs received

   100tcp4-establishedFINs received

 1arp-input   ARP replies sent


Below is the info when nclients == 500.


Client:



DBGvpp# show error

   CountNode  Reason

  3104  session-queue Packets transmitted

   498tcp4-rcv-processPure ACKs received

   498tcp4-rcv-processFINs received

  2998tcp4-establishedPackets pushed into rx fifo

  2892tcp4-establishedPure ACKs received

   106tcp4-establishedDuplicate ACK



Server:

DBGvpp# show error

   CountNode  Reason

  2998  session-queue Packets transmitted

   500   tcp4-listen  SYNs received

   998tcp4-rcv-processPure ACKs received

  2996tcp4-establishedPackets pushed into rx fifo/

 2tcp4-establishedOOO packets pushed into rx 
fifo

  2476tcp4-establishedPure ACKs received

   498tcp4-establishedFINs received

We can see that in clients side, packets transmission is 3104, which is bigger 
than normal case 600*5, but in the server side, the recived packet is only 
2996, which is below 3000, which causes only 498 FIN is sent from client, so 2 
live session makes "test echo" hang until timeout.


Thanks
Ping

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10233): https://lists.fd.io/g/vpp-dev/message/10233
Mute This Topic: https://lists.fd.io/mt/24876529/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] tls init server is too heavy

2018-08-12 Thread Yu, Ping 
Hi, Florin,

Based on this discuss, I have submitted a code review #14156 for this. Please 
help review it.

The main change is:

1)  Add a point in ctx_id to point engine specific data, and point to a 
openssl_tls_ctx data structure.

2)  Add 2 engine specific API such for start listen and stop listen.

3)  CPS performance has been improved around 30% after this patch.

4)  Main implementation in openssl, and will not break mbedtls.

Thanks
Ping

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Yu, Ping
Sent: Thursday, July 26, 2018 9:26 AM
To: Florin Coras (fcoras) ; vpp-dev@lists.fd.io
Cc: Yu, Ping 
Subject: Re: [vpp-dev] tls init server is too heavy

That’s great. I will implement it and submit patch for this optimization.

Ping

From: Florin Coras (fcoras) [mailto:fco...@cisco.com]
Sent: Thursday, July 26, 2018 1:01 AM
To: Yu, Ping mailto:ping...@intel.com>>; 
vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: tls init server is too heavy

Hi Ping,

The plan you proposed sounds great, so definitely go for it! You’ll have to 
find a place to store a pointer to the shared engine-generated context (i.e., 
ssl_ctx) in the generic listener context. If no obvious field is available, 
maybe you can abuse the ctx_id since we still have space there (note that it’s 
limited to 42B).

Let me know how it goes!

Cheers,
Florin

From: "Yu, Ping" mailto:ping...@intel.com>>
Date: Wednesday, July 25, 2018 at 9:13 AM
To: "Florin Coras (fcoras)" mailto:fco...@cisco.com>>, 
"vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Cc: "Yu, Ping" mailto:ping...@intel.com>>
Subject: tls init server is too heavy

Hello, Florin

In current TLS openssl implementation, in each accepted TLS session, 
openssl_ctx_init_server needs to re-init ssl_ctx, and set key and certificate, 
which actually is not necessary, and normally one-time initialization is good 
enough. After I change this initialization to run only once, I can get around 
20~30% performance improvement for CPS.
I am now considering to re-architect this initialization, and one possible 
point is to move this to tls_start_listen. A generic tls_ssl_ctx_init can be 
the interface, then it will call engine specific, such as openssl ssl_ctx 
initialization afterward. How do you think?

Thanks
Ping




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10109): https://lists.fd.io/g/vpp-dev/message/10109
Mute This Topic: https://lists.fd.io/mt/23814247/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] tls init server is too heavy

2018-07-25 Thread Yu, Ping 
That’s great. I will implement it and submit patch for this optimization.

Ping

From: Florin Coras (fcoras) [mailto:fco...@cisco.com]
Sent: Thursday, July 26, 2018 1:01 AM
To: Yu, Ping ; vpp-dev@lists.fd.io
Subject: Re: tls init server is too heavy

Hi Ping,

The plan you proposed sounds great, so definitely go for it! You’ll have to 
find a place to store a pointer to the shared engine-generated context (i.e., 
ssl_ctx) in the generic listener context. If no obvious field is available, 
maybe you can abuse the ctx_id since we still have space there (note that it’s 
limited to 42B).

Let me know how it goes!

Cheers,
Florin

From: "Yu, Ping" mailto:ping...@intel.com>>
Date: Wednesday, July 25, 2018 at 9:13 AM
To: "Florin Coras (fcoras)" mailto:fco...@cisco.com>>, 
"vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" 
mailto:vpp-dev@lists.fd.io>>
Cc: "Yu, Ping" mailto:ping...@intel.com>>
Subject: tls init server is too heavy

Hello, Florin

In current TLS openssl implementation, in each accepted TLS session, 
openssl_ctx_init_server needs to re-init ssl_ctx, and set key and certificate, 
which actually is not necessary, and normally one-time initialization is good 
enough. After I change this initialization to run only once, I can get around 
20~30% performance improvement for CPS.
I am now considering to re-architect this initialization, and one possible 
point is to move this to tls_start_listen. A generic tls_ssl_ctx_init can be 
the interface, then it will call engine specific, such as openssl ssl_ctx 
initialization afterward. How do you think?

Thanks
Ping




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9935): https://lists.fd.io/g/vpp-dev/message/9935
Mute This Topic: https://lists.fd.io/mt/23814247/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] tls init server is too heavy

2018-07-25 Thread Yu, Ping 
Hello, Florin

In current TLS openssl implementation, in each accepted TLS session, 
openssl_ctx_init_server needs to re-init ssl_ctx, and set key and certificate, 
which actually is not necessary, and normally one-time initialization is good 
enough. After I change this initialization to run only once, I can get around 
20~30% performance improvement for CPS.
I am now considering to re-architect this initialization, and one possible 
point is to move this to tls_start_listen. A generic tls_ssl_ctx_init can be 
the interface, then it will call engine specific, such as openssl ssl_ctx 
initialization afterward. How do you think?

Thanks
Ping




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#9932): https://lists.fd.io/g/vpp-dev/message/9932
Mute This Topic: https://lists.fd.io/mt/23814247/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] too much memory needed to build gbp_contract

2018-03-21 Thread Yu, Ping 
Hello, all

After setting several memory to be huge pages, I found that VPP build has some 
problem when building gbp_contract. System reports several page fault in dmesg, 
and build will hang for couple of hours. 
Build info is below:

  CXX  l2_emulation_cmds.lo
  CXX  l2_emulation.lo
  CXX  gbp_endpoint_cmds.lo
  CXX  gbp_endpoint.lo
  CXX  gbp_contract_cmds.lo
  CXX  gbp_contract.lo

I have not dig into the details, and it looks cc1plus costs too much memory in 
"top". If vpp build needs a huge memory, then I'd like to suggest a memory 
check could be performed before building. 

Ping

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

You receive all messages sent to this group.

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

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