date:20190313

Re: [vpp-dev] Fragmentation and Reassembly #vnet

2019-03-13 Thread Ole Troan

> I am new to VPP and experimenting with it.
> I was able to get Reass/Frag working on regular Interfaces.
>  
> The question i have is does Reassembly and Fragmentation supported on Tunnel 
> interfaces(Both VXLAN/IPSec).
> If supported, is there any config knob i need to enable in addition to 
> enabling feature on those interfaces.
>  
> I am running V18.10. Any inputs will be of great help.

Firstly if you need fragmentation and reassembly you are probably doing 
something wrong. ;-)

Fragmentation is done both for IPv4 and IPv6 in the rewrite node. For IPv6 it 
is only done for locally originated. packets.
Somewhat depending on inner tunnel MTU and outer interface MTU, you can end up 
with inner or outer fragmentation in the tunnel.

Full reassembly is enabled by default only for forus packets (destined to one 
of VPP’s addresses).
It can be enabled in-path as well, but that’s probably not a good idea.
Virtual reassembly is integrated into NAT, MAP, and I’m working on generalising 
that.

None of these are tunnel type specific. (Although some tunnels act as input 
features, or have their own FIB DPO, bypassing the “forus” check).

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

View/Reply Online (#12502): https://lists.fd.io/g/vpp-dev/message/12502
Mute This Topic: https://lists.fd.io/mt/30410981/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] vlib_buffer_free_inline with CLIB_HAVE_VEC128 will always free buffers one by one, not via the 4 packets batch fast path

2019-03-13 Thread lollita

Hi, Damjan.

We found in vlib_buffer_free_inline with CLIB_HAVE_VEC128, buffers will always 
be freed one by one, not via the 4 packets batch fast path. The phenomenon is 
the same by calling via avf_device_class_tx_fn or via error_drop.
   It will add about 20 CPU cycles in my test case, the pain point is 
clib_atomic_sub_fetch. Perf result attached for your reference.

  27.54%  avf_plugin.so [.] avf_device_class_tx_fn_avx2
  20.89%  libvnet.so.19.04  [.] ip4_rewrite_node_fn_avx2
  13.12%  libvnet.so.19.04  [.] ip4_lookup_node_fn_avx2
  12.47%  dpdk_plugin.so[.] ipsec_tx_input_node_fn_avx2
   8.14%  libvlib.so.19.04  [.] vlib_worker_loop
   4.65%  libvlib.so.19.04  [.] dispatch_pending_node
   4.64%  libvnet.so.19.04  [.] vnet_interface_output_node
   3.15%  dpdk_plugin.so[.] ipsec_encrypt_tx_node_fn_avx2
   1.60%  dpdk_plugin.so[.] dpdk_crypto_input_node_fn_avx2
   1.31%  libvlib.so.19.04  [.] vlib_put_next_frame
   1.02%  libvlib.so.19.04  [.] vlib_get_next_frame_internal
   0.44%  libvppinfra.so.19.04  [.] mspace_usable_size_with_delta
   0.44%  libvppinfra.so.19.04  [.] mspace_usable_size
   0.29%  libc-2.23.so  [.] __memmove_avx_unaligned
   0.15%  libvnet.so.19.04  [.] vlib_put_next_frame@plt
   0.15%  libvnet.so.19.04  [.] vnet_get_main
   0.00%  [kernel]  [k] native_write_msr


   │if (clib_atomic_sub_fetch (&b[0]->ref_count, 1) == 0)
  0.29 │lock   subb $0x1,0xc(%rax)
20.48 │ ┌──jne1955
   │ │  mov%ecx,%eax
   │ │  add$0x1,%ecx
   │ │{
   │ │  vlib_buffer_copy_template (b[0], &bt);
  0.87 │192b:│  mov-0x4b0(%rbp),%rdx

   After checking the source code, I think the implement is different with 
or without CLIB_HAVE_VEC128.

   Without CLIB_HAVE_VEC128, as long as the four packets are not in buffer 
chain, with ref_count as 1, and allocated by same buffer pool, they will be 
freed in batch.
   With CLIB_HAVE_VEC128, even in those condition, the sum will be not 0, 
and will goto one_by_one.

   My suggestion is set ref_count in flags_refs_mask to 1, then if the 
ref_count is 0 or 1, it will go to fast path. This is not totally same as 
without CLIB_HAVE_VEC128, but it looks is the most simplified fix.

  vlib_buffer_t flags_refs_mask = {
.flags = VLIB_BUFFER_NEXT_PRESENT,
.ref_count = ~1
  };

BR/Lollita Liu

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

View/Reply Online (#12503): https://lists.fd.io/g/vpp-dev/message/12503
Mute This Topic: https://lists.fd.io/mt/30414067/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] vlib_buffer_free_inline with CLIB_HAVE_VEC128 will always free buffers one by one, not via the 4 packets batch fast path

2019-03-13 Thread Damjan Marion via Lists.Fd.Io


On 13 Mar 2019, at 10:19, Lollita Liu 
mailto:lollita@ericsson.com>> wrote:

Hi, Damjan.

We found in vlib_buffer_free_inline with CLIB_HAVE_VEC128, buffers will always 
be freed one by one, not via the 4 packets batch fast path. The phenomenon is 
the same by calling via avf_device_class_tx_fn or via error_drop.
   It will add about 20 CPU cycles in my test case, the pain point is 
clib_atomic_sub_fetch. Perf result attached for your reference.

  27.54%  avf_plugin.so [.] avf_device_class_tx_fn_avx2
  20.89%  libvnet.so.19.04  [.] ip4_rewrite_node_fn_avx2
  13.12%  libvnet.so.19.04  [.] ip4_lookup_node_fn_avx2
  12.47%  dpdk_plugin.so[.] ipsec_tx_input_node_fn_avx2
   8.14%  libvlib.so.19.04  [.] vlib_worker_loop
   4.65%  libvlib.so.19.04  [.] dispatch_pending_node
   4.64%  libvnet.so.19.04  [.] vnet_interface_output_node
   3.15%  dpdk_plugin.so[.] ipsec_encrypt_tx_node_fn_avx2
   1.60%  dpdk_plugin.so[.] dpdk_crypto_input_node_fn_avx2
   1.31%  libvlib.so.19.04  [.] vlib_put_next_frame
   1.02%  libvlib.so.19.04  [.] vlib_get_next_frame_internal
   0.44%  libvppinfra.so.19.04  [.] mspace_usable_size_with_delta
   0.44%  libvppinfra.so.19.04  [.] mspace_usable_size
   0.29%  libc-2.23.so  [.] __memmove_avx_unaligned
   0.15%  libvnet.so.19.04  [.] vlib_put_next_frame@plt
   0.15%  libvnet.so.19.04  [.] vnet_get_main
   0.00%  [kernel]  [k] native_write_msr


   │if (clib_atomic_sub_fetch (&b[0]->ref_count, 1) == 0)
  0.29 │lock   subb $0x1,0xc(%rax)
20.48 │ ┌──jne1955
   │ │  mov%ecx,%eax
   │ │  add$0x1,%ecx
   │ │{
   │ │  vlib_buffer_copy_template (b[0], &bt);
  0.87 │192b:│  mov-0x4b0(%rbp),%rdx

   After checking the source code, I think the implement is different with 
or without CLIB_HAVE_VEC128.

   Without CLIB_HAVE_VEC128, as long as the four packets are not in buffer 
chain, with ref_count as 1, and allocated by same buffer pool, they will be 
freed in batch.
   With CLIB_HAVE_VEC128, even in those condition, the sum will be not 0, 
and will goto one_by_one.

   My suggestion is set ref_count in flags_refs_mask to 1, then if the 
ref_count is 0 or 1, it will go to fast path.

At this point ref_count cannot be 0.

This is not totally same as without CLIB_HAVE_VEC128, but it looks is the most 
simplified fix.

  vlib_buffer_t flags_refs_mask = {
.flags = VLIB_BUFFER_NEXT_PRESENT,
.ref_count = ~1
  };

Makes sense to me, and it should be the same as ref_count==0 at this point is 
not possible.
Can you please submit the patch. I know you already did it as part of bigger 
one which i half-merged.
Going forward please make one fix per patch.

Thanks

--
Damjan



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

View/Reply Online (#12504): https://lists.fd.io/g/vpp-dev/message/12504
Mute This Topic: https://lists.fd.io/mt/30414067/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] Standard VPP functionality for AD4,AD6,AS4,AS6

2019-03-13 Thread Gunaseelan Venkatachary - ERS, HCL Tech

Team
Am resending the same again as I am not sure the former one had reached the 
forum , Sorry

Best Regards
Gunaseelan V
98408 60856

From: Gunaseelan Venkatachary - ERS, HCL Tech
Sent: Friday, March 8, 2019 3:00 PM
To: vpp-dev@lists.fd.io
Subject: Standard VPP functionality for AD4,AD6,AS4,AS6

Team
Wish to share our observations on validating AD4, AD6 ; AS4 & AS6 functionality 
using VPP . We faced issues compared to AD2 (Eth) functionality testing and 
following is the summary

For AD2: In Egress packets are getting received from VM's (QEMU VM) 
vhost-user-input which is sibling of device-input
For AD4: In Egress packets are getting received from vhost-user-input, so here 
packets are going to ethernet-input node which are received from virtual 
interface and pkt is getting dropped in Ethernet because of wrong mac. As the 
AD4 feature is enabled in ip4-unicast arc, packets are dropped even before 
coming to this arc.


/* *INDENT-OFF* */
VNET_FEATURE_INIT (srv6_ad2_rewrite, static) =
{
   .arc_name = "device-input",
   .node_name = "srv6-ad2-rewrite",
   .runs_before = VNET_FEATURES ("ethernet-input"),
};

VNET_FEATURE_INIT (srv6_ad4_rewrite, static) =
{
   .arc_name = "ip4-unicast",
   .node_name = "srv6-ad4-rewrite",
   .runs_before = 0,
};

We have modified the code to receive the packet from device-input as below

VNET_FEATURE_INIT (srv6_ad4_rewrite, static) =
{
   .arc_name = "device-input",
   .node_name = "srv6-ad4-rewrite",
   .runs_before = 0,
};

After this change, we see its working fine, wish to check if our observation 
fine along with code changes.

Also we would like to know what setup you have used to act as VM ?? that is, 
whether you have used vhost-user-input for sending and receiving packets 
to/from VM respectively.


Best Regards
Gunaseelan V
98408 60856

::DISCLAIMER::
--
The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.
--
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

[vpp-dev] Fragmentation and Reassembly

2019-03-13 Thread via Lists.Fd.Io

I am new to VPP and experimenting with it.
I was able to get Reass/Frag working on regular Interfaces.
The question i have is does Reassembly and Fragmentation supported on Tunnel 
interfaces(Both VXLAN/IPSec).If supported, is there any config knob i need to 
enable in addition to enabling feature on those interfaces.
I am running V18.10. Any inputs will be of great help.

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

View/Reply Online (#12506): https://lists.fd.io/g/vpp-dev/message/12506
Mute This Topic: https://lists.fd.io/mt/30410981/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Standard VPP functionality for AD4,AD6,AS4,AS6

2019-03-13 Thread Damjan Marion via Lists.Fd.Io


I bet that more than 90% of subscribers to this list doesn’t know what 
AD4,AD6,AS4,AS6 means (including myself).
Out of code snippets you provided, looks like it is SR related.

So might be worth adding existing code author(s) to CC, as maybe they are not 
reading this list very frequently.
“git blame” might be useful for finding right names.


> On 13 Mar 2019, at 11:31, Gunaseelan Venkatachary - ERS, HCL Tech 
>  wrote:
> 
> Team 
> Am resending the same again as I am not sure the former one had reached the 
> forum , Sorry
>  
> Best Regards
> Gunaseelan V
> 98408 60856
>  
> From: Gunaseelan Venkatachary - ERS, HCL Tech 
> Sent: Friday, March 8, 2019 3:00 PM
> To: vpp-dev@lists.fd.io 
> Subject: Standard VPP functionality for AD4,AD6,AS4,AS6 
>  
> Team 
> Wish to share our observations on validating AD4, AD6 ; AS4 & AS6 
> functionality using VPP . We faced issues compared to AD2 (Eth) functionality 
> testing and following is the summary
>  
> For AD2: In Egress packets are getting received from VM’s (QEMU VM) 
> vhost-user-input which is sibling of device-input
> For AD4: In Egress packets are getting received from vhost-user-input, so 
> here packets are going to ethernet-input node which are received from virtual 
> interface and pkt is getting dropped in Ethernet because of wrong mac. As the 
> AD4 feature is enabled in ip4-unicast arc, packets are dropped even before 
> coming to this arc.
>  
>  
> /* *INDENT-OFF* */
> VNET_FEATURE_INIT (srv6_ad2_rewrite, static) =
> {
>.arc_name = "device-input",
>.node_name = "srv6-ad2-rewrite",
>.runs_before = VNET_FEATURES ("ethernet-input"),
> };
>  
> VNET_FEATURE_INIT (srv6_ad4_rewrite, static) =
> {
>.arc_name = "ip4-unicast",
>.node_name = "srv6-ad4-rewrite",
>.runs_before = 0,
> };
>  
> We have modified the code to receive the packet from device-input as below
>  
> VNET_FEATURE_INIT (srv6_ad4_rewrite, static) =
> {
>.arc_name = "device-input",
>.node_name = "srv6-ad4-rewrite",
>.runs_before = 0,
> };
>  
> After this change, we see its working fine, wish to check if our observation 
> fine along with code changes.
>  
> Also we would like to know what setup you have used to act as VM ?? that is, 
> whether you have used vhost-user-input for sending and receiving packets 
> to/from VM respectively.
>  
>  
> Best Regards
> Gunaseelan V
> 98408 60856
>  
> ::DISCLAIMER::
> --
> The contents of this e-mail and any attachment(s) are confidential and 
> intended for the named recipient(s) only. E-mail transmission is not 
> guaranteed to be secure or error-free as information could be intercepted, 
> corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses 
> in transmission. The e mail and its contents (with or without referred 
> errors) shall therefore not attach any liability on the originator or HCL or 
> its affiliates. Views or opinions, if any, presented in this email are solely 
> those of the author and may not necessarily reflect the views or opinions of 
> HCL or its affiliates. Any form of reproduction, dissemination, copying, 
> disclosure, modification, distribution and / or publication of this message 
> without the prior written consent of authorized representative of HCL is 
> strictly prohibited. If you have received this email in error please delete 
> it and notify the sender immediately. Before opening any email and/or 
> attachments, please check them for viruses and other defects.
> --
>  -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12505): https://lists.fd.io/g/vpp-dev/message/12505 
> 
> Mute This Topic: https://lists.fd.io/mt/30307126/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 (#12507): https://lists.fd.io/g/vpp-dev/message/12507
Mute This Topic: https://lists.fd.io/mt/30307126/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Build VPP packages on aarch64

2019-03-13 Thread Lijian Zhang

Hi Maintainers,
The current aarch64 version of VPP package distro in cloud repository 
(https://packagecloud.io/fdio/master/ubuntu) is made on a ThunderX server.
During the compilation process, no matter what type of make target is (either 
binaries, e.g, build/build-release, or packages, e.g., pkg-deb, pkg-rpm), it's 
always using some arch-specific options, e.g., 128Byte cache line size, 
T=arm64-thunderx-linuxapp-gcc, RTE_MACHINE=thunderx, even for the package 
distro to be uploaded into cloud repository.

The aarch64 version of package distro crashed on current CSIT performance 
testing aarch64 servers due to the non-generic compilation options. And that 
non-generic options may also cause performance drop on other aarch64 variants.

So VPP/Aarch64 community has a  suggestion that,
1. for binary type target, e.g., build/build-release, the compilation can use 
arch-specific options
2. for package type target, e.g., pkg-deb/pkg-rpm, the compilation has to  use 
generic options, e.g., 64Byte cache line size, T=arm64-armv8a-linuxapp-gcc, 
RTE_MACHINE=armv8a

Makefile gets to know if it's binary target or package target by checking if 
there's a string of 'package' in target name.

A draft patch is as below. Appreciate your suggestions.

diff --git a/build-data/packages/external.mk b/build-data/packages/external.mk
index 1ed3f09af..03e902dc1 100644
--- a/build-data/packages/external.mk
+++ b/build-data/packages/external.mk
@@ -42,6 +42,10 @@ endif
DPDK_PLATFORM_TARGET=$(strip $($(PLATFORM)_dpdk_target))
ifneq ($(DPDK_PLATFORM_TARGET),)
DPDK_MAKE_ARGS += DPDK_TARGET=$(DPDK_PLATFORM_TARGET)
+else
+ifneq (,$(findstring package,$(MAKECMDGOALS)))
+DPDK_MAKE_ARGS += DPDK_TARGET_GENERIC=y
+endif
endif
 DPDK_MAKE_EXTRA_ARGS = $(strip $($(PLATFORM)_dpdk_make_extra_args))
diff --git a/build-data/packages/vpp.mk b/build-data/packages/vpp.mk
index 9ce557a99..6c6cb4446 100644
--- a/build-data/packages/vpp.mk
+++ b/build-data/packages/vpp.mk
@@ -31,6 +31,9 @@ vpp_cmake_args += 
-DCMAKE_PREFIX_PATH:PATH="$(vpp_cmake_prefix_path)"
ifeq ("$(V)","1")
vpp_cmake_args += -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
endif
+ifneq (,$(findstring package,$(MAKECMDGOALS)))
+vpp_cmake_args += -DCMAKE_TARGET_GENERIC:BOOL=ON
+endif
 # Use devtoolset on centos 7
ifneq ($(wildcard /opt/rh/devtoolset-7/enable),)
diff --git a/build/external/packages/dpdk.mk b/build/external/packages/dpdk.mk
index 9e10fca1a..1cf2de196 100644
--- a/build/external/packages/dpdk.mk
+++ b/build/external/packages/dpdk.mk
@@ -15,6 +15,7 @@ DPDK_PKTMBUF_HEADROOM?= 128
DPDK_CACHE_LINE_SIZE ?= 64
DPDK_DOWNLOAD_DIR?= $(DL_CACHE_DIR)
DPDK_DEBUG   ?= n
+DPDK_TARGET_GENERIC  ?= n
DPDK_MLX4_PMD?= n
DPDK_MLX5_PMD?= n
DPDK_MLX5_PMD_DLOPEN_DEPS?= n
@@ -69,6 +70,9 @@ DPDK_TARGET   ?= arm64-armv8a-linuxapp-$(DPDK_CC)
DPDK_MACHINE  ?= armv8a
DPDK_TUNE ?= generic
+# Assign aarch64 variant specific options
+ifeq (n, $(DPDK_TARGET_GENERIC))
+
CPU_IMP_ARM = 0x41
CPU_IMP_CAVIUM  = 0x43
@@ -113,6 +117,9 @@ $(warning Unknown Cavium CPU)
endif
endif
+# Finish of assigning aarch64 variant specific options
+endif
+
##
# Unknown platform
##
diff --git a/src/cmake/cpu.cmake b/src/cmake/cpu.cmake
index 60cf3b9dc..a1a670b23 100644
--- a/src/cmake/cpu.cmake
+++ b/src/cmake/cpu.cmake
@@ -33,9 +33,12 @@ elseif(CMAKE_SYSTEM_PROCESSOR MATCHES 
"^(aarch64.*|AARCH64.*)")
   set(CPU_PART ${value})
 endif()
   endforeach()
+  if(CMAKE_TARGET_GENERIC)
+message(STATUS "Generic image for all aarch64 variant - cache line size 
detection disabled")
+set(VPP_LOG2_CACHE_LINE_SIZE 6)
   # Implementer 0x43 - Cavium
   #  Part 0x0af - ThunderX2 is 64B, rest all are 128B
-  if (${CPU_IMPLEMENTER} STREQUAL "0x43")
+  elseif (${CPU_IMPLEMENTER} STREQUAL "0x43")
 if (${CPU_PART} STREQUAL "0x0af")
   set(VPP_LOG2_CACHE_LINE_SIZE 6)
 else()

Thanks.

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

View/Reply Online (#12508): https://lists.fd.io/g/vpp-dev/message/12508
Mute This Topic: https://lists.fd.io/mt/30416789/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] Build VPP packages on aarch64

2019-03-13 Thread Damjan Marion via Lists.Fd.Io


Dear Lijian,

We use gerrit for code review, so please submit your patch there…

Thanks,

--
Damjan

On 13 Mar 2019, at 16:01, Lijian Zhang (Arm Technology China) 
mailto:lijian.zh...@arm.com>> wrote:

Hi Maintainers,
The current aarch64 version of VPP package distro in cloud repository 
(https://packagecloud.io/fdio/master/ubuntu) is made on a ThunderX server.
During the compilation process, no matter what type of make target is (either 
binaries, e.g, build/build-release, or packages, e.g., pkg-deb, pkg-rpm), it’s 
always using some arch-specific options, e.g., 128Byte cache line size, 
T=arm64-thunderx-linuxapp-gcc, RTE_MACHINE=thunderx, even for the package 
distro to be uploaded into cloud repository.

The aarch64 version of package distro crashed on current CSIT performance 
testing aarch64 servers due to the non-generic compilation options. And that 
non-generic options may also cause performance drop on other aarch64 variants.

So VPP/Aarch64 community has a  suggestion that,
1. for binary type target, e.g., build/build-release, the compilation can use 
arch-specific options
2. for package type target, e.g., pkg-deb/pkg-rpm, the compilation has to  use 
generic options, e.g., 64Byte cache line size, T=arm64-armv8a-linuxapp-gcc, 
RTE_MACHINE=armv8a

Makefile gets to know if it’s binary target or package target by checking if 
there’s a string of ‘package’ in target name.

A draft patch is as below. Appreciate your suggestions.

diff --git a/build-data/packages/external.mk b/build-data/packages/external.mk
index 1ed3f09af..03e902dc1 100644
--- a/build-data/packages/external.mk
+++ b/build-data/packages/external.mk
@@ -42,6 +42,10 @@ endif
DPDK_PLATFORM_TARGET=$(strip $($(PLATFORM)_dpdk_target))
ifneq ($(DPDK_PLATFORM_TARGET),)
DPDK_MAKE_ARGS += DPDK_TARGET=$(DPDK_PLATFORM_TARGET)
+else
+ifneq (,$(findstring package,$(MAKECMDGOALS)))
+DPDK_MAKE_ARGS += DPDK_TARGET_GENERIC=y
+endif
endif
 DPDK_MAKE_EXTRA_ARGS = $(strip $($(PLATFORM)_dpdk_make_extra_args))
diff --git a/build-data/packages/vpp.mk b/build-data/packages/vpp.mk
index 9ce557a99..6c6cb4446 100644
--- a/build-data/packages/vpp.mk
+++ b/build-data/packages/vpp.mk
@@ -31,6 +31,9 @@ vpp_cmake_args += 
-DCMAKE_PREFIX_PATH:PATH="$(vpp_cmake_prefix_path)"
ifeq ("$(V)","1")
vpp_cmake_args += -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
endif
+ifneq (,$(findstring package,$(MAKECMDGOALS)))
+vpp_cmake_args += -DCMAKE_TARGET_GENERIC:BOOL=ON
+endif
 # Use devtoolset on centos 7
ifneq ($(wildcard /opt/rh/devtoolset-7/enable),)
diff --git a/build/external/packages/dpdk.mk b/build/external/packages/dpdk.mk
index 9e10fca1a..1cf2de196 100644
--- a/build/external/packages/dpdk.mk
+++ b/build/external/packages/dpdk.mk
@@ -15,6 +15,7 @@ DPDK_PKTMBUF_HEADROOM?= 128
DPDK_CACHE_LINE_SIZE ?= 64
DPDK_DOWNLOAD_DIR?= $(DL_CACHE_DIR)
DPDK_DEBUG   ?= n
+DPDK_TARGET_GENERIC  ?= n
DPDK_MLX4_PMD?= n
DPDK_MLX5_PMD?= n
DPDK_MLX5_PMD_DLOPEN_DEPS?= n
@@ -69,6 +70,9 @@ DPDK_TARGET   ?= arm64-armv8a-linuxapp-$(DPDK_CC)
DPDK_MACHINE  ?= armv8a
DPDK_TUNE ?= generic
+# Assign aarch64 variant specific options
+ifeq (n, $(DPDK_TARGET_GENERIC))
+
CPU_IMP_ARM = 0x41
CPU_IMP_CAVIUM  = 0x43
@@ -113,6 +117,9 @@ $(warning Unknown Cavium CPU)
endif
endif
+# Finish of assigning aarch64 variant specific options
+endif
+
##
# Unknown platform
##
diff --git a/src/cmake/cpu.cmake b/src/cmake/cpu.cmake
index 60cf3b9dc..a1a670b23 100644
--- a/src/cmake/cpu.cmake
+++ b/src/cmake/cpu.cmake
@@ -33,9 +33,12 @@ elseif(CMAKE_SYSTEM_PROCESSOR MATCHES 
"^(aarch64.*|AARCH64.*)")
   set(CPU_PART ${value})
 endif()
   endforeach()
+  if(CMAKE_TARGET_GENERIC)
+message(STATUS "Generic image for all aarch64 variant - cache line size 
detection disabled")
+set(VPP_LOG2_CACHE_LINE_SIZE 6)
   # Implementer 0x43 - Cavium
   #  Part 0x0af - ThunderX2 is 64B, rest all are 128B
-  if (${CPU_IMPLEMENTER} STREQUAL "0x43")
+  elseif (${CPU_IMPLEMENTER} STREQUAL "0x43")
 if (${CPU_PART} STREQUAL "0x0af")
   set(VPP_LOG2_CACHE_LINE_SIZE 6)
 else()

Thanks.

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

View/Reply Online (#12509): https://lists.fd.io/g/vpp-dev/message/12509
Mute This Topic: https://lists.fd.io/mt/30416789/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] Build VPP packages on aarch64

2019-03-13 Thread Lijian Zhang

Yes, Damjan, will submit the patch to gerrit for public review, after finishing 
internal review inside VPP/Aarch64.
This email is just to get the idea from community beforehand.
Thanks.

From: Damjan Marion (damarion) 
Sent: Wednesday, March 13, 2019 11:04 PM
To: Lijian Zhang (Arm Technology China) 
Cc: vpp-dev@lists.fd.io; nd 
Subject: Re: Build VPP packages on aarch64

Dear Lijian,

We use gerrit for code review, so please submit your patch there…

Thanks,

--
Damjan

On 13 Mar 2019, at 16:01, Lijian Zhang (Arm Technology China) 
mailto:lijian.zh...@arm.com>> wrote:

Hi Maintainers,
The current aarch64 version of VPP package distro in cloud repository 
(https://packagecloud.io/fdio/master/ubuntu) is made on a ThunderX server.
During the compilation process, no matter what type of make target is (either 
binaries, e.g, build/build-release, or packages, e.g., pkg-deb, pkg-rpm), it’s 
always using some arch-specific options, e.g., 128Byte cache line size, 
T=arm64-thunderx-linuxapp-gcc, RTE_MACHINE=thunderx, even for the package 
distro to be uploaded into cloud repository.

The aarch64 version of package distro crashed on current CSIT performance 
testing aarch64 servers due to the non-generic compilation options. And that 
non-generic options may also cause performance drop on other aarch64 variants.

So VPP/Aarch64 community has a  suggestion that,
1. for binary type target, e.g., build/build-release, the compilation can use 
arch-specific options
2. for package type target, e.g., pkg-deb/pkg-rpm, the compilation has to  use 
generic options, e.g., 64Byte cache line size, T=arm64-armv8a-linuxapp-gcc, 
RTE_MACHINE=armv8a

Makefile gets to know if it’s binary target or package target by checking if 
there’s a string of ‘package’ in target name.

A draft patch is as below. Appreciate your suggestions.

diff --git a/build-data/packages/external.mk b/build-data/packages/external.mk
index 1ed3f09af..03e902dc1 100644
--- a/build-data/packages/external.mk
+++ b/build-data/packages/external.mk
@@ -42,6 +42,10 @@ endif
DPDK_PLATFORM_TARGET=$(strip $($(PLATFORM)_dpdk_target))
ifneq ($(DPDK_PLATFORM_TARGET),)
DPDK_MAKE_ARGS += DPDK_TARGET=$(DPDK_PLATFORM_TARGET)
+else
+ifneq (,$(findstring package,$(MAKECMDGOALS)))
+DPDK_MAKE_ARGS += DPDK_TARGET_GENERIC=y
+endif
endif
 DPDK_MAKE_EXTRA_ARGS = $(strip $($(PLATFORM)_dpdk_make_extra_args))
diff --git a/build-data/packages/vpp.mk b/build-data/packages/vpp.mk
index 9ce557a99..6c6cb4446 100644
--- a/build-data/packages/vpp.mk
+++ b/build-data/packages/vpp.mk
@@ -31,6 +31,9 @@ vpp_cmake_args += 
-DCMAKE_PREFIX_PATH:PATH="$(vpp_cmake_prefix_path)"
ifeq ("$(V)","1")
vpp_cmake_args += -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
endif
+ifneq (,$(findstring package,$(MAKECMDGOALS)))
+vpp_cmake_args += -DCMAKE_TARGET_GENERIC:BOOL=ON
+endif
 # Use devtoolset on centos 7
ifneq ($(wildcard /opt/rh/devtoolset-7/enable),)
diff --git a/build/external/packages/dpdk.mk b/build/external/packages/dpdk.mk
index 9e10fca1a..1cf2de196 100644
--- a/build/external/packages/dpdk.mk
+++ b/build/external/packages/dpdk.mk
@@ -15,6 +15,7 @@ DPDK_PKTMBUF_HEADROOM?= 128
DPDK_CACHE_LINE_SIZE ?= 64
DPDK_DOWNLOAD_DIR?= $(DL_CACHE_DIR)
DPDK_DEBUG   ?= n
+DPDK_TARGET_GENERIC  ?= n
DPDK_MLX4_PMD?= n
DPDK_MLX5_PMD?= n
DPDK_MLX5_PMD_DLOPEN_DEPS?= n
@@ -69,6 +70,9 @@ DPDK_TARGET   ?= arm64-armv8a-linuxapp-$(DPDK_CC)
DPDK_MACHINE  ?= armv8a
DPDK_TUNE ?= generic
+# Assign aarch64 variant specific options
+ifeq (n, $(DPDK_TARGET_GENERIC))
+
CPU_IMP_ARM = 0x41
CPU_IMP_CAVIUM  = 0x43
@@ -113,6 +117,9 @@ $(warning Unknown Cavium CPU)
endif
endif
+# Finish of assigning aarch64 variant specific options
+endif
+
##
# Unknown platform
##
diff --git a/src/cmake/cpu.cmake b/src/cmake/cpu.cmake
index 60cf3b9dc..a1a670b23 100644
--- a/src/cmake/cpu.cmake
+++ b/src/cmake/cpu.cmake
@@ -33,9 +33,12 @@ elseif(CMAKE_SYSTEM_PROCESSOR MATCHES 
"^(aarch64.*|AARCH64.*)")
   set(CPU_PART ${value})
 endif()
   endforeach()
+  if(CMAKE_TARGET_GENERIC)
+message(STATUS "Generic image for all aarch64 variant - cache line size 
detection disabled")
+set(VPP_LOG2_CACHE_LINE_SIZE 6)
   # Implementer 0x43 - Cavium
   #  Part 0x0af - ThunderX2 is 64B, rest all are 128B
-  if (${CPU_IMPLEMENTER} STREQUAL "0x43")
+  elseif (${CPU_IMPLEMENTER} STREQUAL "0x43")
 if (${CPU_PART} STREQUAL "0x0af")
   set(VPP_LOG2_CACHE_LINE_SIZE 6)
 else()

Thanks.

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

View/Reply Online (#12510): https://lists.fd.io/g/vpp-dev/message/12510
Mute This Topic: https://lists.fd.io/mt/30416789/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/un

Re: [vpp-dev] Build VPP packages on aarch64

2019-03-13 Thread Damjan Marion via Lists.Fd.Io



On 13 Mar 2019, at 16:10, Lijian Zhang (Arm Technology China) 
mailto:lijian.zh...@arm.com>> wrote:

Yes, Damjan, will submit the patch to gerrit for public review, after finishing 
internal review inside VPP/Aarch64.

Just for my curiosity, why your “internal” reviewers cannot just use gerrit for 
review.
If you feel that your patch should not be merged yet (as you are awaiting 
feedback), just stick -2 to it.

This email is just to get the idea from community beforehand.
Thanks.

We also use gerrit for getting idea from community beforehand.

--
Damjan


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

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

[vpp-dev] [RFC] net/vdev_netvsc: check for required related drivers

2019-03-13 Thread Stephen Hemminger

The vdev_netvsc virtual driver that is used to do initialization
on Hyper-V/Azure won't work without failsafe and tap device.
If the related devices aren't present, it causes confusing errors
later in initialization when it crafts devargs and attempts to
send them to a device driver that isn't there.

Unfortunately, this is common with VPP where the TAP and FAILSAFE
PMD's are both optional.  The suggestion here is to detect this
in the startup phase earlier.

Alternative would be to use RTE_BUILD_BUG_ON(!defined(...))
but that would break people doing normal VPP build.

Signed-off-by: Stephen Hemminger 
---
 drivers/net/vdev_netvsc/vdev_netvsc.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/net/vdev_netvsc/vdev_netvsc.c 
b/drivers/net/vdev_netvsc/vdev_netvsc.c
index 801f54c96e01..9c262358b5ee 100644
--- a/drivers/net/vdev_netvsc/vdev_netvsc.c
+++ b/drivers/net/vdev_netvsc/vdev_netvsc.c
@@ -812,6 +812,20 @@ vdev_netvsc_scan_callback(__rte_unused void *arg)
struct rte_devargs *devargs;
struct rte_bus *vbus = rte_bus_find_by_name("vdev");
 
+   dev = vbus->find_device(NULL, vdev_netvsc_cmp_rte_device,
+   "net_failsafe");
+   if (!dev) {
+   DRV_LOG(ERR, "failsafe network device not present");
+   return;
+   }
+
+   dev = vbus->find_device(NULL, vdev_netvsc_cmp_rte_device,
+   "net_tap");
+   if (!dev) {
+   DRV_LOG(ERR, "tap network device driver not present");
+   return;
+   }
+
RTE_EAL_DEVARGS_FOREACH("vdev", devargs)
if (!strncmp(devargs->name, VDEV_NETVSC_DRIVER_NAME,
 VDEV_NETVSC_DRIVER_NAME_LEN))
-- 
2.17.1

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

View/Reply Online (#12512): https://lists.fd.io/g/vpp-dev/message/12512
Mute This Topic: https://lists.fd.io/mt/30417005/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] Fragmentation and Reassembly #vnet

2019-03-13 Thread Caffeine Coder via Lists.Fd.Io

 Hi Ole,Thanks for the quick response.
I am setting MTU to 1500 and trying to test larger packets. (by enabling 
reassembly feature on interfaces)It seems to work fine on regular interfaces. 
and On tunnel interfaces packets are getting struck in reassembly saying 
inconsistent UDP/IP lengths.So thought of checking with the community.
Thanks,SamOn Wednesday, March 13, 2019, 1:39:06 AM PDT, Ole Troan 
 wrote:  

 > I am new to VPP and experimenting with it.
> I was able to get Reass/Frag working on regular Interfaces.
>  
> The question i have is does Reassembly and Fragmentation supported on Tunnel 
> interfaces(Both VXLAN/IPSec).
> If supported, is there any config knob i need to enable in addition to 
> enabling feature on those interfaces.
>  
> I am running V18.10. Any inputs will be of great help.

Firstly if you need fragmentation and reassembly you are probably doing 
something wrong. ;-)

Fragmentation is done both for IPv4 and IPv6 in the rewrite node. For IPv6 it 
is only done for locally originated. packets.
Somewhat depending on inner tunnel MTU and outer interface MTU, you can end up 
with inner or outer fragmentation in the tunnel.

Full reassembly is enabled by default only for forus packets (destined to one 
of VPP’s addresses).
It can be enabled in-path as well, but that’s probably not a good idea.
Virtual reassembly is integrated into NAT, MAP, and I’m working on generalising 
that.

None of these are tunnel type specific. (Although some tunnels act as input 
features, or have their own FIB DPO, bypassing the “forus” check).

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

View/Reply Online (#12502): https://lists.fd.io/g/vpp-dev/message/12502
Mute This Topic: https://lists.fd.io/mt/30410981/1743273
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=3816821
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [caffeine.co...@yahoo.com]
-=-=-=-=-=-=-=-=-=-=-=-  
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12513): https://lists.fd.io/g/vpp-dev/message/12513
Mute This Topic: https://lists.fd.io/mt/30410981/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Fragmentation and Reassembly #vnet

2019-03-13 Thread Ole Troan

> I am setting MTU to 1500 and trying to test larger packets. (by enabling 
> reassembly feature on interfaces)
> It seems to work fine on regular interfaces. and On tunnel interfaces packets 
> are getting struck in reassembly saying inconsistent UDP/IP lengths.
> So thought of checking with the community.

OK, please share your exact setup and we can take a look.

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

View/Reply Online (#12514): https://lists.fd.io/g/vpp-dev/message/12514
Mute This Topic: https://lists.fd.io/mt/30410981/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Fragmentation and Reassembly #vnet

2019-03-13 Thread Paul Vinciguerra

Hi Sam,

Would you be willing to create unittests for the scenarios you are testing?

On Wed, Mar 13, 2019 at 1:00 PM Ole Troan  wrote:

> > I am setting MTU to 1500 and trying to test larger packets. (by enabling
> reassembly feature on interfaces)
> > It seems to work fine on regular interfaces. and On tunnel interfaces
> packets are getting struck in reassembly saying inconsistent UDP/IP lengths.
> > So thought of checking with the community.
>
> OK, please share your exact setup and we can take a look.
>
> Cheers,
> Ole-=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#12514): https://lists.fd.io/g/vpp-dev/message/12514
> Mute This Topic: https://lists.fd.io/mt/30410981/1594641
> Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=3512467
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [
> pvi...@vinciconsulting.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12515): https://lists.fd.io/g/vpp-dev/message/12515
Mute This Topic: https://lists.fd.io/mt/30410981/21656
Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VPP plugins development in Go

2019-03-13 Thread OMER AHARONIAN

Hi,

My name is Omer and I'm planning to start using VPP as part of a project
I'm working on. I was trying to find an answer to the following question
but without much success. I was hoping you might have the answer.
VPP provides the I/S for developing custom plugins that can be hooked into
a graph of nodes. I've only seen examples for such plugins written in the C
language and was wondering whether other languages Go, for instance, can
also be used to write such plugins.

Waiting to hear from you,
Omer.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12516): https://lists.fd.io/g/vpp-dev/message/12516
Mute This Topic: https://lists.fd.io/mt/30419605/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 plugins development in Go

2019-03-13 Thread Damjan Marion via Lists.Fd.Io



> On 13 Mar 2019, at 19:42, OMER AHARONIAN  wrote:
> 
> Hi,
> 
> My name is Omer and I'm planning to start using VPP as part of a project I'm 
> working on. I was trying to find an answer to the following question but 
> without much success. I was hoping you might have the answer.
> VPP provides the I/S for developing custom plugins that can be hooked into a 
> graph of nodes. I've only seen examples for such plugins written in the C 
> language and was wondering whether other languages Go, for instance, can also 
> be used to write such plugins.

While not impossible, afaik nobody tried to do such thing before. It will 
likely be easier to learn C than to go that route :)

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

View/Reply Online (#12517): https://lists.fd.io/g/vpp-dev/message/12517
Mute This Topic: https://lists.fd.io/mt/30419605/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 plugins development in Go

2019-03-13 Thread Dave Barach via Lists.Fd.Io

At least in concept, it would be possible to write plugins in languages other 
than C or C++.

With respect to golang...: cgo might just about work, but the last time I 
tested it, it cost around 300 clock cycles to cross the c <---> golang 
boundary. When processing packets at speed, that’s the entire clock cycle 
budget available to process one packet, and then some.

If the go runtime garbage collector decides to run, vpp will surely drop a 
bunch of packets. That’s a non-starter. Let’s stipulate that if you’re close 
personal friends with the unsafe package and you’re willing to write ersatz 
c-code in golang, you might be able to avoid that one. That wouldn’t help 
mitigate the c <---> golang function call tax problem.

Golang is well-suited to the task of building control-plane agents – see the 
Ligato project - but I think you’ll have more fun than you want trying to build 
data plane nodes in any language other than C / C++.

HTH... Dave

From: vpp-dev@lists.fd.io  On Behalf Of OMER AHARONIAN
Sent: Wednesday, March 13, 2019 2:42 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] VPP plugins development in Go

Hi,

My name is Omer and I'm planning to start using VPP as part of a project I'm 
working on. I was trying to find an answer to the following question but 
without much success. I was hoping you might have the answer.
VPP provides the I/S for developing custom plugins that can be hooked into a 
graph of nodes. I've only seen examples for such plugins written in the C 
language and was wondering whether other languages Go, for instance, can also 
be used to write such plugins.

Waiting to hear from you,
Omer.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12518): https://lists.fd.io/g/vpp-dev/message/12518
Mute This Topic: https://lists.fd.io/mt/30419605/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 plugins development in Go

2019-03-13 Thread OMER AHARONIAN

As Go provides both good performance and ease of development, I'd be happy
to use it instead of C. Aren't there any projects out there that do so?

On Wed, Mar 13, 2019, 21:07 Damjan Marion  wrote:

>
>
> > On 13 Mar 2019, at 19:42, OMER AHARONIAN  wrote:
> >
> > Hi,
> >
> > My name is Omer and I'm planning to start using VPP as part of a project
> I'm working on. I was trying to find an answer to the following question
> but without much success. I was hoping you might have the answer.
> > VPP provides the I/S for developing custom plugins that can be hooked
> into a graph of nodes. I've only seen examples for such plugins written in
> the C language and was wondering whether other languages Go, for instance,
> can also be used to write such plugins.
>
> While not impossible, afaik nobody tried to do such thing before. It will
> likely be easier to learn C than to go that route :)
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#12519): https://lists.fd.io/g/vpp-dev/message/12519
Mute This Topic: https://lists.fd.io/mt/30419605/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 plugins development in Go

2019-03-13 Thread Wiles, Keith



> On Mar 13, 2019, at 2:16 PM, OMER AHARONIAN  wrote:
> 
> As Go provides both good performance and ease of development, I'd be happy to 
> use it instead of C. Aren't there any projects out there that do so?
> 
> On Wed, Mar 13, 2019, 21:07 Damjan Marion  wrote:

Here is a Go design using DPDK called NFF-Go 
https://www.dpdk.org/hosted-projects/
Go is fast, but calling ‘C’ code from Go is very expensive as Go needs to do 
some conversion from ‘C’ <-> ‘Go’. The NFF-Go code calls DPDK to process 
packets at a much higher level then just having wrapper routines around every 
DPDK API, this will be the same thing for VPP is my guess.

> 
> 
> > On 13 Mar 2019, at 19:42, OMER AHARONIAN  wrote:
> > 
> > Hi,
> > 
> > My name is Omer and I'm planning to start using VPP as part of a project 
> > I'm working on. I was trying to find an answer to the following question 
> > but without much success. I was hoping you might have the answer.
> > VPP provides the I/S for developing custom plugins that can be hooked into 
> > a graph of nodes. I've only seen examples for such plugins written in the C 
> > language and was wondering whether other languages Go, for instance, can 
> > also be used to write such plugins.
> 
> While not impossible, afaik nobody tried to do such thing before. It will 
> likely be easier to learn C than to go that route :)
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#12519): https://lists.fd.io/g/vpp-dev/message/12519
> Mute This Topic: https://lists.fd.io/mt/30419605/675169
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [keith.wi...@intel.com]
> -=-=-=-=-=-=-=-=-=-=-=-

Regards,
Keith

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

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

[vpp-dev] is sw_interface_dump api bug?

2019-03-13 Thread "Zhou You(Joe Zhou)

Dear VPP developers,


   I used sw_interface_dump api to get sw interface info, but found the result 
is not right following these steps :
 1) create a loop interface with instance 10, ie loop10
 2) create a loop inteerface with instance 1, ie loop1
 3) use sw_interface_dump to get loop1's info, such as 
vpp.api.sw_interface_dum(name_filter_valid=True, name_filter="loop1")
 4) sw_interface_dump return loop10's info instead of loop1


  Then I try to find out the reason from source code, I guess maybe it's the 
wrong use of strcasestr in vl_api_sw_interface_dump_t_handler function, I 
wonder if it was strcasecmp rather than strcasestr.


  I create a patch ,  hope someone can help to review it.


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

View/Reply Online (#12521): https://lists.fd.io/g/vpp-dev/message/12521
Mute This Topic: https://lists.fd.io/mt/30423722/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] is sw_interface_dump api bug?

2019-03-13 Thread "Zhou You(Joe Zhou)

Patch url: https://gerrit.fd.io/r/18273




-- Original --
From:  "Joe Zhou";
Date:  Thu, Mar 14, 2019 10:06 AM
To:  "vpp-dev@lists.fd.io";

Subject:  is sw_interface_dump api bug?



Dear VPP developers,


   I used sw_interface_dump api to get sw interface info, but found the result 
is not right following these steps :
 1) create a loop interface with instance 10, ie loop10
 2) create a loop inteerface with instance 1, ie loop1
 3) use sw_interface_dump to get loop1's info, such as 
vpp.api.sw_interface_dum(name_filter_valid=True, name_filter="loop1")
 4) sw_interface_dump return loop10's info instead of loop1


  Then I try to find out the reason from source code, I guess maybe it's the 
wrong use of strcasestr in vl_api_sw_interface_dump_t_handler function, I 
wonder if it was strcasecmp rather than strcasestr.


  I create a patch ,  hope someone can help to review it.


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

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

[vpp-dev] To support QUIC protocol

2019-03-13 Thread Davi Scofield

Hello,
   Is there any roadmap or suggestion to support QUIC protocol in VPP?
   Thanks！

Davi





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

View/Reply Online (#12523): https://lists.fd.io/g/vpp-dev/message/12523
Mute This Topic: https://lists.fd.io/mt/30423896/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] Fragmentation and Reassembly #vnet

[vpp-dev] vlib_buffer_free_inline with CLIB_HAVE_VEC128 will always free buffers one by one, not via the 4 packets batch fast path

Re: [vpp-dev] vlib_buffer_free_inline with CLIB_HAVE_VEC128 will always free buffers one by one, not via the 4 packets batch fast path

Re: [vpp-dev] Standard VPP functionality for AD4,AD6,AS4,AS6

[vpp-dev] Fragmentation and Reassembly

Re: [vpp-dev] Standard VPP functionality for AD4,AD6,AS4,AS6

[vpp-dev] Build VPP packages on aarch64

Re: [vpp-dev] Build VPP packages on aarch64

Re: [vpp-dev] Build VPP packages on aarch64

Re: [vpp-dev] Build VPP packages on aarch64

[vpp-dev] [RFC] net/vdev_netvsc: check for required related drivers

Re: [vpp-dev] Fragmentation and Reassembly #vnet

Re: [vpp-dev] Fragmentation and Reassembly #vnet

Re: [vpp-dev] Fragmentation and Reassembly #vnet

[vpp-dev] VPP plugins development in Go

Re: [vpp-dev] VPP plugins development in Go

Re: [vpp-dev] VPP plugins development in Go

Re: [vpp-dev] VPP plugins development in Go

Re: [vpp-dev] VPP plugins development in Go

[vpp-dev] is sw_interface_dump api bug?

Re: [vpp-dev] is sw_interface_dump api bug?

[vpp-dev] To support QUIC protocol

22 matches

Site Navigation

Mail list logo

Footer information