Re: [vpp-dev] [tsc] Project Proposal for uDPI

[Ni, Hongjun]

Hi Ed,

Thank you for scheduling the proposal review.

I think a TSC meeting after Aug 21 is better, to follow the FD.io TSC policy.

Thanks,
Hongjun

From: Ed Warnicke [mailto:hagb...@gmail.com]
Sent: Wednesday, August 14, 2019 5:09 AM
To: Ni, Hongjun 
Cc: t...@lists.fd.io; vpp-dev@lists.fd.io; Wang, Xiang W 
; Hong, Yang A ; Chang, Harry 
; gu.ji...@zte.com.cn; Shan Jianghua 
; Zhang Yang ; Li 
Xingfu ; Wu Shuai ; Xia Yuying 
; Fan Chenggang ; Gao Feng 
; Liu Zhong ; Zhao Yong 
; Chen Haiquan 
Subject: Re: [tsc] Project Proposal for uDPI

Hongjun,

You guys are eligible for project creation review starting at the Aug 21 TSC 
meeting I believe (based on sending the notification to the TSC on Aug 8) ... 
when would you like to schedule for that Thu's TSC meeting, or a subsequent one?

Ed

On Thu, Aug 8, 2019 at 8:11 PM Ni, Hongjun 
mailto:hongjun...@intel.com>> wrote:
Hello FD.io TSCs

Please accept this project proposal for uDPI for consideration.
https://wiki.fd.io/view/Project_Proposals/uDPI

So far, this project has 11 founders and 15 initial committers from
Intel, ZTE, China Telecom, HuachenTel, Inspur, Yxlink, Sunyainfo, Tencent, 
China Unicom, Huawei, QingCloud.

If possible, I would like to present this on TSC meeting.

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

View/Reply Online (#1070): https://lists.fd.io/g/tsc/message/1070
Mute This Topic: https://lists.fd.io/mt/32805806/464962
Group Owner: tsc+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/tsc/unsub  
[hagb...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] ipsec packets fragmented post encryption

[Caffeine Coder via Lists.Fd.Io]

Hi,I am on 18.10 and trying to enable reassembly and fragmentation. It is 
working fine for vxlan and vxlan-gpe tunnels but IPSec it is not.We set 
physical interface MTU to be 1500 and IPSEC interface MTU to 1350 to give room 
for encryption.
The issue we are seeing is packets are getting fragmented sent out after 
encryption and causing traffic is getting dropped.Is there any different way to 
enable fragmentation and then encryption each fragment on 18.10.

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

View/Reply Online (#13728): https://lists.fd.io/g/vpp-dev/message/13728
Mute This Topic: https://lists.fd.io/mt/32857966/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] [tsc] Project Proposal for uDPI

[Edward Warnicke]

Hongjun,

You guys are eligible for project creation review starting at the Aug 21
TSC meeting I believe (based on sending the notification to the TSC on Aug
8) ... when would you like to schedule for that Thu's TSC meeting, or a
subsequent one?

Ed

On Thu, Aug 8, 2019 at 8:11 PM Ni, Hongjun  wrote:

> Hello FD.io TSCs
>
>
>
> Please accept this project proposal for uDPI for consideration.
>
> https://wiki.fd.io/view/Project_Proposals/uDPI
>
>
>
> So far, this project has 11 founders and 15 initial committers from
>
> Intel, ZTE, China Telecom, HuachenTel, Inspur, Yxlink, Sunyainfo, Tencent,
> China Unicom, Huawei, QingCloud.
>
>
>
> If possible, I would like to present this on TSC meeting.
>
>
>
> Thanks,
>
> Hongjun
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#1070): https://lists.fd.io/g/tsc/message/1070
> Mute This Topic: https://lists.fd.io/mt/32805806/464962
> Group Owner: tsc+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/tsc/unsub  [hagb...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Help with two interfaces accessing outside network

[carlito nueno]

Hi all,

I am trying to setup two WAN interfaces where each of them can access
to the outside world at the same time.

So far I have:

set int state wan0 up
set int state wan1 up

set int ip address wan0 172.78.10.155/29
set dhcp client intfc wan1 hostname test-wans

ip route add 0.0.0.0/0 via 172.78.10.158 wan0

vpp# ping 8.8.8.8 source wan0
vpp# ping 8.8.8.8 source wan1

I am unable to ping via wan1

Any advice?

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

View/Reply Online (#13726): https://lists.fd.io/g/vpp-dev/message/13726
Mute This Topic: https://lists.fd.io/mt/32857184/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] lockless architecture

[Satya Murthy]

Hi Dave,

I totally agree with you that my email was an over-simplification of a bigger 
issue for sure.

What we are trying to see is:
can a single thread handle both control plane and data plane activities for a 
particular application object ( ex: a flow object) , so that, a need of lock 
can be avoided.
( Making sure that control plane messages and data plane packets landing on the 
same thread is a different issue.)

--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13725): https://lists.fd.io/g/vpp-dev/message/13725
Mute This Topic: https://lists.fd.io/mt/32853245/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] lockless architecture

[Dave Barach via Lists.Fd.Io]

What you’ve written is a best an oversimplification. It’s not correct to say 
that vpp lacks lockless data structures, and that all table-programming 
activities require coarse-grained locking and/or barrier synchronization.

Rather than starting a discussion from first principles, would it be possible 
to describe what you’re trying to do in detail?

Thanks... Dave

From: vpp-dev@lists.fd.io  On Behalf Of Satya Murthy
Sent: Tuesday, August 13, 2019 10:51 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] lockless architecture

Hi ,

Need some inputs on the lock less architecture with multi-threaded VPP system.

From the experiences we had so far, taking a lock ( whatsoever small time the 
lock is taken for ) degrades
the performance. Hence, trying to see if we have any feasibility of lockless 
architecture in VPP.
We have gone through this in deep but seeing few issues on implementing this.

1) The vnet library and other core plugins like acls/classifiers does not seem 
to be thread-safe. The data structures in these does not seem be be thread 
specific, and hence applications from different threads may not able to modify 
them without acquiring a lock. This poses an issue.

2) I think, this is the reason, the control plane operations via vpp-api are 
handled by single main thread. However, this model will have an issue of main 
thread needing to take a write-lock when it is trying to modify any data via 
control plane. Worker threads during this time have to wait for this lock 
causing performance degradation.

So, if both controlplane and data plane operations are performed by same thread 
(let's say by a specific worker), then we have an issue of underlying vnet 
layer not being thread-safe.

If go with the approach of main thread and worker thread handling control and 
data plane activities respectively, then we need to take lock which may degrade 
performance.

Any viable approach that can avoid both of these issues ?

--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] lockless architecture

[Satya Murthy]

Hi ,

Need some inputs on the lock less architecture with multi-threaded VPP system.

>From the experiences we had so far, taking a lock ( whatsoever small time the 
>lock is taken for ) degrades
the performance. Hence, trying to see if we have any feasibility of lockless 
architecture in VPP.
We have gone through this in deep but seeing few issues on implementing this.

1) The vnet library and other core plugins like acls/classifiers does not seem 
to be thread-safe. The data structures in these does not seem be be thread 
specific, and hence applications from different threads may not able to modify 
them without acquiring a lock. This poses an issue.

2) I think, this is the reason, the control plane operations via vpp-api are 
handled by single main thread. However, this model will have an issue of main 
thread needing to take a write-lock when it is trying to modify any data via 
control plane. Worker threads during this time have to wait for this lock 
causing performance degradation.

So, if both controlplane and data plane operations are performed by same thread 
(let's say by a specific worker), then we have an issue of underlying vnet 
layer not being thread-safe.

If go with the approach of main thread and worker thread handling control and 
data plane activities respectively, then we need to take lock which may degrade 
performance.

Any viable approach that can avoid both of these issues ?

--
Thanks & Regards,
Murthy
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13723): https://lists.fd.io/g/vpp-dev/message/13723
Mute This Topic: https://lists.fd.io/mt/32853245/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] A method to measure the allocated memory size for IKE SA

[Damjan Marion via Lists.Fd.Io]

OK, that is not exactly what you asked in your first email.
If you want to find out size of struct and all child/indirect data, you will 
need to sum all of them manually.

Most of them are vectors, so you cal use vl() helper in gdb to get length. I.e.

(gdb) p sizeof (ikev2_rekey_t) * vl(my_ikev2_struct.rekey)



> On 13 Aug 2019, at 13:30, Jaemin Park  wrote:
> 
> The invocation of sizeof() does not cover the whole allocated memory for IKE 
> SA.
> That structure has the pointers of other nested structures, the pointers of 
> keys and so on.
> 
> 2019년 8월 13일 (화) 오후 7:38, Damjan Marion  >님이 작성:
> 
> 
> > On 13 Aug 2019, at 05:01, jmpar...@gmail.com  
> > wrote:
> > 
> > Hi, all
> > 
> > I'd like to measure the allocated memory size for the whole structure of 
> > IKE SA (ikev2_sa_t).
> > Because ikev2_sa_t has many other struct types, it is not simple for me to 
> > measure the memory size.
> > 
> > Is there any method like API or other function calls to measure the memory 
> > size for IKE SA?
> 
> 
> maybe print sizeof (ikev2_sa_t) ?
> 
> -- 
> Gmail 모바일에서 보낸 메일
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#13721): https://lists.fd.io/g/vpp-dev/message/13721
> Mute This Topic: https://lists.fd.io/mt/32848977/675642
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#13722): https://lists.fd.io/g/vpp-dev/message/13722
Mute This Topic: https://lists.fd.io/mt/32848977/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] A method to measure the allocated memory size for IKE SA

[Jaemin Park]

The invocation of sizeof() does not cover the whole allocated memory for
IKE SA.
That structure has the pointers of other nested structures, the pointers of
keys and so on.

2019년 8월 13일 (화) 오후 7:38, Damjan Marion 님이 작성:

>
>
> > On 13 Aug 2019, at 05:01, jmpar...@gmail.com wrote:
> >
> > Hi, all
> >
> > I'd like to measure the allocated memory size for the whole structure of
> IKE SA (ikev2_sa_t).
> > Because ikev2_sa_t has many other struct types, it is not simple for me
> to measure the memory size.
> >
> > Is there any method like API or other function calls to measure the
> memory size for IKE SA?
>
>
> maybe print sizeof (ikev2_sa_t) ?
>
> --
Gmail 모바일에서 보낸 메일
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13721): https://lists.fd.io/g/vpp-dev/message/13721
Mute This Topic: https://lists.fd.io/mt/32848977/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] A method to measure the allocated memory size for IKE SA

[Damjan Marion via Lists.Fd.Io]

> On 13 Aug 2019, at 05:01, jmpar...@gmail.com wrote:
> 
> Hi, all
> 
> I'd like to measure the allocated memory size for the whole structure of IKE 
> SA (ikev2_sa_t).
> Because ikev2_sa_t has many other struct types, it is not simple for me to 
> measure the memory size.
> 
> Is there any method like API or other function calls to measure the memory 
> size for IKE SA?


maybe print sizeof (ikev2_sa_t) ?

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

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

Re: [tsc] [vpp-dev] Project Proposal for uDPI

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via Lists.Fd.Io]

>> uDPI

> microDPI


Universal Deep Packet Inspection is the new project here.

Would it make sense to use UDPI as its abbreviation

(e.g. capital U, to distinguish from "micro")?


Vratko.



From: t...@lists.fd.io  on behalf of Ni, Hongjun 

Sent: Tuesday, August 13, 2019 03:47
To: Ni, Hongjun; Alexey; t...@lists.fd.io
Cc: vpp-dev@lists.fd.io; Wang, Xiang W; Hong, Yang A; Chang, Harry; 
gu.ji...@zte.com.cn; Shan Jianghua; Zhang Yang; Li Xingfu; Wu Shuai; Xia 
Yuying; Fan Chenggang; Gao Feng; Liu Zhong; Zhao Yong; Chen Haiquan
Subject: Re: [tsc] [vpp-dev] Project Proposal for uDPI

Hi Alexey and all,

Alexey and I had a discussion offline.
It seems that we mentioned two different projects except the same project name.

The project Alexey mentioned is "microDPI packet inspection for network 
analytics".
It is developed based on Machine Learning and Python language, using GPL3.0 
License.
Last activity for this project is 10.04.2017, which is 2 years ago. That is why 
Alexey said it is died.
It supports six specific protocols/applications.

The project we proposed here is "Universal Deep Packet Inspection".
It is developed based on industry regex matching library, VPP, and C language, 
using Apache 2.0 License.
We plan to support most industry network protocols/applications.

Both have different scopes, features, implementations and Licenses.

Thanks,
Hongjun

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Ni, Hongjun
Sent: Friday, August 9, 2019 10:03 PM
To: Alexey ; t...@lists.fd.io
Cc: vpp-dev@lists.fd.io; Wang, Xiang W ; Hong, Yang A 
; Chang, Harry ; 
gu.ji...@zte.com.cn; Shan Jianghua ; Zhang Yang 
; Li Xingfu ; Wu Shuai 
; Xia Yuying ; Fan Chenggang 
; Gao Feng ; Liu Zhong 
; Zhao Yong ; Chen Haiquan 

Subject: Re: [vpp-dev] Project Proposal for uDPI

Hi Alexey,

Could you give some thoughts on this?

Thanks,
Hongjun

From: vpp-dev@lists.fd.io 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Alexey
Sent: Friday, August 9, 2019 6:54 PM
To: Ni, Hongjun mailto:hongjun...@intel.com>>; 
t...@lists.fd.io
Cc: vpp-dev@lists.fd.io; Wang, Xiang W 
mailto:xiang.w.w...@intel.com>>; Hong, Yang A 
mailto:yang.a.h...@intel.com>>; Chang, Harry 
mailto:harry.ch...@intel.com>>; 
gu.ji...@zte.com.cn; Shan Jianghua 
mailto:shanjia...@chinatelecom.cn>>; Zhang Yang 
mailto:zhangy@chinatelecom.cn>>; Li Xingfu 
mailto:lixin...@huachentel.com>>; Wu Shuai 
mailto:wush...@inspur.com>>; Xia Yuying 
mailto:yuying...@yxlink.com>>; Fan Chenggang 
mailto:fanchengg...@sunyainfo.com>>; Gao Feng 
mailto:davidf...@tencent.com>>; Liu Zhong 
mailto:liuzho...@chinaunicom.cn>>; Zhao Yong 
mailto:zhaoyon...@huawei.com>>; Chen Haiquan 
mailto:o...@yunify.com>>
Subject: Re: [vpp-dev] Project Proposal for uDPI

udpi is died


09.08.2019, 04:11, "Ni, Hongjun" 
mailto:hongjun...@intel.com>>:

Hello FD.io TSCs



Please accept this project proposal for uDPI for consideration.

https://wiki.fd.io/view/Project_Proposals/uDPI



So far, this project has 11 founders and 15 initial committers from

Intel, ZTE, China Telecom, HuachenTel, Inspur, Yxlink, Sunyainfo, Tencent, 
China Unicom, Huawei, QingCloud.



If possible, I would like to present this on TSC meeting.



Thanks,

Hongjun
,

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

View/Reply Online (#13684): https://lists.fd.io/g/vpp-dev/message/13684
Mute This Topic: https://lists.fd.io/mt/32805807/675634
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
[devel-net-ne-vleza...@yandex.ru]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] reminder: 19.08 RC2 is tomorrow Wednesday 14 August

[Andrew Yourtchenko]

Hi all,

Just a kind reminder that 19.08 RC2 milestone is tomorrow.

After that milestone, only critical bug fixes will be merged into
stable/1908 in preparation for the release.

--a

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

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