Re: [vpp-dev] running VPP non-root broken

2018-10-23 Thread Lee Roberts 
Damjan,

In my case, we have a four-socket Skylake server filled with 2x25GbE NICs and
encryption accelerators---trying to see how much IPsec throughput we can manage.

Recently saw a ~50% performance increase by changing from 2MB hugepages (8192 
pages)
to 1GB hugepages (16 pages) with VPP 18.04 on Ubuntu 16.04 (4.4.0 kernel).


-Lee


From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Damjan 
Marion via Lists.Fd.Io
Sent: Tuesday, October 23, 2018 4:05 PM
To: Roberts, Lee A. 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] running VPP non-root broken


I submitted patch

Just for my curiosity what is the use case for allocating >=2 GB of wired 
memory?
I thought nobody wants to do that so i did not pay attention.
—
Damjan

On 23 Oct 2018, at 21:00, Lee Roberts 
mailto:lee.robe...@hpe.com>> wrote:
In the following code, take a close look at line #61:




Back in VPP 18.01.1, we had a similar problem---see VPP-1168 
(https://jira.fd.io/browse/VPP-1168).
One needs to be sure the left shift doesn’t lose high-order bits.  You may need 
to explicitly
cast “i” to be unsigned-64 before left-shifting it:

  uword pa = clib_pmalloc_get_pa (pm, (u8 *) va + ((u64)i << 
a->log2_page_sz));



-Lee Roberts



From: vpp-dev@lists.fd.io 
[mailto:vpp-dev@lists.fd.io] On Behalf Of Sirshak Das
Sent: Tuesday, October 23, 2018 12:45 PM
To: dmar...@me.com; vpp-dev 
mailto:vpp-dev@lists.fd.io>>
Cc: Honnappa Nagarahalli 
mailto:honnappa.nagaraha...@arm.com>>; Lijian 
Zhang (Arm Technology China) 
mailto:lijian.zh...@arm.com>>; khemendra kumar 
mailto:khemendra.kuma...@gmail.com>>; Juraj Linkeš 
mailto:juraj.lin...@pantheon.tech>>
Subject: Re: [vpp-dev] running VPP non-root broken

Hi Damjan,

I am getting the following error as well I don’t know if its related to this 
issue:
vlib_plugin_early_init:361: plugin path 
/home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
load_one_plugin:117: Plugin disabled (default): abf_plugin.so
load_one_plugin:117: Plugin disabled (default): acl_plugin.so
load_one_plugin:117: Plugin disabled (default): avf_plugin.so
load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit 
(DPDK))
load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
load_one_plugin:117: Plugin disabled (default): ila_plugin.so
load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
load_one_plugin:117: Plugin disabled (default): lb_plugin.so
load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
load_one_plugin:117: Plugin disabled (default): map_plugin.so
load_one_plugin:117: Plugin disabled (default): memif_plugin.so
load_one_plugin:117: Plugin disabled (default): nat_plugin.so
load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
load_one_plugin:117: Plugin disabled (default): stn_plugin.so
load_one_plugin:117: Plugin disabled (default): svs_plugin.so
load_one_plugin:117: Plugin disabled (default): tlsmbedtls_plugin.so
load_one_plugin:117: Plugin disabled (default): tlsopenssl_plugin.so
load_one_plugin:117: Plugin disabled (default): unittest_plugin.so
load_one_plugin:117: Plugin disabled (default): vmxnet3_plugin.so
clib_elf_parse_file: open `linux-vdso.so.1': No such file or directory
load_one_vat_plugin:67: Loaded plugin: lb_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: gtpu_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: memif_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nsh_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nsim_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: avf_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: vmxnet3_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: pppoe_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: mactime_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: lacp_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: dpdk_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: cdp_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: flowprobe_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nat_test_plugin.so
load_one_vat_plugin:67: Loaded plugin:

Re: [vpp-dev] running VPP non-root broken

2018-10-23 Thread Sirshak Das 
2M works but 1G still fails.

I toned down the dpdk resource allocation to default:
dpdk
{
  dev 0004:01:00.1
  dev 0004:01:00.2
  no-multi-seg
  log-level debug
  dev default
  {
num-rx-queues 1
# num-tx-queues 4
num-rx-desc 2048
num-tx-desc 2048
  }
  # num-mbufs 128000
  # socket-mem 2048,2048
  no-tx-checksum-offload

But here is the problem (for 16G of Hugepage memory):
With:
2MB (nr_hugepages: 8192)
GRUB_CMDLINE_LINUX="default_hugepagesz=2M hugepagesz=1G hugepages=16 
hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 nohz_full=16-45 
rcu_nocbs=16-45"
vs 1GB (nr_hugepages: 16)
GRUB_CMDLINE_LINUX="default_hugepagesz=1G hugepagesz=1G hugepages=16 
hugepagesz=2M hugepages=8192 iommu.passthrough=1 isolcpus=16-45 nohz_full=16-45 
rcu_nocbs=16-45"

I am getting a performance improvement of 49% when I use 1G hugepages compared 
to 2MB.
I am not an expert on hugepages to pinpoint the exact reason but it will surely 
help if you can fix the 1G hugepage issue.

Thank you
Sirshak Das
From: Damjan Marion 
Sent: Tuesday, October 23, 2018 3:43 PM
To: Sirshak Das 
Cc: vpp-dev ; Honnappa Nagarahalli 
; Lijian Zhang (Arm Technology China) 
; khemendra kumar ; Juraj 
Linkeš 
Subject: Re: [vpp-dev] running VPP non-root broken


OMG, you are good in wasting memory. 1G pages, 2G per socket given to dpdk to 
hang empty :)
128K buffers

For a start can you switch default page size to 2M. newer x86 kernels ignore it 
but maybe it behaves
differently on aarch64...

In the meantime I will fix few coverity issues...

--
Damjan


On 23 Oct 2018, at 20:45, Sirshak Das 
mailto:sirshak@arm.com>> wrote:

Hi Damjan,

I am getting the following error as well I don’t know if its related to this 
issue:
vlib_plugin_early_init:361: plugin path 
/home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
load_one_plugin:117: Plugin disabled (default): abf_plugin.so
load_one_plugin:117: Plugin disabled (default): acl_plugin.so
load_one_plugin:117: Plugin disabled (default): avf_plugin.so
load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit 
(DPDK))
load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
load_one_plugin:117: Plugin disabled (default): ila_plugin.so
load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
load_one_plugin:117: Plugin disabled (default): lb_plugin.so
load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
load_one_plugin:117: Plugin disabled (default): map_plugin.so
load_one_plugin:117: Plugin disabled (default): memif_plugin.so
load_one_plugin:117: Plugin disabled (default): nat_plugin.so
load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
load_one_plugin:117: Plugin disabled (default): stn_plugin.so
load_one_plugin:117: Plugin disabled (default): svs_plugin.so
load_one_plugin:117: Plugin disabled (default): tlsmbedtls_plugin.so
load_one_plugin:117: Plugin disabled (default): tlsopenssl_plugin.so
load_one_plugin:117: Plugin disabled (default): unittest_plugin.so
load_one_plugin:117: Plugin disabled (default): vmxnet3_plugin.so
clib_elf_parse_file: open `linux-vdso.so.1': No such file or directory
load_one_vat_plugin:67: Loaded plugin: lb_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: gtpu_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: memif_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nsh_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nsim_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: avf_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: vmxnet3_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: pppoe_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: mactime_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: lacp_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: dpdk_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: cdp_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: flowprobe_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nat_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: stn_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: acl_test_plugin.so
load_one_vat_plugin:67: Loaded plugin:

Re: [vpp-dev] running VPP non-root broken

2018-10-23 Thread Sirshak Das 
No, long back I had uncommented a few lines from the old config and never 
bothered to change (I have the whole server for myself so had the liberty to be 
lavish).
Let me retest with the patch.

Thank you
Sirshak Das
From: Damjan Marion 
Sent: Tuesday, October 23, 2018 3:43 PM
To: Sirshak Das 
Cc: vpp-dev ; Honnappa Nagarahalli 
; Lijian Zhang (Arm Technology China) 
; khemendra kumar ; Juraj 
Linkeš 
Subject: Re: [vpp-dev] running VPP non-root broken


OMG, you are good in wasting memory. 1G pages, 2G per socket given to dpdk to 
hang empty :)
128K buffers

For a start can you switch default page size to 2M. newer x86 kernels ignore it 
but maybe it behaves
differently on aarch64...

In the meantime I will fix few coverity issues...

--
Damjan


On 23 Oct 2018, at 20:45, Sirshak Das 
mailto:sirshak@arm.com>> wrote:

Hi Damjan,

I am getting the following error as well I don’t know if its related to this 
issue:
vlib_plugin_early_init:361: plugin path 
/home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
load_one_plugin:117: Plugin disabled (default): abf_plugin.so
load_one_plugin:117: Plugin disabled (default): acl_plugin.so
load_one_plugin:117: Plugin disabled (default): avf_plugin.so
load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit 
(DPDK))
load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
load_one_plugin:117: Plugin disabled (default): ila_plugin.so
load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
load_one_plugin:117: Plugin disabled (default): lb_plugin.so
load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
load_one_plugin:117: Plugin disabled (default): map_plugin.so
load_one_plugin:117: Plugin disabled (default): memif_plugin.so
load_one_plugin:117: Plugin disabled (default): nat_plugin.so
load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
load_one_plugin:117: Plugin disabled (default): stn_plugin.so
load_one_plugin:117: Plugin disabled (default): svs_plugin.so
load_one_plugin:117: Plugin disabled (default): tlsmbedtls_plugin.so
load_one_plugin:117: Plugin disabled (default): tlsopenssl_plugin.so
load_one_plugin:117: Plugin disabled (default): unittest_plugin.so
load_one_plugin:117: Plugin disabled (default): vmxnet3_plugin.so
clib_elf_parse_file: open `linux-vdso.so.1': No such file or directory
load_one_vat_plugin:67: Loaded plugin: lb_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: gtpu_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: memif_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nsh_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nsim_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: avf_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: vmxnet3_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: pppoe_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: mactime_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: lacp_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: dpdk_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: cdp_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: flowprobe_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nat_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: stn_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: acl_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: ioam_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: map_test_plugin.so
vnet_feature_arc_init:206: feature node 'acl-plugin-out-ip6-fa' not found 
(before 'ip6-dvr-reinject', arc 'ip6-output')
vnet_feature_arc_init:206: feature node 'nat44-in2out-output' not found (before 
'ip4-dvr-reinject', arc 'ip4-output')
vnet_feature_arc_init:206: feature node 'acl-plugin-out-ip4-fa' not found 
(before 'ip4-dvr-reinject', arc 'ip4-output')
vlib_physmem_shared_map_create: pmalloc_map_pages: failed to mmap 153 pages at 
0xfffaa3c0 fd 23 numa 0 flags 0x42031: Invalid argument

dpdk_buffer_pool_create: failed to allocate mempool on socket 0


This is the startup.conf I am using:

ip
{
  heap-size 4G
}
unix
{
  nodaemon
  interactive
  cli-listen localhost:5002
  log /home/sirdas/var/log/vpp/vpp.log
}
ip6
{

Re: [vpp-dev] about gtpu encap

2018-10-23 Thread Yao, Chengqiang 
Hi Daolin,

You can see the code below in gtpu4_encap node, if you set gtpu4_encap as next 
node, the sw_if_index should be set correctly. In you case, it should be set to 
the gtpu tunnel1.

sw_if_index0 = vnet_buffer(b0)->sw_if_index[VLIB_TX];

A workable solution is add a node as the next node of gtpu_decap, set correct 
sw_if_index to sw_if_index[VLIB_TX] of the packet, then pass the packet to 
gtpu4_encap node.


Best Regards,
Chengqiang Yao



From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of John Lo 
(loj) via Lists.Fd.Io
Sent: Tuesday, October 23, 2018 10:23 PM
To: Liu Daolin (刘道林) ; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] about gtpu encap

I believe you can cross connect two gtpu tunnel interfaces on the VPP in your 
GW to achieve what you need:
DBGvpp# set int l2 xconnect ?
  set interface l2 xconnectset interface l2 xconnect 
 

You need to set L2 xconnect on both gtpu tunnel interfaces to each other.

Regards,
John

From: vpp-dev@lists.fd.io 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Liu Daolin (???)
Sent: Tuesday, October 23, 2018 3:51 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] about gtpu encap

Hi,

I have a question about gtpu encap node in VPP. My network topology is:

[cid:image002.jpg@01D46AC2.C0DA7910]

VPP is running on GW in Linux VM with two IP interfaces, and eNB & CN in the 
above graph are running on two different Linux VMs with only one IP interface. 
After starting VPP and some regular settings with CLI, I can ping CN from eNB 
side successfully, vice versa without any problem.

Currently, my requirement is that setting gtpu tunnels between both eNB<->GW 
and GW<->CN, and then from the eNB side, it will send UDP packet to GW with 
gtpu (port 2152, src IP 192.168.2.2, dst IP 192.168.2.1), and VPP can decap 
this gtpu packet (teid 261) to get T-PDU data, and then re-encap gtpu (teid 
262) and udp to send to CN (port 2152, src IP 192.168.3.1, dst IP 192.168.3.2). 
Something like this:

[cid:image002.jpg@01D46B78.923DACB0]

You can see below original packet from eNB side.

[cid:image003.jpg@01D46B78.923DACB0]

Actually, I don't need VPP to decode the payload in red color, i.e. T-PDU Data 
4500…… I just want to keep this T-PDU Data and then fill the new teid and src & 
dst IP to send to CN side. The output packet should like this:

[cid:image004.jpg@01D46B78.923DACB0]

I run below command to set tunnels:

vppctl create gtpu tunnel src 192.168.2.1 dst 192.168.2.2 teid 261
vppctl create gtpu tunnel src 192.168.3.2 dst 192.168.3.1 teid 262

and capture the original packet with "show trace" successfully. But the VPP 
treated the payload 4500…… as l2-input since I didn't set "decap-next node" in 
above command.

But if I use below command:

vppctl create gtpu tunnel src 192.168.2.1 dst 192.168.2.2 teid 261 decap-next 
node gtpu4-encap
vppctl create gtpu tunnel src 192.168.3.2 dst 192.168.3.1 teid 262 decap-next 
node gtpu4-encap

The VPP process will be crashed. Maybe I miss something or my command is not 
correct enough. Actually I found that there is no previous node for 
gtpu4-encap. I don't know why.

Could you please show me what should I do to satisfy my requirement which is 
not complex in my mind?

Thanks a lot!
Best regards
刘道林 (Daolin Liu)
T大连市共进科技有限公司
DALIAN GONGJIN TECHNOLOGY CO.,LTD
中国大连市高新园区软件园路1A-4-24层
Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
直线(TEL)：(86-411)39996705   分机(EXT)：76824
手机(Mobile)：(86)13704090959

本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部的泄漏、阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你所接收到的文本。
 This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10932): https://lists.fd.io/g/vpp-dev/message/10932
Mute This Topic: https://lists.fd.io/mt/27566720/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] running VPP non-root broken

2018-10-23 Thread Damjan Marion via Lists.Fd.Io 

I submitted patch

Just for my curiosity what is the use case for allocating >=2 GB of wired 
memory?
I thought nobody wants to do that so i did not pay attention.

— 
Damjan

> On 23 Oct 2018, at 21:00, Lee Roberts  wrote:
> 
> In the following code, take a close look at line #61:
>  
> 
>  
>  
> Back in VPP 18.01.1, we had a similar problem---see VPP-1168 
> (https://jira.fd.io/browse/VPP-1168).
> One needs to be sure the left shift doesn’t lose high-order bits.  You may 
> need to explicitly
> cast “i” to be unsigned-64 before left-shifting it:
>  
>   uword pa = clib_pmalloc_get_pa (pm, (u8 *) va + ((u64)i << 
> a->log2_page_sz));
>  
>  
> -Lee Roberts
>  
>  
>  
> From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Sirshak 
> Das
> Sent: Tuesday, October 23, 2018 12:45 PM
> To: dmar...@me.com; vpp-dev 
> Cc: Honnappa Nagarahalli ; Lijian Zhang (Arm 
> Technology China) ; khemendra kumar 
> ; Juraj Linkeš 
> Subject: Re: [vpp-dev] running VPP non-root broken
>  
> Hi Damjan,
>  
> I am getting the following error as well I don’t know if its related to this 
> issue:
> vlib_plugin_early_init:361: plugin path 
> /home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
> load_one_plugin:117: Plugin disabled (default): abf_plugin.so
> load_one_plugin:117: Plugin disabled (default): acl_plugin.so
> load_one_plugin:117: Plugin disabled (default): avf_plugin.so
> load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
> load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development 
> Kit (DPDK))
> load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
> load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
> load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
> load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
> load_one_plugin:117: Plugin disabled (default): ila_plugin.so
> load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
> load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
> load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
> load_one_plugin:117: Plugin disabled (default): lb_plugin.so
> load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
> load_one_plugin:117: Plugin disabled (default): map_plugin.so
> load_one_plugin:117: Plugin disabled (default): memif_plugin.so
> load_one_plugin:117: Plugin disabled (default): nat_plugin.so
> load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
> load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
> load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
> load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
> load_one_plugin:117: Plugin disabled (default): stn_plugin.so
> load_one_plugin:117: Plugin disabled (default): svs_plugin.so
> load_one_plugin:117: Plugin disabled (default): tlsmbedtls_plugin.so
> load_one_plugin:117: Plugin disabled (default): tlsopenssl_plugin.so
> load_one_plugin:117: Plugin disabled (default): unittest_plugin.so
> load_one_plugin:117: Plugin disabled (default): vmxnet3_plugin.so
> clib_elf_parse_file: open `linux-vdso.so.1': No such file or directory
> load_one_vat_plugin:67: Loaded plugin: lb_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: gtpu_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: memif_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: nsh_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: nsim_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: avf_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: vmxnet3_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: pppoe_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: mactime_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: lacp_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: dpdk_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: cdp_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: flowprobe_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: nat_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: stn_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: acl_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: ioam_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: map_test_plugin.so
> vnet_feature_arc_init:206: feature node 'acl-plugin-out-ip6-fa' not found 
> (before 'ip6-dvr-reinject', arc 'ip6-output')
> vnet_feature_arc_init:206: feature node 'nat44-in2out-output' not found 
> (before 'ip4-dvr-reinject', arc 'ip4-output')
> vnet_feature_arc_init:206: feature node 'acl-plugin-out-ip4-fa' not found 
> (before 'ip4-dvr-reinject', arc 'ip4-output')
> vlib_physmem_shared_map_create: pmalloc_map_pages: failed to mmap 153

Re: [vpp-dev] running VPP non-root broken

2018-10-23 Thread Damjan Marion via Lists.Fd.Io 

OMG, you are good in wasting memory. 1G pages, 2G per socket given to dpdk to 
hang empty :)
128K buffers

For a start can you switch default page size to 2M. newer x86 kernels ignore it 
but maybe it behaves
differently on aarch64...

In the meantime I will fix few coverity issues...

-- 
Damjan

> On 23 Oct 2018, at 20:45, Sirshak Das  wrote:
> 
> Hi Damjan,
>  
> I am getting the following error as well I don’t know if its related to this 
> issue:
> vlib_plugin_early_init:361: plugin path 
> /home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
> load_one_plugin:117: Plugin disabled (default): abf_plugin.so
> load_one_plugin:117: Plugin disabled (default): acl_plugin.so
> load_one_plugin:117: Plugin disabled (default): avf_plugin.so
> load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
> load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development 
> Kit (DPDK))
> load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
> load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
> load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
> load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
> load_one_plugin:117: Plugin disabled (default): ila_plugin.so
> load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
> load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
> load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
> load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
> load_one_plugin:117: Plugin disabled (default): lb_plugin.so
> load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
> load_one_plugin:117: Plugin disabled (default): map_plugin.so
> load_one_plugin:117: Plugin disabled (default): memif_plugin.so
> load_one_plugin:117: Plugin disabled (default): nat_plugin.so
> load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
> load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
> load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
> load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
> load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
> load_one_plugin:117: Plugin disabled (default): stn_plugin.so
> load_one_plugin:117: Plugin disabled (default): svs_plugin.so
> load_one_plugin:117: Plugin disabled (default): tlsmbedtls_plugin.so
> load_one_plugin:117: Plugin disabled (default): tlsopenssl_plugin.so
> load_one_plugin:117: Plugin disabled (default): unittest_plugin.so
> load_one_plugin:117: Plugin disabled (default): vmxnet3_plugin.so
> clib_elf_parse_file: open `linux-vdso.so.1': No such file or directory
> load_one_vat_plugin:67: Loaded plugin: lb_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: gtpu_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: memif_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: nsh_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: nsim_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: avf_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: vmxnet3_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: pppoe_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: mactime_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: lacp_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: dpdk_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: cdp_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: flowprobe_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: nat_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: stn_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: acl_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: ioam_test_plugin.so
> load_one_vat_plugin:67: Loaded plugin: map_test_plugin.so
> vnet_feature_arc_init:206: feature node 'acl-plugin-out-ip6-fa' not found 
> (before 'ip6-dvr-reinject', arc 'ip6-output')
> vnet_feature_arc_init:206: feature node 'nat44-in2out-output' not found 
> (before 'ip4-dvr-reinject', arc 'ip4-output')
> vnet_feature_arc_init:206: feature node 'acl-plugin-out-ip4-fa' not found 
> (before 'ip4-dvr-reinject', arc 'ip4-output')
> vlib_physmem_shared_map_create: pmalloc_map_pages: failed to mmap 153 pages 
> at 0xfffaa3c0 fd 23 numa 0 flags 0x42031: Invalid argument
>  
> dpdk_buffer_pool_create: failed to allocate mempool on socket 0
>  
>  
> This is the startup.conf I am using: 
>  
> ip
> {
>   heap-size 4G
> }
> unix
> {
>   nodaemon
>   interactive
>   cli-listen localhost:5002
>   log /home/sirdas/var/log/vpp/vpp.log
> }
> ip6
> {
>   heap-size 4G
>   hash-buckets 200
> }
> heapsize 4G
> plugins
> {
>   plugin default
>   {
> disable
>   }
>   plugin dpdk_plugin.so
>   {
> enable
>   }
> }
> cpu
> {
>   corelist-workers 18,20
>   main-core 17
> }
> dpdk
> {
>   dev 0004:01:00.1
>   dev 0004:01:00.2
>   no-multi-seg
>

Re: [vpp-dev] running VPP non-root broken

2018-10-23 Thread Sirshak Das 
Hi Damjan,

I am getting the following error as well I don't know if its related to this 
issue:
vlib_plugin_early_init:361: plugin path 
/home/sirdas/code/commita/vpp/build-root/install-vpp-native/vpp/lib/vpp_plugins
load_one_plugin:117: Plugin disabled (default): abf_plugin.so
load_one_plugin:117: Plugin disabled (default): acl_plugin.so
load_one_plugin:117: Plugin disabled (default): avf_plugin.so
load_one_plugin:117: Plugin disabled (default): cdp_plugin.so
load_one_plugin:189: Loaded plugin: dpdk_plugin.so (Data Plane Development Kit 
(DPDK))
load_one_plugin:117: Plugin disabled (default): flowprobe_plugin.so
load_one_plugin:117: Plugin disabled (default): gbp_plugin.so
load_one_plugin:117: Plugin disabled (default): gtpu_plugin.so
load_one_plugin:117: Plugin disabled (default): igmp_plugin.so
load_one_plugin:117: Plugin disabled (default): ila_plugin.so
load_one_plugin:117: Plugin disabled (default): ioam_plugin.so
load_one_plugin:117: Plugin disabled (default): ixge_plugin.so
load_one_plugin:117: Plugin disabled (default): l2e_plugin.so
load_one_plugin:117: Plugin disabled (default): lacp_plugin.so
load_one_plugin:117: Plugin disabled (default): lb_plugin.so
load_one_plugin:117: Plugin disabled (default): mactime_plugin.so
load_one_plugin:117: Plugin disabled (default): map_plugin.so
load_one_plugin:117: Plugin disabled (default): memif_plugin.so
load_one_plugin:117: Plugin disabled (default): nat_plugin.so
load_one_plugin:117: Plugin disabled (default): nsh_plugin.so
load_one_plugin:117: Plugin disabled (default): nsim_plugin.so
load_one_plugin:117: Plugin disabled (default): perfmon_plugin.so
load_one_plugin:117: Plugin disabled (default): pppoe_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6ad_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6am_plugin.so
load_one_plugin:117: Plugin disabled (default): srv6as_plugin.so
load_one_plugin:117: Plugin disabled (default): stn_plugin.so
load_one_plugin:117: Plugin disabled (default): svs_plugin.so
load_one_plugin:117: Plugin disabled (default): tlsmbedtls_plugin.so
load_one_plugin:117: Plugin disabled (default): tlsopenssl_plugin.so
load_one_plugin:117: Plugin disabled (default): unittest_plugin.so
load_one_plugin:117: Plugin disabled (default): vmxnet3_plugin.so
clib_elf_parse_file: open `linux-vdso.so.1': No such file or directory
load_one_vat_plugin:67: Loaded plugin: lb_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: gtpu_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: memif_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nsh_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nsim_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: avf_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: vmxnet3_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: pppoe_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: mactime_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: lacp_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: dpdk_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: cdp_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: flowprobe_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: nat_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: stn_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: acl_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: ioam_test_plugin.so
load_one_vat_plugin:67: Loaded plugin: map_test_plugin.so
vnet_feature_arc_init:206: feature node 'acl-plugin-out-ip6-fa' not found 
(before 'ip6-dvr-reinject', arc 'ip6-output')
vnet_feature_arc_init:206: feature node 'nat44-in2out-output' not found (before 
'ip4-dvr-reinject', arc 'ip4-output')
vnet_feature_arc_init:206: feature node 'acl-plugin-out-ip4-fa' not found 
(before 'ip4-dvr-reinject', arc 'ip4-output')
vlib_physmem_shared_map_create: pmalloc_map_pages: failed to mmap 153 pages at 
0xfffaa3c0 fd 23 numa 0 flags 0x42031: Invalid argument

dpdk_buffer_pool_create: failed to allocate mempool on socket 0


This is the startup.conf I am using:

ip
{
  heap-size 4G
}
unix
{
  nodaemon
  interactive
  cli-listen localhost:5002
  log /home/sirdas/var/log/vpp/vpp.log
}
ip6
{
  heap-size 4G
  hash-buckets 200
}
heapsize 4G
plugins
{
  plugin default
  {
disable
  }
  plugin dpdk_plugin.so
  {
enable
  }
}
cpu
{
  corelist-workers 18,20
  main-core 17
}
dpdk
{
  dev 0004:01:00.1
  dev 0004:01:00.2
  no-multi-seg
  log-level debug
  dev default
  {
num-rx-queues 2
num-rx-desc 2048
num-tx-desc 2048
  }
  num-mbufs 128000
  socket-mem 2048,2048
  no-tx-checksum-offload
}

More info for debugging:
Boot parameters:
default_hugepagesz=1G hugepagesz=1G hugepages=32 hugepagesz=2M hugepages=2048 
iommu.passthrough=1 isolcpus=16-45 nohz_full=16-45 rcu_nocbs=16-45

OS & Kernel:
Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-38-generic aarch64)

Meminfo:
$ cat /proc/meminfo
MemTotal:   98827048 kB
MemFree: 2802448 kB
MemAvailable:2730464 kB
Buffers:   44960 kB
Cached:

[vpp-dev] running VPP non-root broken

2018-10-23 Thread Damjan Marion via Lists.Fd.Io 

Folks,

Looks like my big physmem patch breaks non-root operation of VPP,  working on it
and It will take a bit of time so as a workaround "make test" can be run with 
sudo.

Let me know if any issues, and I will revert, but would like to avoid that due 
to the size of patch.

-- 
Damjan

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

View/Reply Online (#10927): https://lists.fd.io/g/vpp-dev/message/10927
Mute This Topic: https://lists.fd.io/mt/27570325/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] about gtpu encap

2018-10-23 Thread John Lo (loj) via Lists.Fd.Io 
I believe you can cross connect two gtpu tunnel interfaces on the VPP in your 
GW to achieve what you need:
DBGvpp# set int l2 xconnect ?
  set interface l2 xconnectset interface l2 xconnect 
 

You need to set L2 xconnect on both gtpu tunnel interfaces to each other.

Regards,
John

From: vpp-dev@lists.fd.io  On Behalf Of Liu Daolin (???)
Sent: Tuesday, October 23, 2018 3:51 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] about gtpu encap

Hi,

I have a question about gtpu encap node in VPP. My network topology is:

[cid:image002.jpg@01D46AC2.C0DA7910]

VPP is running on GW in Linux VM with two IP interfaces, and eNB & CN in the 
above graph are running on two different Linux VMs with only one IP interface. 
After starting VPP and some regular settings with CLI, I can ping CN from eNB 
side successfully, vice versa without any problem.

Currently, my requirement is that setting gtpu tunnels between both eNB<->GW 
and GW<->CN, and then from the eNB side, it will send UDP packet to GW with 
gtpu (port 2152, src IP 192.168.2.2, dst IP 192.168.2.1), and VPP can decap 
this gtpu packet (teid 261) to get T-PDU data, and then re-encap gtpu (teid 
262) and udp to send to CN (port 2152, src IP 192.168.3.1, dst IP 192.168.3.2). 
Something like this:

[cid:image002.jpg@01D46ABA.69062A20]

You can see below original packet from eNB side.

[cid:image003.jpg@01D46ABA.69062A20]

Actually, I don't need VPP to decode the payload in red color, i.e. T-PDU Data 
4500…… I just want to keep this T-PDU Data and then fill the new teid and src & 
dst IP to send to CN side. The output packet should like this:

[cid:image004.jpg@01D46ABA.69062A20]

I run below command to set tunnels:

vppctl create gtpu tunnel src 192.168.2.1 dst 192.168.2.2 teid 261
vppctl create gtpu tunnel src 192.168.3.2 dst 192.168.3.1 teid 262

and capture the original packet with "show trace" successfully. But the VPP 
treated the payload 4500…… as l2-input since I didn't set "decap-next node" in 
above command.

But if I use below command:

vppctl create gtpu tunnel src 192.168.2.1 dst 192.168.2.2 teid 261 decap-next 
node gtpu4-encap
vppctl create gtpu tunnel src 192.168.3.2 dst 192.168.3.1 teid 262 decap-next 
node gtpu4-encap

The VPP process will be crashed. Maybe I miss something or my command is not 
correct enough. Actually I found that there is no previous node for 
gtpu4-encap. I don't know why.

Could you please show me what should I do to satisfy my requirement which is 
not complex in my mind?

Thanks a lot!
Best regards
刘道林 (Daolin Liu)
T大连市共进科技有限公司
DALIAN GONGJIN TECHNOLOGY CO.,LTD
中国大连市高新园区软件园路1A-4-24层
Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
直线(TEL)：(86-411)39996705   分机(EXT)：76824
手机(Mobile)：(86)13704090959

本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部的泄漏、阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你所接收到的文本。
 This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10926): https://lists.fd.io/g/vpp-dev/message/10926
Mute This Topic: https://lists.fd.io/mt/27566720/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] one question IP checksum

2018-10-23 Thread John Lo (loj) via Lists.Fd.Io 
I don't know if VXLAN-GPE is implemented in VPP to handle IP payload without 
ethernet header properly.  You can try it to check what happens.  I would not 
be surprised if something need to be fixed in VXLAN-GPE encap/decap for it to 
work properly.  Hopefully the owner of VXLAN-GPE can comment further.

If your requirement is to have IP in IP tunnel, GRE tunnel may be a better 
choice which is fully supported by VPP.  Then everything will be handled in L3 
only.

Regards,
John

From: Zhang, Yuwei1 
Sent: Monday, October 22, 2018 10:44 PM
To: John Lo (loj) ; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] one question IP checksum

Thanks a lot, I think I got a better understanding cause of your help. As you 
said, the outer udp checksum is optional and often left as 0, is there any 
issue if I use VXLAN-GPE and send packet to ip4-input-nochecksum node which 
will skip the inner ip checksum verification?

Regards,
Yuwei
From: vpp-dev@lists.fd.io 
[mailto:vpp-dev@lists.fd.io] On Behalf Of John Lo (loj) via Lists.Fd.Io
Sent: Monday, October 22, 2018 11:56 PM
To: Zhang, Yuwei1 mailto:yuwei1.zh...@intel.com>>; 
vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] one question IP checksum

Hi Yuwei,

I did not suggest one can create VXLAN tunnel and send the dcap packet directly 
to ip4-input or ip4-input-nochecksum.  It will not work because the VXLAN 
payload still have a MAC header before the IP header after decap.  That's why 
it only works if it is sent to ethernet-input.  You are getting checksum error, 
because ip4-input node is treating the MAC header as if it is an IP header.

I was suggesting you may be able to create VXLAN-GPE tunnel (with a different 
CLI to that of the VXLAN one) which is different to VXLAN tunnel.  With 
VXLAN-GPE, you can potentially send just IP packet without ethernet header, 
with the appropriate protocol field in the VXLAN-GPE header set accordingly.  
Then it is feasible to send the packet directly to ip4-input or 
ip4-input-nochecksum.  I am not sure how complete VXLAN-GPE handling is 
implemented in VPP so you may need to improve the code to handle it.

Note that big portion of performance gain you observed is because 
ethernet-input node is bypassed, in addition to saving from not calculating IP 
checksum.

As I described before, VXLAN is supposed to be used for L2 to carry ethernet 
packets.  If it is used for L3, it is not standard usage and will not 
interoperate properly with other devices. For L3, VXLAN-GPE should ideally be 
used as it is designed to handle encap/decap of various packet types, as GPE 
mean "generic protocol extension", including L2 and L3 protocols.

Regards,
John

From: Zhang, Yuwei1 mailto:yuwei1.zh...@intel.com>>
Sent: Monday, October 22, 2018 4:50 AM
To: John Lo (loj) mailto:l...@cisco.com>>; 
vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] one question IP checksum

Hi John, thanks for your instructions, I tried to use your method with below 
steps:

1)  Create tunnel: vppctl create vxlan tunnel src 10.0.0.1 dst 10.0.0.2 vni 
24 encap-vrf-id 0 decap-next node ip4-input-no-checksum;

2)  Send vxlan traffic without inner ip header;
I can see obvious performance gain. But if I set the decap-next node 
ipv4-input, the vpp will drop the packet after decapsulation cause of the wrong 
inner ip header checksum. But when I set the decap-next node Ethernet-input, 
the packet will not be dropped. I'm a little confuse about this.

BTW, could you give me some explanation about which scenario should use vxlan 
over l2 and which scenario should use vxlan over l3? Thanks for your kindly 
help again!

Regards,
Yuwei
From: vpp-dev@lists.fd.io 
[mailto:vpp-dev@lists.fd.io] On Behalf Of John Lo (loj) via Lists.Fd.Io
Sent: Saturday, October 20, 2018 11:06 PM
To: Zhang, Yuwei1 mailto:yuwei1.zh...@intel.com>>; 
vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] one question IP checksum

Hi Yuwei,

I see that you are using VXLAN to carry L3 packets which seems to still have 
ethernet header.  This is not standard usage of VXLAN so I am not aware of a 
way to achieve what you desired via some kind of configuration of VPP.  A more 
optimal (also not standard) way may be to just send IP payload in VXLLAN tunnel 
without Ethernet header.  Then on decap, you can send the packet directly to 
ip-input-nochecksum node instead of (ethernet-input node).  The proper way to 
do this would be to use VXLAN-GPE which include a protocol header to specify 
payload type.

BTW, your claim of UDP checksum on the outer packet would've already cover the 
inner payload including its IP header is not necessarily correct.  For IPv4, 
the UDP checksum is optional and often left as 0 so not calculated.  VPP VXLAN 
encap would leave UDP checksum as 0 to save clocks, if the

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

2018-10-23 Thread Edward Warnicke 
I look forward to it :)

Ed

On Tue, Oct 23, 2018 at 8:42 AM Ni, Hongjun  wrote:

> Hi Ed,
>
>
>
> OK. I or some project proposer will join the Nov 8 8am PT TSC meeting and
> present the proposal.
>
>
>
> Thanks a lot,
>
> Hongjun
>
>
>
> *From:* t...@lists.fd.io [mailto:t...@lists.fd.io] *On Behalf Of *Edward
> Warnicke
> *Sent:* Tuesday, October 23, 2018 9:15 PM
> *To:* Ni, Hongjun 
> *Cc:* t...@lists.fd.io; vpp-dev@lists.fd.io; Wang, Drenfong <
> drenfong.w...@intel.com>; ??? ;
> chen...@huachentel.com; lizhuo...@cmhi.chinamobile.com; ??? <
> lihf...@chinaunicom.cn>; zhijl@chinatelecom.cn; changlin...@nxp.com;
> Wang Tianyi ; davidfgao(?? ;
> lixin...@huachentel.com; jingqing@alibaba-inc.com
> *Subject:* Re: [tsc] Project Proposal for Sweetcomb
>
>
>
> Hongjun,
>
>
>
> Thank you for the proposal :)  Per the FD.io technical charter, all
> proposals must be out for public review for two weeks prior to approval by
> the TSC.  I believe this makes Nov 8 the earliest TSC meeting where we
> could approve at the TSC.  Would you like to schedule the project creation
> review for the Nov 8 8am PT TSC meeting?  Will you (or other proposers of
> the project) be able to make that time to present the proposal?
>
>
>
> Ed
>
>
>
> On Tue, Oct 23, 2018 at 7:01 AM Ni, Hongjun  wrote:
>
> Hello FD.io TSCs
>
>
>
> Please accept this project proposal for Sweetcomb for consideration.
>
> https://wiki.fd.io/view/Project_Proposals/Sweetcomb
>
>
>
> This project has nine founding companies:
>
> Intel, HuachenTel, China Mobile, China Unicom, China Telecom, NXP, Tieto,
> Tencent, Alibaba.
>
>
>
> 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 (#856): https://lists.fd.io/g/tsc/message/856
> Mute This Topic: https://lists.fd.io/mt/27567539/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 (#10924): https://lists.fd.io/g/vpp-dev/message/10924
Mute This Topic: https://lists.fd.io/mt/27568384/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 Sweetcomb

2018-10-23 Thread Ni, Hongjun 
Hi Ed,

OK. I or some project proposer will join the Nov 8 8am PT TSC meeting and 
present the proposal.

Thanks a lot,
Hongjun

From: t...@lists.fd.io [mailto:t...@lists.fd.io] On Behalf Of Edward Warnicke
Sent: Tuesday, October 23, 2018 9:15 PM
To: Ni, Hongjun 
Cc: t...@lists.fd.io; vpp-dev@lists.fd.io; Wang, Drenfong 
; ??? ; 
chen...@huachentel.com; lizhuo...@cmhi.chinamobile.com; ??? 
; zhijl@chinatelecom.cn; changlin...@nxp.com; Wang 
Tianyi ; davidfgao(?? ; 
lixin...@huachentel.com; jingqing@alibaba-inc.com
Subject: Re: [tsc] Project Proposal for Sweetcomb

Hongjun,

Thank you for the proposal :)  Per the FD.io technical charter, all proposals 
must be out for public review for two weeks prior to approval by the TSC.  I 
believe this makes Nov 8 the earliest TSC meeting where we could approve at the 
TSC.  Would you like to schedule the project creation review for the Nov 8 8am 
PT TSC meeting?  Will you (or other proposers of the project) be able to make 
that time to present the proposal?

Ed

On Tue, Oct 23, 2018 at 7:01 AM Ni, Hongjun 
mailto:hongjun...@intel.com>> wrote:
Hello FD.io TSCs

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

This project has nine founding companies:
Intel, HuachenTel, China Mobile, China Unicom, China Telecom, NXP, Tieto, 
Tencent, Alibaba.

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 (#856): https://lists.fd.io/g/tsc/message/856
Mute This Topic: https://lists.fd.io/mt/27567539/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 (#10923): https://lists.fd.io/g/vpp-dev/message/10923
Mute This Topic: https://lists.fd.io/mt/27568384/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 Sweetcomb

2018-10-23 Thread Edward Warnicke 
Hongjun,

Thank you for the proposal :)  Per the FD.io technical charter, all
proposals must be out for public review for two weeks prior to approval by
the TSC.  I believe this makes Nov 8 the earliest TSC meeting where we
could approve at the TSC.  Would you like to schedule the project creation
review for the Nov 8 8am PT TSC meeting?  Will you (or other proposers of
the project) be able to make that time to present the proposal?

Ed

On Tue, Oct 23, 2018 at 7:01 AM Ni, Hongjun  wrote:

> Hello FD.io TSCs
>
>
>
> Please accept this project proposal for Sweetcomb for consideration.
>
> https://wiki.fd.io/view/Project_Proposals/Sweetcomb
>
>
>
> This project has nine founding companies:
>
> Intel, HuachenTel, China Mobile, China Unicom, China Telecom, NXP, Tieto,
> Tencent, Alibaba.
>
>
>
> 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 (#856): https://lists.fd.io/g/tsc/message/856
> Mute This Topic: https://lists.fd.io/mt/27567539/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 (#10922): https://lists.fd.io/g/vpp-dev/message/10922
Mute This Topic: https://lists.fd.io/mt/27568384/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Project Proposal for Sweetcomb

2018-10-23 Thread Ni, Hongjun 
Hello FD.io TSCs

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

This project has nine founding companies:
Intel, HuachenTel, China Mobile, China Unicom, China Telecom, NXP, Tieto, 
Tencent, Alibaba.

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 (#10921): https://lists.fd.io/g/vpp-dev/message/10921
Mute This Topic: https://lists.fd.io/mt/27567540/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 crashing out of dead_client_scan()

2018-10-23 Thread Dave Barach via Lists.Fd.Io 
Read at face value, the vpp binary API memory segment (VA range 0x3000 and 
above) is out of memory. The failing allocation is a request for 60 bytes, 
which is not an unreasonable ask.

Before doing anything else, try increasing the size of the API segment and see 
if the problem recurs.

We do not support 18.01 at this point, but I’ll sketch the work necessary to 
track down a binary API segment memory leak in that code version.

It will take a certain amount of scaffolding work to track down binary API 
segment memory leaks. In src/vppinfra/mheap_bootstrap.h, set 
MHEAP_HAVE_SMALL_OBJECT_CACHE to 0 in all cases.

Patch the current “memory-trace” debug CLI command, and the current “show 
memory” command – see below. Boot vpp and enable memory tracing on the api 
segment.

Do whatever you normally do to cause the out-of-memory crash, but not for quite 
as long ()...

Then, “show memory api-segment” to look for API segment memory leaks.

Good luck.

Dave

static clib_error_t *
enable_disable_memory_trace (vlib_main_t * vm,
 unformat_input_t * input,
 vlib_cli_command_t * cmd)
{
  unformat_input_t _line_input, *line_input = &_line_input;
  int enable;
  int api_segment = 0;
  void *oldheap;


  if (!unformat_user (input, unformat_line_input, line_input))
return 0;

  while (unformat_check_input (line_input) != UNFORMAT_END_OF_INPUT)
{
  if (unformat (line_input, "%U", unformat_vlib_enable_disable, ))
 ;
  else if (unformat (line_input, "api-segment"))
 api_segment = 1;
  else
 {
   unformat_free (line_input);
   return clib_error_return (0, "invalid input");
 }
}
  unformat_free (line_input);

  if (api_segment)
oldheap = vl_msg_push_heap ();
  clib_mem_trace (enable);
  if (api_segment)
vl_msg_pop_heap (oldheap);

  return 0;
}

/* *INDENT-OFF* */
VLIB_CLI_COMMAND (enable_disable_memory_trace_command, static) = {
  .path = "memory-trace",
  .short_help = "on|off [api-segment] Enable/disable memory allocation trace",
  .function = enable_disable_memory_trace,
};
/* *INDENT-ON* */


static clib_error_t *
show_memory_usage (vlib_main_t * vm,
  unformat_input_t * input, vlib_cli_command_t * cmd)
{
  int verbose __attribute__ ((unused)) = 0, api_segment = 0;
  clib_error_t *error;
  u32 index = 0;

  while (unformat_check_input (input) != UNFORMAT_END_OF_INPUT)
{
  if (unformat (input, "verbose"))
 verbose = 1;
  else if (unformat (input, "api-segment"))
 api_segment = 1;
  else
 {
   error = clib_error_return (0, "unknown input `%U'",
  format_unformat_error, input);
   return error;
 }
}

  if (api_segment)
{
  void *oldheap = vl_msg_push_heap ();
  u8 *s_in_svm =
 format (0, "%U\n", format_mheap, clib_mem_get_heap (), 1);
  vl_msg_pop_heap (oldheap);
  u8 *s = vec_dup (s_in_svm);

  oldheap = vl_msg_push_heap ();
  vec_free (s_in_svm);
  vl_msg_pop_heap (oldheap);
  vlib_cli_output (vm, "API segment start:");
  vlib_cli_output (vm, "%v", s);
  vlib_cli_output (vm, "API segment end:");
  vec_free (s);
}

#if USE_DLMALLOC == 0
  /* *INDENT-OFF* */
  foreach_vlib_main (
  ({
  mheap_t *h = mheap_header (clib_per_cpu_mheaps[index]);
  vlib_cli_output (vm, "%sThread %d %s\n", index ? "\n":"", index,
  vlib_worker_threads[index].name);
  vlib_cli_output (vm, "  %U\n", format_page_map, pointer_to_uword (h) -
 h->vm_alloc_offset_from_header,
  h->vm_alloc_size);
  vlib_cli_output (vm, "  %U\n", format_mheap, clib_per_cpu_mheaps[index],
   verbose);
  index++;
  }));
  /* *INDENT-ON* */
#else
  {
uword clib_mem_trace_enable_disable (uword enable);
uword was_enabled;

/*
 * Note: the foreach_vlib_main cause allocator traffic,
 * so shut off tracing before we go there...
 */
was_enabled = clib_mem_trace_enable_disable (0);

/* *INDENT-OFF* */
   foreach_vlib_main (
({
  struct dlmallinfo mi;
  void *mspace;
  mspace = clib_per_cpu_mheaps[index];

  mi = mspace_mallinfo (mspace);
  vlib_cli_output (vm, "%sThread %d %s\n", index ? "\n":"", index,
  vlib_worker_threads[index].name);
  vlib_cli_output (vm, "  %U\n", format_page_map,
   pointer_to_uword (mspace_least_addr(mspace)),
   mi.arena);
  vlib_cli_output (vm, "  %U\n", format_mheap, clib_per_cpu_mheaps[index],
   verbose);
  index++;
}));
/* *INDENT-ON* */

/* Restore the trace flag */
clib_mem_trace_enable_disable (was_enabled);
  }
#endif /* USE_DLMALLOC */
  return 0;
}

/* *INDENT-OFF* */
VLIB_CLI_COMMAND (show_memory_usage_command, static) = {
  .path = "show memory",
  .short_help = "[verbose | api-segment] Show current memory usage",
  .function = show_memory_usage,
};
/*

[vpp-dev] VPP crashing out of dead_client_scan()

2018-10-23 Thread siddarth rai 
Hi all,
I am facing an occasional VPP crash from dead_client_scan() when I restart
a client .
I am using VPP version v18.01.1-100~g3a6948c.  Upgrading to a newer version
is not an option for me currently.

Here is the backtrace :

Program terminated with signal 6, Aborted.
*#0  0x2ad10a37f207 in raise () from /lib64/libc.so.6*
*Missing separate debuginfos, use: debuginfo-install
OPWVmepCR-99.9-el7.x86_64*
*(gdb) bt*
*#0  0x2ad10a37f207 in raise () from /lib64/libc.so.6*
*#1  0x2ad10a3808f8 in abort () from /lib64/libc.so.6*
*#2  0x00405ef3 in os_panic () at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vpp/vnet/main.c:268*
*#3  0x2ad1097fb6d2 in clib_mem_alloc_aligned_at_offset
(os_out_of_memory_on_failure=1, align_offset=, align=4,
size=60)*
*at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vppinfra/mem.h:105*
*#4  vec_resize_allocate_memory (v=,
length_increment=length_increment@entry=4, data_bytes=,
header_bytes=, header_bytes@entry=0,
data_align=data_align@entry=4)*
*at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vppinfra/vec.c:84*
*#5  0x2ad1097bd5bc in _vec_resize (data_align=0, header_bytes=0,
data_bytes=, length_increment=4, v=)*
*at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vppinfra/vec.h:142*
*#6  format_integer (s=, s@entry=0x308d6a84
"svm_client_scan_this_region_nolock:", number=,
options=options@entry=0x2ad10d3cabf0)*
*at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vppinfra/format.c:535*
*#7  0x2ad1097be32e in do_percent (va=0x2ad10d3cac78, fmt=, _s=)*
*at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vppinfra/format.c:314*
*#8  va_format (s=0x308d6a84 "svm_client_scan_this_region_nolock:",
fmt=, va=va@entry=0x2ad10d3cac78)*
*at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vppinfra/format.c:404*
*#9  0x2ad1097bd707 in format (s=,
fmt=fmt@entry=0x2ad10980b5a3 "%wd:")*
*at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vppinfra/format.c:423*
*#10 0x2ad1097b9234 in _clib_error (how_to_die=how_to_die@entry=4,
function_name=function_name@entry=0x2ad10959a0a0 <__FUNCTION__.11526>
"svm_client_scan_this_region_nolock", line_number=line_number@entry=1205, *
*fmt=fmt@entry=0x2ad10959a00f "%s: cleanup ghost pid %d") at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vppinfra/error.c:122*
*#11 0x2ad109586b11 in svm_client_scan_this_region_nolock
(rp=0x30021000) at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/svm/svm.c:1204*
*#12 0x2ad10820b896 in dead_client_scan (am=,
now=, shm=0x3004300c)*
*at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vlibmemory/memory_vlib.c:803*
*#13 memclnt_process (vm=0x2ad1086af260 ,
node=0x2ad10d3c2000, f=)*
*at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vlibmemory/memory_vlib.c:1091*
*#14 0x2ad10845b656 in vlib_process_bootstrap (_a=) at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vlib/main.c:1231*
*#15 0x2ad1097c6838 in clib_calljmp () at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vppinfra/longjmp.S:110*
*#16 0x2ad10d249e30 in ?? ()*
*#17 0x2ad10845c999 in vlib_process_startup (f=0x0, p=0x2ad10d3c2000,
vm=0x2ad1086af260 )*
*at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vlib/main.c:1253*
*#18 dispatch_process (vm=0x2ad1086af260 ,
p=0x2ad10d3c2000, last_time_stamp=59319358378453656, f=0x0)*
*at
/bfs-build/build-area.44/builds/LinuxNBngp_mainline_RH7/2018-10-18-1026/third-party/vpp/vpp_1801/build-data/../src/vlib/main.c:1296*

Any help will be greatly appreciated.

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

View/Reply Online (#10918): https://lists.fd.io/g/vpp-dev/message/10918
Mute This Topic: https://lists.fd.io/mt/27567087/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 translate some ctrl data to OS ?

2018-10-23 Thread Dave Barach via Lists.Fd.Io 
See https://wiki.fd.io/view/VPP/VPP_Home_Gateway for a NAT-based example.

From: vpp-dev@lists.fd.io  On Behalf Of 
wangchuan...@163.com
Sent: Tuesday, October 23, 2018 2:55 AM
To: vpp-dev 
Subject: [vpp-dev] How translate some ctrl data to OS ?

Hi all，
PCA have running a VPP that have only 1 hw_if : GigabitEthernet2/0/0 , 1 
ip:172.16.0.2/16,   and already have vxlan [172.16.0.2 - 172.16.0.3].
How should I config the vpp to let me login the PCA'sOS from 172.16.0.4 by SSH ?

Is there some feature ? e.g. ip-port mapping







wangchuan...@163.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] about gtpu encap

2018-10-23 Thread 刘道林 
Hi,

I have a question about gtpu encap node in VPP. My network topology is:

[cid:image002.jpg@01D46AC2.C0DA7910]

VPP is running on GW in Linux VM with two IP interfaces, and eNB & CN in the 
above graph are running on two different Linux VMs with only one IP interface. 
After starting VPP and some regular settings with CLI, I can ping CN from eNB 
side successfully, vice versa without any problem.

Currently, my requirement is that setting gtpu tunnels between both eNB<->GW 
and GW<->CN, and then from the eNB side, it will send UDP packet to GW with 
gtpu (port 2152, src IP 192.168.2.2, dst IP 192.168.2.1), and VPP can decap 
this gtpu packet (teid 261) to get T-PDU data, and then re-encap gtpu (teid 
262) and udp to send to CN (port 2152, src IP 192.168.3.1, dst IP 192.168.3.2). 
Something like this:

[cid:image004.jpg@01D46AE8.31D69390]

You can see below original packet from eNB side.

[cid:image006.jpg@01D46AE8.31D69390]

Actually, I don't need VPP to decode the payload in red color, i.e. T-PDU Data 
4500…… I just want to keep this T-PDU Data and then fill the new teid and src & 
dst IP to send to CN side. The output packet should like this:

[cid:image008.jpg@01D46AE8.31D69390]

I run below command to set tunnels:

vppctl create gtpu tunnel src 192.168.2.1 dst 192.168.2.2 teid 261
vppctl create gtpu tunnel src 192.168.3.2 dst 192.168.3.1 teid 262

and capture the original packet with "show trace" successfully. But the VPP 
treated the payload 4500…… as l2-input since I didn't set "decap-next node" in 
above command.

But if I use below command:

vppctl create gtpu tunnel src 192.168.2.1 dst 192.168.2.2 teid 261 decap-next 
node gtpu4-encap
vppctl create gtpu tunnel src 192.168.3.2 dst 192.168.3.1 teid 262 decap-next 
node gtpu4-encap

The VPP process will be crashed. Maybe I miss something or my command is not 
correct enough. Actually I found that there is no previous node for 
gtpu4-encap. I don't know why.

Could you please show me what should I do to satisfy my requirement which is 
not complex in my mind?

Thanks a lot!
Best regards
刘道林 (Daolin Liu)
T大连市共进科技有限公司
DALIAN GONGJIN TECHNOLOGY CO.,LTD
中国大连市高新园区软件园路1A-4-24层
Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
直线(TEL)：(86-411)39996705   分机(EXT)：76824
手机(Mobile)：(86)13704090959

本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部的泄漏、阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你所接收到的文本。
 This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#10916): https://lists.fd.io/g/vpp-dev/message/10916
Mute This Topic: https://lists.fd.io/mt/27566720/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] PPPoE plugin documentation/support

2018-10-23 Thread Ni, Hongjun 
Hi Alp Arslan,

To make tap_cli work, you need to revert the code as per this patch:
https://gerrit.fd.io/r/#/c/9467/ 

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of 
alp.ars...@xflowresearch.com
Sent: Tuesday, October 23, 2018 4:01 PM
To: Ni, Hongjun ; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] PPPoE plugin documentation/support

Dell - Internal Use - Confidential  

Dear Hongjun, 

Thanks for the reply. 

I am using the VPP version 18.07. If the tap_cli is still present, can you 
please point me towards what could be the problem with the existing plugin. 
I would like to see this one working a little bit, before starting to look into 
tapv2.

Regards,
Alp Arslan

-Original Message-
From: Ni, Hongjun [mailto:hongjun...@intel.com]
Sent: Tuesday, October 23, 2018 12:51 PM
To: alp.ars...@xflowresearch.com; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] PPPoE plugin documentation/support

Hi Alp Arslan,

Since tap_cli code is going to be deprecated in favour of tapv2.
I suggest you leverage tapv2, and also need some rework for PPPoE plugin.

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of 
alp.ars...@xflowresearch.com
Sent: Tuesday, October 23, 2018 3:08 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] PPPoE plugin documentation/support

Dear All, 

I am trying to evaluate the support of pppoe in vpp. However, I am facing some 
issues, here is my startup conf file. 

unix {
  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid vpp
}
api-trace {
  on
}
api-segment {
  gid vpp
}
socksvr {
  default
}
cpu {
main-core 1
corelist-workers 2,4,3,5
}
dpdk {
dev :05:00.1
uio-driver vfio-pci
socket-mem 2048,2048
}
plugins {
plugin default { enable}
}
tuntap {
  enable
  ethernet
  name newtap
}

After that I run the following commands: 

vpp# set interface state TenGigabitEthernet5/0/1 up vpp# set interface state
local0 up

Now at this point if I try to connect from the pppoe client, I can see three 
PADI request reaching VPP, and VPP trying to forward them at local0 interface. 
To forward this traffic to the tap port instead, I use this command. 

vpp# create pppoe cp cp-if-index 2

The help and the documentation for this command show this "create pppoe cp 
if-name  [del]", which doesn't work.
Now at this moment, I was expecting the VPP to forward the PADI request to
tuntap-0 interface, but I don't see anything in the VPP counters, nor by using 
tcpdump on interface "newtap" which is the kernel facing side of "tuntap-0" 
interface. 

My question is, Is my approach correct? Are the PADI requests forwarded to the 
tuntap-0 interface? If not where do they go? I cannot find any good 
documentation on this anywhere. 
Any help regarding this would be highly appreciated. 

Regards,
Alp Arslan




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

View/Reply Online (#10915): https://lists.fd.io/g/vpp-dev/message/10915
Mute This Topic: https://lists.fd.io/mt/27566265/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] PPPoE plugin documentation/support

2018-10-23 Thread alp . arslan 
Dell - Internal Use - Confidential  

Dear Hongjun, 

Thanks for the reply. 

I am using the VPP version 18.07. If the tap_cli is still present, can you
please point me towards what could be the problem with the existing plugin. 
I would like to see this one working a little bit, before starting to look
into tapv2.

Regards,
Alp Arslan

-Original Message-
From: Ni, Hongjun [mailto:hongjun...@intel.com] 
Sent: Tuesday, October 23, 2018 12:51 PM
To: alp.ars...@xflowresearch.com; vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] PPPoE plugin documentation/support

Hi Alp Arslan,

Since tap_cli code is going to be deprecated in favour of tapv2.
I suggest you leverage tapv2, and also need some rework for PPPoE plugin.

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of
alp.ars...@xflowresearch.com
Sent: Tuesday, October 23, 2018 3:08 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] PPPoE plugin documentation/support

Dear All, 

I am trying to evaluate the support of pppoe in vpp. However, I am facing
some issues, here is my startup conf file. 

unix {
  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid vpp
}
api-trace {
  on
}
api-segment {
  gid vpp
}
socksvr {
  default
}
cpu {
main-core 1
corelist-workers 2,4,3,5
}
dpdk {
dev :05:00.1
uio-driver vfio-pci
socket-mem 2048,2048
}
plugins {
plugin default { enable}
}
tuntap {
  enable
  ethernet
  name newtap
}

After that I run the following commands: 

vpp# set interface state TenGigabitEthernet5/0/1 up vpp# set interface state
local0 up

Now at this point if I try to connect from the pppoe client, I can see three
PADI request reaching VPP, and VPP trying to forward them at local0
interface. 
To forward this traffic to the tap port instead, I use this command. 

vpp# create pppoe cp cp-if-index 2

The help and the documentation for this command show this "create pppoe cp
if-name  [del]", which doesn't work.
Now at this moment, I was expecting the VPP to forward the PADI request to
tuntap-0 interface, but I don't see anything in the VPP counters, nor by
using tcpdump on interface "newtap" which is the kernel facing side of
"tuntap-0" interface. 

My question is, Is my approach correct? Are the PADI requests forwarded to
the tuntap-0 interface? If not where do they go? I cannot find any good
documentation on this anywhere. 
Any help regarding this would be highly appreciated. 

Regards,
Alp Arslan




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

View/Reply Online (#10914): https://lists.fd.io/g/vpp-dev/message/10914
Mute This Topic: https://lists.fd.io/mt/27566265/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] PPPoE plugin documentation/support

2018-10-23 Thread Ni, Hongjun 
Hi Alp Arslan,

Since tap_cli code is going to be deprecated in favour of tapv2.
I suggest you leverage tapv2, and also need some rework for PPPoE plugin.

Thanks,
Hongjun

-Original Message-
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of 
alp.ars...@xflowresearch.com
Sent: Tuesday, October 23, 2018 3:08 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] PPPoE plugin documentation/support

Dear All, 

I am trying to evaluate the support of pppoe in vpp. However, I am facing some 
issues, here is my startup conf file. 

unix {
  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid vpp
}
api-trace {
  on
}
api-segment {
  gid vpp
}
socksvr {
  default
}
cpu {
main-core 1
corelist-workers 2,4,3,5
}
dpdk {
dev :05:00.1
uio-driver vfio-pci
socket-mem 2048,2048
}
plugins {
plugin default { enable}
}
tuntap {
  enable
  ethernet
  name newtap
}

After that I run the following commands: 

vpp# set interface state TenGigabitEthernet5/0/1 up vpp# set interface state 
local0 up

Now at this point if I try to connect from the pppoe client, I can see three 
PADI request reaching VPP, and VPP trying to forward them at local0 interface. 
To forward this traffic to the tap port instead, I use this command. 

vpp# create pppoe cp cp-if-index 2

The help and the documentation for this command show this "create pppoe cp 
if-name  [del]", which doesn't work.
Now at this moment, I was expecting the VPP to forward the PADI request to
tuntap-0 interface, but I don't see anything in the VPP counters, nor by using 
tcpdump on interface "newtap" which is the kernel facing side of "tuntap-0" 
interface. 

My question is, Is my approach correct? Are the PADI requests forwarded to the 
tuntap-0 interface? If not where do they go? I cannot find any good 
documentation on this anywhere. 
Any help regarding this would be highly appreciated. 

Regards,
Alp Arslan



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

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

[vpp-dev] PPPoE plugin documentation/support

2018-10-23 Thread alp . arslan 
Dear All, 

I am trying to evaluate the support of pppoe in vpp. However, I am facing
some issues, here is my startup conf file. 

unix {
  nodaemon
  log /var/log/vpp/vpp.log
  full-coredump
  cli-listen /run/vpp/cli.sock
  gid vpp
}
api-trace {
  on
}
api-segment {
  gid vpp
}
socksvr {
  default
}
cpu {
main-core 1
corelist-workers 2,4,3,5
}
dpdk {
dev :05:00.1
uio-driver vfio-pci
socket-mem 2048,2048
}
plugins {
plugin default { enable}
}
tuntap {
  enable
  ethernet
  name newtap
}

After that I run the following commands: 

vpp# set interface state TenGigabitEthernet5/0/1 up
vpp# set interface state local0 up

Now at this point if I try to connect from the pppoe client, I can see three
PADI request reaching VPP, and VPP trying to forward them at local0
interface. 
To forward this traffic to the tap port instead, I use this command. 

vpp# create pppoe cp cp-if-index 2

The help and the documentation for this command show this "create pppoe cp
if-name  [del]", which doesn't work.
Now at this moment, I was expecting the VPP to forward the PADI request to
tuntap-0 interface, but I don't see anything in the VPP counters, nor by
using tcpdump on interface "newtap" which is the kernel facing side of
"tuntap-0" interface. 

My question is, Is my approach correct? Are the PADI requests forwarded to
the tuntap-0 interface? If not where do they go? I cannot find any good
documentation on this anywhere. 
Any help regarding this would be highly appreciated. 

Regards, 
Alp Arslan



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

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

[vpp-dev] How translate some ctrl data to OS ?

2018-10-23 Thread wangchuan...@163.com 
Hi all，
PCA have running a VPP that have only 1 hw_if : GigabitEthernet2/0/0 , 1 
ip:172.16.0.2/16,   and already have vxlan [172.16.0.2 - 172.16.0.3].
How should I config the vpp to let me login the PCA'sOS from 172.16.0.4 by SSH ?

Is there some feature ? e.g. ip-port mapping 








wangchuan...@163.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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