Re: [vpp-dev] dpdk-20.02 compile error for Intel atom

[Benoit Ganne (bganne) via lists.fd.io]

Hi,

This is a dpdk issue, not a VPP issue. However, it looks like your target does 
not support SSE4.1 which seems to be needed by librte_acl.

ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of
> mythosmonkeyk...@163.com
> Sent: lundi 13 avril 2020 11:52
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] dpdk-20.02 compile error for Intel atom
> 
> 
> --
> hi all,
> I've added two files, content is as follows:
> 
> mk/machine/atom/rte. Vars. Mk
> 
> 
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2010-2014 Intel Corporation
> 
> #
> # machine:
> #
> #   - can define ARCH variable (overridden by cmdline value)
> #   - can define CROSS variable (overridden by cmdline value)
> #   - define MACHINE_CFLAGS variable (overridden by cmdline value)
> #   - define MACHINE_LDFLAGS variable (overridden by cmdline value)
> #   - define MACHINE_ASFLAGS variable (overridden by cmdline value)
> #   - can define CPU_CFLAGS variable (overridden by cmdline value) that
> # overrides the one defined in arch.
> #   - can define CPU_LDFLAGS variable (overridden by cmdline value) that
> # overrides the one defined in arch.
> #   - can define CPU_ASFLAGS variable (overridden by cmdline value) that
> # overrides the one defined in arch.
> #   - may override any previously defined variable
> #
> 
> # ARCH =
> # CROSS =
> # MACHINE_CFLAGS =
> # MACHINE_LDFLAGS =
> # MACHINE_ASFLAGS =
> # CPU_CFLAGS =
> # CPU_LDFLAGS =
> # CPU_ASFLAGS =
> 
> MACHINE_CFLAGS = -march=atom
> 
> # On FreeBSD systems, sometimes the correct CPU type is not picked up.
> # To get everything to compile, we need SSE4.2 support, so check if that
> is
> # reported by compiler. If not, check if the CPU actually supports it, and
> if
> # so, set the compilation target to be a corei7, minimum target with
> SSE4.2.
> SSE42_SUPPORT=$(shell $(CC) -march=native -dM -E -  SSE4_2)
> ifeq ($(SSE42_SUPPORT),)
> MACHINE_CFLAGS = -march=corei7
> endif
> 
> config/defconfig_x86_64-atom-linuxapp-gcc:
> 
> 
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2010-2014 Intel Corporation
> 
> #include "common_linux"
> 
> CONFIG_RTE_MACHINE="atom"
> 
> CONFIG_RTE_ARCH="x86_64"
> CONFIG_RTE_ARCH_X86_64=y
> CONFIG_RTE_ARCH_X86=y
> CONFIG_RTE_ARCH_64=y
> 
> CONFIG_RTE_TOOLCHAIN="gcc"
> CONFIG_RTE_TOOLCHAIN_GCC=y
> 
> However, I ran into the following problems while compiling:
> make config T=x86_64-atom-linux-gcc
> make V=1
> 
> The error message is as follows:
> 
> gcc -Wp,-MD,./.acl_run_sse.o.d.tmp  -m64 -pthread -I/home/wangj/code/dpdk-
> 20.02/lib/librte_eal/linux/eal/include  -march=atom -
> DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2 -
> DRTE_MACHINE_CPUFLAG_SSE3 -DRTE_MACHINE_CPUFLAG_SSSE3  -
> I/home/wangj/code/dpdk-20.02/build/include -DRTE_USE_FUNCTION_VERSIONING -
> include /home/wangj/code/dpdk-20.02/build/include/rte_config.h -
> D_GNU_SOURCE -O3 -W -Wall -Wstrict-prototypes -Wmissing-prototypes -
> Wmissing-declarations -Wold-style-definition -Wpointer-arith -Wcast-align
> -Wnested-externs -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef
> -Wwrite-strings -Wdeprecated -Wno-missing-field-initializers -Wno-address-
> of-packed-member -I/home/wangj/code/dpdk-20.02/lib/librte_acl-o
> acl_run_sse.o -c /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.c
> In file included from /home/wangj/code/dpdk-
> 20.02/lib/librte_acl/acl_run_sse.c:5:0:
> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h: In function
> ‘resolve_priority_sse’:
> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h:84:4: warning:
> implicit declaration of function ‘_mm_blendv_epi8’ [-Wimplicit-function-
> declaration]
> results = _mm_blendv_epi8(results, results1, selector);
> ^
> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h:84:4: warning:
> nested extern declaration of ‘_mm_blendv_epi8’ [-Wnested-externs]
> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h:84:12: error:
> incompatible types when assigning to type ‘xmm_t’ from type ‘int’
> results = _mm_blendv_epi8(results, results1, selector);
> ^
> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h:85:13: error:
> incompatible types when assigning to type ‘xmm_t’ from type ‘int’
> priority = _mm_blendv_epi8(priority, priority1,
>  ^
> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h: In function
> ‘acl_match_check_x4’:
> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h:136:2: warning:
> implicit declaration of function ‘_mm_testz_si128’ [-Wimplicit-function-
> declaration]
>   while (!_mm_testz_si128(temp, temp)) {
>   ^
> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h:136:2: warning:
> nested extern declaration of ‘_mm_testz_si128’ [-Wnested-externs]
> In file included from /home/wangj/code/dpdk-
> 20.02/lib/librte_acl/acl_run_sse.h:6:0,
>  from /home/wangj/code/dpdk-
> 20.02/lib/librte_acl/acl_run_sse.c:5:
> /home/wangj/code/dpdk-20.02/lib/librte_a

Re: [vpp-dev] dpdk-20.02 compile error for Intel atom

[Damjan Marion via lists.fd.io]

+1, -march=atom is bad, you likely have newer ATOM CPU, so consider using 
-march={silvermont,goldmont,goldmont-plus}.

What exact CPU are you targeting?


— 
Damjan

> On 14 Apr 2020, at 12:13, Benoit Ganne (bganne) via lists.fd.io 
>  wrote:
> 
> Hi,
> 
> This is a dpdk issue, not a VPP issue. However, it looks like your target 
> does not support SSE4.1 which seems to be needed by librte_acl.
> 
> ben
> 
>> -Original Message-
>> From: vpp-dev@lists.fd.io  > > On Behalf Of
>> mythosmonkeyk...@163.com 
>> Sent: lundi 13 avril 2020 11:52
>> To: vpp-dev@lists.fd.io 
>> Subject: [vpp-dev] dpdk-20.02 compile error for Intel atom
>> 
>> 
>> --
>> hi all,
>>I've added two files, content is as follows:
>> 
>> mk/machine/atom/rte. Vars. Mk
>> 
>> 
>> # SPDX-License-Identifier: BSD-3-Clause
>> # Copyright(c) 2010-2014 Intel Corporation
>> 
>> #
>> # machine:
>> #
>> #   - can define ARCH variable (overridden by cmdline value)
>> #   - can define CROSS variable (overridden by cmdline value)
>> #   - define MACHINE_CFLAGS variable (overridden by cmdline value)
>> #   - define MACHINE_LDFLAGS variable (overridden by cmdline value)
>> #   - define MACHINE_ASFLAGS variable (overridden by cmdline value)
>> #   - can define CPU_CFLAGS variable (overridden by cmdline value) that
>> # overrides the one defined in arch.
>> #   - can define CPU_LDFLAGS variable (overridden by cmdline value) that
>> # overrides the one defined in arch.
>> #   - can define CPU_ASFLAGS variable (overridden by cmdline value) that
>> # overrides the one defined in arch.
>> #   - may override any previously defined variable
>> #
>> 
>> # ARCH =
>> # CROSS =
>> # MACHINE_CFLAGS =
>> # MACHINE_LDFLAGS =
>> # MACHINE_ASFLAGS =
>> # CPU_CFLAGS =
>> # CPU_LDFLAGS =
>> # CPU_ASFLAGS =
>> 
>> MACHINE_CFLAGS = -march=atom
>> 
>> # On FreeBSD systems, sometimes the correct CPU type is not picked up.
>> # To get everything to compile, we need SSE4.2 support, so check if that
>> is
>> # reported by compiler. If not, check if the CPU actually supports it, and
>> if
>> # so, set the compilation target to be a corei7, minimum target with
>> SSE4.2.
>> SSE42_SUPPORT=$(shell $(CC) -march=native -dM -E - > SSE4_2)
>> ifeq ($(SSE42_SUPPORT),)
>>MACHINE_CFLAGS = -march=corei7
>> endif
>> 
>> config/defconfig_x86_64-atom-linuxapp-gcc:
>> 
>> 
>> # SPDX-License-Identifier: BSD-3-Clause
>> # Copyright(c) 2010-2014 Intel Corporation
>> 
>> #include "common_linux"
>> 
>> CONFIG_RTE_MACHINE="atom"
>> 
>> CONFIG_RTE_ARCH="x86_64"
>> CONFIG_RTE_ARCH_X86_64=y
>> CONFIG_RTE_ARCH_X86=y
>> CONFIG_RTE_ARCH_64=y
>> 
>> CONFIG_RTE_TOOLCHAIN="gcc"
>> CONFIG_RTE_TOOLCHAIN_GCC=y
>> 
>> However, I ran into the following problems while compiling:
>> make config T=x86_64-atom-linux-gcc
>> make V=1
>> 
>> The error message is as follows:
>> 
>> gcc -Wp,-MD,./.acl_run_sse.o.d.tmp  -m64 -pthread -I/home/wangj/code/dpdk-
>> 20.02/lib/librte_eal/linux/eal/include  -march=atom -
>> DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2 -
>> DRTE_MACHINE_CPUFLAG_SSE3 -DRTE_MACHINE_CPUFLAG_SSSE3  -
>> I/home/wangj/code/dpdk-20.02/build/include -DRTE_USE_FUNCTION_VERSIONING -
>> include /home/wangj/code/dpdk-20.02/build/include/rte_config.h -
>> D_GNU_SOURCE -O3 -W -Wall -Wstrict-prototypes -Wmissing-prototypes -
>> Wmissing-declarations -Wold-style-definition -Wpointer-arith -Wcast-align
>> -Wnested-externs -Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef
>> -Wwrite-strings -Wdeprecated -Wno-missing-field-initializers -Wno-address-
>> of-packed-member -I/home/wangj/code/dpdk-20.02/lib/librte_acl-o
>> acl_run_sse.o -c /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.c
>> In file included from /home/wangj/code/dpdk-
>> 20.02/lib/librte_acl/acl_run_sse.c:5:0:
>> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h: In function
>> ‘resolve_priority_sse’:
>> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h:84:4: warning:
>> implicit declaration of function ‘_mm_blendv_epi8’ [-Wimplicit-function-
>> declaration]
>>results = _mm_blendv_epi8(results, results1, selector);
>>^
>> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h:84:4: warning:
>> nested extern declaration of ‘_mm_blendv_epi8’ [-Wnested-externs]
>> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h:84:12: error:
>> incompatible types when assigning to type ‘xmm_t’ from type ‘int’
>>results = _mm_blendv_epi8(results, results1, selector);
>>^
>> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h:85:13: error:
>> incompatible types when assigning to type ‘xmm_t’ from type ‘int’
>>priority = _mm_blendv_epi8(priority, priority1,
>> ^
>> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h: In function
>> ‘acl_match_check_x4’:
>> /home/wangj/code/dpdk-20.02/lib/librte_acl/acl_run_sse.h:136:2: warning:
>> imp

[vpp-dev] Unknown input `tap connect` #vpp

[mauricio.solisjr via lists.fd.io]

Hi,
I am trying to connect a tap interface to a vpp using "tap connect tap0" 
command.  I am receive an "Unknown input" error whenever I attempt it.

Am I missing a plugin? I'm on CentOS7 running vpp v20.01 and the following are 
my plugins.

abf_plugin.so gbp_plugin.so  mactime_plugin.so  
sctp_plugin.so

acl_plugin.so gtpu_plugin.so map_plugin.so  
srv6ad_plugin.so

avf_plugin.so hs_apps_plugin.so  mdata_plugin.so    
srv6am_plugin.so

builtinurl_plugin.so  http_static_plugin.so  memif_plugin.so    
srv6as_plugin.so

cdp_plugin.so igmp_plugin.so nat_plugin.so  
srv6mobile_plugin.so

crypto_ia32_plugin.so ikev2_plugin.so    nsh_plugin.so  
stn_plugin.so

crypto_ipsecmb_plugin.so  ila_plugin.so  nsim_plugin.so 
svs_plugin.so

crypto_openssl_plugin.so  ioam_plugin.so oddbuf_plugin.so   
tlsmbedtls_plugin.so

ct6_plugin.so ixge_plugin.so perfmon_plugin.so  
tlsopenssl_plugin.so

dhcp_plugin.so    l2e_plugin.so  ping_plugin.so 
tlspicotls_plugin.so

dns_plugin.so l3xc_plugin.so pppoe_plugin.so    
unittest_plugin.so

dpdk_plugin.so    lacp_plugin.so quic_plugin.so 
vmxnet3_plugin.so

flowprobe_plugin.so   lb_plugin.so   rdma_plugin.so

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

View/Reply Online (#16063): https://lists.fd.io/g/vpp-dev/message/16063
Mute This Topic: https://lists.fd.io/mt/73007641/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&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] #vat How can I use vpp_api_test via socket file

[wei_sky2008]

Hello,

I am trying to connect VPP by vpp_vat_socket via socket file.

However I am not able to connect to VPP via vpp_api_test over the socket file.

Is this expected behavior? How to connect to vpp via vpp_api_test over custom 
socket file?

Thank you.

My startup.conf

unix

{

cli-listen /run/vpp/cli-vpp1.sock

log /tmp/vpe.log
nodaemon

}

api-segment

{

prefix vpp1

}

cpu

{

corelist-workers 2

main-core 1

}

dpdk

{

dev :03:00.0

}

socksvr {

socket-name /run/vpp/api_1.sock

}

I use cmd connect vppvpp_api_test socket-name /run/vpp/api_1.sock chroot 
prefix vpp1
But it can't work,why?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16064): https://lists.fd.io/g/vpp-dev/message/16064
Mute This Topic: https://lists.fd.io/mt/73008683/21656
Mute #vat: https://lists.fd.io/mk?hashtag=vat&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] exporting plugin functions/symbols to global space

[Satya Murthy]

Hi,

I remember seeing some questions regarding this in fdio mailing list, but not 
able to find it now.

We have a plugin which has 10 functions that are needed by 3 other plugins ( 
which are owned by us ).
As of now, we are doing vlib_get_plugin_symbol() and getting the symbols.

But , I remember there is a way each plugin can export the functions to global 
space, so that other plugins dont need to do dlsym and get it directly from 
global symbol table.
Is there any framework /macros in VPP to export all or specific symbols to 
global level from a plugin, so that all the other plugins can access it without 
doing dlsym.

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

View/Reply Online (#16065): https://lists.fd.io/g/vpp-dev/message/16065
Mute This Topic: https://lists.fd.io/mt/73008778/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] exporting plugin functions/symbols to global space

[Dave Barach via lists.fd.io]

As a matter of discipline, you’d be better off to continue binding symbols 
explicitly. Otherwise, what you end up with amounts to one plugin split into 
pieces.

As things stand, if someone misconfigures the set of loaded plugins it ought to 
be obvious what happened. (“Where is the foo plugin?”).

Using the global symbol table creates implicit plugin load-order dependencies 
which are not helpful. We currently load plugins via dlopen (... RTLD_LAZY). 
Imagine what would happen if that changed to dlopen (... RTLD_NOW).

FWIW... D.

From: vpp-dev@lists.fd.io  On Behalf Of Satya Murthy
Sent: Tuesday, April 14, 2020 8:14 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] exporting plugin functions/symbols to global space

Hi,

I remember seeing some questions regarding this in fdio mailing list, but not 
able to find it now.

We have a plugin which has 10 functions that are needed by 3 other plugins ( 
which are owned by us ).
As of now, we are doing vlib_get_plugin_symbol() and getting the symbols.

But , I remember there is a way each plugin can export the functions to global 
space, so that other plugins dont need to do dlsym and get it directly from 
global symbol table.
Is there any framework /macros in VPP to export all or specific symbols to 
global level from a plugin, so that all the other plugins can access it without 
doing dlsym.

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

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

[vpp-dev] #vat how to use VPP and vpp_api_test in K8s 's POD

[wei_sky2008]

In our project, we want to use VPP for external communication in pod
In this pod, I want to use two containers to allow VPP and vpp_api_test 
respectively ，
VPP is used to process messages received by pod from dpdk bound network 
card，and vpp_api_test is used to configure VPP when messages are received by 
other services of the same k8s cluster
but vpp_api_test only can use shm or sock file to cfg vpp, I try modify vpp 
container startup.conf
statseg {
socket-name /volumeshare/api_1.sock
}
in vpp container ./vpp_api_test socket-name /volumeshare/api_1.sock
it can work
but vpp_ai_test container , it can not work:
clib_socket_init: connect (fd 3, '/volumeshare/api_1.sock'): Protocol wrong 
type for socket
WARNING: socket connection failed

These two containers belong to the same pod. And in the pod yaml , I mount 
/volumeshare/ directory for these two containers.

how can I do?
Thanks
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16067): https://lists.fd.io/g/vpp-dev/message/16067
Mute This Topic: https://lists.fd.io/mt/73009185/21656
Mute #vat: https://lists.fd.io/mk?hashtag=vat&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] VPP checksum behavior problems

[Sun, Chenmin]

Hi Florin,
But what I saw in current master branch is, the bad checksum packets are all 
dropped in ip4-local node. See log below:

00:06:42:511858: dpdk-input
  1/2 rx queue 0
  buffer 0xfe57e2: current data 0, length 124, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x100
   ext-hdr-valid
  PKT MBUF: port 1, nb_segs 1, pkt_len 124
buf_len 2176, data_len 124, ol_flags 0x8a, data_off 128, phys_addr 
0xbf95f900
packet_type 0x191 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x5bf78172 fdir.hi 0x0 fdir.lo 0x5bf78172
Packet Offload Flags
  PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
  PKT_RX_L4_CKSUM_BAD (0x0008) L4 cksum of RX pkt. is not OK
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
extension headers
  RTE_PTYPE_L4_TCP (0x0100) TCP packet
  IP4: 00:00:01:00:24:00 -> 00:00:00:00:01:01
  TCP: 66.66.66.6 -> 66.66.66.66
tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
fragment id 0x
  TCP: 111 -> 222
seq. 0x0201 ack 0x0200
flags 0x00, tcp header: 20 bytes
window 0, checksum 0xf6b5
00:06:42:512116: ethernet-input
  frame: flags 0x3, hw-if-index 2, sw-if-index 2
  IP4: 00:00:01:00:24:00 -> 00:00:00:00:01:01
00:06:42:512143: ip4-input-no-checksum
  TCP: 66.66.66.6 -> 66.66.66.66
tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
fragment id 0x
  TCP: 111 -> 222
seq. 0x0201 ack 0x0200
flags 0x00, tcp header: 20 bytes
window 0, checksum 0xf6b5
00:06:42:512175: ip4-lookup
  fib 0 dpo-idx 8 flow hash: 0x
  TCP: 66.66.66.6 -> 66.66.66.66
tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
fragment id 0x
  TCP: 111 -> 222
seq. 0x0201 ack 0x0200
flags 0x00, tcp header: 20 bytes
window 0, checksum 0xf6b5
00:06:42:512217: ip4-local
TCP: 66.66.66.6 -> 66.66.66.66
  tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
  fragment id 0x
TCP: 111 -> 222
  seq. 0x0201 ack 0x0200
  flags 0x00, tcp header: 20 bytes
  window 0, checksum 0xf6b5
00:06:42:512280: ip4-drop
TCP: 66.66.66.6 -> 66.66.66.66
  tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
  fragment id 0x
TCP: 111 -> 222
  seq. 0x0201 ack 0x0200
  flags 0x00, tcp header: 20 bytes
  window 0, checksum 0xf6b5
00:06:42:512308: error-drop
  rx:1/2
00:06:42:512323: drop
  ip4-local: bad tcp checksum


Best Regards,
Sun, Chenmin

From: Florin Coras 
Sent: Tuesday, April 14, 2020 12:04 AM
To: Sun, Chenmin 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VPP checksum behavior problems

Hi Chenmin,

Regarding your second question, some of the device drivers could mark buffers 
for tx csum offload which is honored only if data is about to be delivered to 
the network (or if some other action performed to the buffer requires csums to 
be computed). Otherwise, if packets end up consumed locally, e.g., tunnel or 
host stack termination, the data is assumed to be correct and no checksum is 
computed.

So, for instance, if udp/tcp packets received from a tap interface are 
terminated locally, we don’t try to compute/validate checksum, since there’s 
nothing to validate as the checksum has not yet been filled in.

Regards,
Florin

On Apr 13, 2020, at 12:52 AM, Sun, Chenmin 
mailto:chenmin@intel.com>> wrote:

[Edited Message Follows]
Hi experts,

I am confusing about the L4 checksum behavior in VPP. I noticed the code was 
there for a very long time(more than 3 years) so I open this topic to see if 
anybody knows the history and why.


  *   The first problem is in DPDK plugin and was introduced in commit 
d81566ff92: Disable for-us udp/tcp checksum validation by default
in Current DPDK plugin, the code clears flags 
VNET_BUFFER_F_L4_CHECKSUM_COMPUTED and VNET_BUFFER_F_L4_CHECKSUM_CORRECT when 
"enable-tcp-udp-checksum" option is enabled. While these two flags are used to 
identify if the L4 checksum is checked and correct, respectively. So I think 
this is a wrong behavior - are we doing the opposite?
The current DPDK plugin assumes all the packets from DPDK are correct but in 
fact we should check per packet and set the corresponding bits. I've pushed a 
patch to fix this issue and Dave invited experts to help to review - Thanks 
Dave :-)


  *   Another problem in the IP4 graph node. The following mechanism was first 
introduced in commit 96be8e88109b3e1 and got refactored in commit 1b25552eb.

#define ip4_local_csum_is_offloaded(_b) \
_b->flags & VNET_BUFFER_F_OFFLOAD_TCP_CKSUM \
|| _b->flags & VNET_BUFFER_F_OFFLOAD_UDP_CKSUM

#define ip4_local_need_csum_check(is_tcp_udp, _b) \
(is_tcp_udp && !(_b->flags & VNET_BUFFER_F_L4_CHECKSUM_COMPUTED \
|| ip4_local_csum_is_offloaded (_b)))

#defin

[vpp-dev] Macswapplugin compilation failure

[tupai via lists.fd.io]

Hi All,

I was following the Macswap Breakdown YouTube video and downloaded the tarball.

Steps:
tar -zxvf macswap-plugin.tar.gz -C /root/vpp-dev/vpp/devboot
cd /root/vpp-dev/vpp/devboot/macswap-plugin/
autoreconf -i -f
mkdir build
cd build
../configure --with-plugin-toolkit
[root@vpp-dev build]# make
mkdir -p `dirname macswap/macswap.api.h` ; \
gcc  -E -P -C -x c ../macswap/macswap.api \
| vppapigen --input - --output macswap/macswap.api.h --show-name 
macswap/macswap.api.h
/bin/sh: line 2: vppapigen: command not found
make: *** [macswap/macswap.api.h] Error 127
[root@vpp-dev build]#

I looked for vppapigen and it was present. Can someone guide me on where I am 
going wrong?

[root@vpp-dev vpp]# find ./ -name vppapigen
./build-root/build-vpp_debug-native/vpp/tools/vppapigen
./build-root/install-vpp_debug-native/vpp/bin/vppapigen
./src/tools/vppapigen
./src/tools/vppapigen/vppapigen
[root@vpp-dev vpp]#


VPP git hash is :
commit 81767d71a943fcf1196867549a6b48122f259695
Author: neale ranns 
Date:   Thu Apr 9 13:03:45 2020 +

vom: Fixes for g++-9

Type: improvement

Signed-off-by: neale ranns 
Change-Id: I356251b750fcab05ff91e0295e96a8451e8b2f88

OS is:
[root@vpp-dev vpp]# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
[root@vpp-dev vpp]# uname -r
3.10.0-1062.el7.x86_64
[root@vpp-dev vpp]#

Also, make build and make rebuild works fine on the base directory. 
VPP and all it’s other plugins compile fine but macswap plugin is not a part of 
it.

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

View/Reply Online (#16069): https://lists.fd.io/g/vpp-dev/message/16069
Mute This Topic: https://lists.fd.io/mt/73009799/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] Macswapplugin compilation failure

[Damjan Marion via lists.fd.io]

that code seems to be seriously outdated, take sample plugin from the 
src/examples/sample-plugin

https://git.fd.io/vpp/tree/src/examples/sample-plugin 


— 
Damjan

> On 14 Apr 2020, at 15:14, tupai via lists.fd.io 
>  wrote:
> 
> Hi All,
> 
> I was following the Macswap Breakdown YouTube video and downloaded the 
> tarball.
> 
> Steps:
> tar -zxvf macswap-plugin.tar.gz -C /root/vpp-dev/vpp/devboot
> cd /root/vpp-dev/vpp/devboot/macswap-plugin/
> autoreconf -i -f
> mkdir build
> cd build
> ../configure --with-plugin-toolkit
> [root@vpp-dev build]# make
> mkdir -p `dirname macswap/macswap.api.h` ; \
> gcc  -E -P -C -x c ../macswap/macswap.api \
> | vppapigen --input - --output macswap/macswap.api.h --show-name 
> macswap/macswap.api.h
> /bin/sh: line 2: vppapigen: command not found
> make: *** [macswap/macswap.api.h] Error 127
> [root@vpp-dev build]#
> 
> I looked for vppapigen and it was present. Can someone guide me on where I am 
> going wrong?
> 
> [root@vpp-dev vpp]# find ./ -name vppapigen
> ./build-root/build-vpp_debug-native/vpp/tools/vppapigen
> ./build-root/install-vpp_debug-native/vpp/bin/vppapigen
> ./src/tools/vppapigen
> ./src/tools/vppapigen/vppapigen
> [root@vpp-dev vpp]#
> 
> 
> VPP git hash is :
> commit 81767d71a943fcf1196867549a6b48122f259695
> Author: neale ranns mailto:nra...@cisco.com>>
> Date:   Thu Apr 9 13:03:45 2020 +
> 
> vom: Fixes for g++-9
> 
> Type: improvement
> 
> Signed-off-by: neale ranns mailto:nra...@cisco.com>>
> Change-Id: I356251b750fcab05ff91e0295e96a8451e8b2f88
> 
> OS is:
> [root@vpp-dev vpp]# cat /etc/redhat-release
> CentOS Linux release 7.7.1908 (Core)
> [root@vpp-dev vpp]# uname -r
> 3.10.0-1062.el7.x86_64
> [root@vpp-dev vpp]#
> 
> Also, make build and make rebuild works fine on the base directory. 
> VPP and all it’s other plugins compile fine but macswap plugin is not a part 
> of it.
> 
> Regards,
> Surajit
> 

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

View/Reply Online (#16070): https://lists.fd.io/g/vpp-dev/message/16070
Mute This Topic: https://lists.fd.io/mt/73009799/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] #vat How can I use vpp_api_test via socket file

[Dave Barach via lists.fd.io]

Please try https://gerrit.fd.io/r/c/vpp/+/26505. Bit rot.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#16071): https://lists.fd.io/g/vpp-dev/message/16071
Mute This Topic: https://lists.fd.io/mt/73008683/21656
Mute #vat: https://lists.fd.io/mk?hashtag=vat&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] VPP checksum behavior problems

[Florin Coras]

Hi Chenmin, 

If packets are marked as having a bad csum, or marked as needing a csum and 
that turns out to be wrong after ip-local computes it, ip-local should drop 
them. From the trace lower, l4 csum is reported as bad by dpdk. 

So why is this unexpected?

Regards,
Florin

> On Apr 14, 2020, at 6:14 AM, Sun, Chenmin  wrote:
> 
> Hi Florin,
> But what I saw in current master branch is, the bad checksum packets are all 
> dropped in ip4-local node. See log below:
>
> 00:06:42:511858: dpdk-input
>   1/2 rx queue 0
>   buffer 0xfe57e2: current data 0, length 124, buffer-pool 0, ref-count 1, 
> totlen-nifb 0, trace handle 0x100
>ext-hdr-valid 
>   PKT MBUF: port 1, nb_segs 1, pkt_len 124
> buf_len 2176, data_len 124, ol_flags 0x8a, data_off 128, phys_addr 
> 0xbf95f900
> packet_type 0x191 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
> rss 0x5bf78172 fdir.hi 0x0 fdir.lo 0x5bf78172
> Packet Offload Flags
>   PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
>   PKT_RX_L4_CKSUM_BAD (0x0008) L4 cksum of RX pkt. is not OK
>   PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
> Packet Types
>   RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
>   RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
> extension headers
>   RTE_PTYPE_L4_TCP (0x0100) TCP packet
>   IP4: 00:00:01:00:24:00 -> 00:00:00:00:01:01
>   TCP: 66.66.66.6 -> 66.66.66.66
> tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
> fragment id 0x
>   TCP: 111 -> 222
> seq. 0x0201 ack 0x0200
> flags 0x00, tcp header: 20 bytes
> window 0, checksum 0xf6b5
> 00:06:42:512116: ethernet-input
>   frame: flags 0x3, hw-if-index 2, sw-if-index 2
>   IP4: 00:00:01:00:24:00 -> 00:00:00:00:01:01
> 00:06:42:512143: ip4-input-no-checksum
>   TCP: 66.66.66.6 -> 66.66.66.66
> tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
> fragment id 0x
>   TCP: 111 -> 222
> seq. 0x0201 ack 0x0200
> flags 0x00, tcp header: 20 bytes
> window 0, checksum 0xf6b5
> 00:06:42:512175: ip4-lookup
>   fib 0 dpo-idx 8 flow hash: 0x
>   TCP: 66.66.66.6 -> 66.66.66.66
> tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
> fragment id 0x
>   TCP: 111 -> 222
> seq. 0x0201 ack 0x0200
> flags 0x00, tcp header: 20 bytes
> window 0, checksum 0xf6b5
> 00:06:42:512217: ip4-local
> TCP: 66.66.66.6 -> 66.66.66.66
>   tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
>   fragment id 0x
> TCP: 111 -> 222
>   seq. 0x0201 ack 0x0200
>   flags 0x00, tcp header: 20 bytes
>   window 0, checksum 0xf6b5
> 00:06:42:512280: ip4-drop
> TCP: 66.66.66.6 -> 66.66.66.66
>   tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
>   fragment id 0x
> TCP: 111 -> 222
>   seq. 0x0201 ack 0x0200
>   flags 0x00, tcp header: 20 bytes
>   window 0, checksum 0xf6b5
> 00:06:42:512308: error-drop
>   rx:1/2
> 00:06:42:512323: drop
>   ip4-local: bad tcp checksum
>
>
> Best Regards,
> Sun, Chenmin
>
> From: Florin Coras  
> Sent: Tuesday, April 14, 2020 12:04 AM
> To: Sun, Chenmin 
> Cc: vpp-dev 
> Subject: Re: [vpp-dev] VPP checksum behavior problems
>
> Hi Chenmin, 
>
> Regarding your second question, some of the device drivers could mark buffers 
> for tx csum offload which is honored only if data is about to be delivered to 
> the network (or if some other action performed to the buffer requires csums 
> to be computed). Otherwise, if packets end up consumed locally, e.g., tunnel 
> or host stack termination, the data is assumed to be correct and no checksum 
> is computed. 
>
> So, for instance, if udp/tcp packets received from a tap interface are 
> terminated locally, we don’t try to compute/validate checksum, since there’s 
> nothing to validate as the checksum has not yet been filled in. 
>
> Regards, 
> Florin
>
> On Apr 13, 2020, at 12:52 AM, Sun, Chenmin  > wrote:
>
> [Edited Message Follows]
> Hi experts,
>
> I am confusing about the L4 checksum behavior in VPP. I noticed the code was 
> there for a very long time(more than 3 years) so I open this topic to see if 
> anybody knows the history and why.
>
> The first problem is in DPDK plugin and was introduced in commit d81566ff92: 
> Disable for-us udp/tcp checksum validation by default
> in Current DPDK plugin, the code clears flags 
> VNET_BUFFER_F_L4_CHECKSUM_COMPUTED and VNET_BUFFER_F_L4_CHECKSUM_CORRECT when 
> "enable-tcp-udp-checksum" option is enabled. While these two flags are used 
> to identify if the L4 checksum is checked and correct, respectively. So I 
> think this is a wrong behavior - are we doing the opposite?
> The current DPDK plugin assumes all the packets from DPDK are correct but in 
> fact we should check per packet and set the corresponding bits. I've pushed a 

Re: [vpp-dev] Macswapplugin compilation failure

[tupai via lists.fd.io]

Thanks Damjan.
That worked.

However, I think the file src/examples/sample-plugin/sample_plugin_doc.md is 
still outdated.
sample.am file seems to be no longer required.
Looks like CMakeLists.txt takes care of everything.

I will try to update this file once I figure it out.

Regards,
Surajit 

> On 14-Apr-2020, at 6:47 PM, Damjan Marion  wrote:
> 
> 
> that code seems to be seriously outdated, take sample plugin from the 
> src/examples/sample-plugin
> 
> https://git.fd.io/vpp/tree/src/examples/sample-plugin 
> 
> 
> — 
> Damjan
> 
>> On 14 Apr 2020, at 15:14, tupai via lists.fd.io  
>> > > wrote:
>> 
>> Hi All,
>> 
>> I was following the Macswap Breakdown YouTube video and downloaded the 
>> tarball.
>> 
>> Steps:
>> tar -zxvf macswap-plugin.tar.gz -C /root/vpp-dev/vpp/devboot
>> cd /root/vpp-dev/vpp/devboot/macswap-plugin/
>> autoreconf -i -f
>> mkdir build
>> cd build
>> ../configure --with-plugin-toolkit
>> [root@vpp-dev build]# make
>> mkdir -p `dirname macswap/macswap.api.h` ; \
>> gcc  -E -P -C -x c ../macswap/macswap.api \
>> | vppapigen --input - --output macswap/macswap.api.h --show-name 
>> macswap/macswap.api.h
>> /bin/sh: line 2: vppapigen: command not found
>> make: *** [macswap/macswap.api.h] Error 127
>> [root@vpp-dev build]#
>> 
>> I looked for vppapigen and it was present. Can someone guide me on where I 
>> am going wrong?
>> 
>> [root@vpp-dev vpp]# find ./ -name vppapigen
>> ./build-root/build-vpp_debug-native/vpp/tools/vppapigen
>> ./build-root/install-vpp_debug-native/vpp/bin/vppapigen
>> ./src/tools/vppapigen
>> ./src/tools/vppapigen/vppapigen
>> [root@vpp-dev vpp]#
>> 
>> 
>> VPP git hash is :
>> commit 81767d71a943fcf1196867549a6b48122f259695
>> Author: neale ranns mailto:nra...@cisco.com>>
>> Date:   Thu Apr 9 13:03:45 2020 +
>> 
>> vom: Fixes for g++-9
>> 
>> Type: improvement
>> 
>> Signed-off-by: neale ranns mailto:nra...@cisco.com>>
>> Change-Id: I356251b750fcab05ff91e0295e96a8451e8b2f88
>> 
>> OS is:
>> [root@vpp-dev vpp]# cat /etc/redhat-release
>> CentOS Linux release 7.7.1908 (Core)
>> [root@vpp-dev vpp]# uname -r
>> 3.10.0-1062.el7.x86_64
>> [root@vpp-dev vpp]#
>> 
>> Also, make build and make rebuild works fine on the base directory. 
>> VPP and all it’s other plugins compile fine but macswap plugin is not a part 
>> of it.
>> 
>> Regards,
>> Surajit
>> 
> 

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

View/Reply Online (#16073): https://lists.fd.io/g/vpp-dev/message/16073
Mute This Topic: https://lists.fd.io/mt/73009799/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 checksum behavior problems

[Sun, Chenmin]

Hi Florin,

You can ignore the DPDK checksum flag as it won’t be passed to next graph 
nodes(I thought this is a bug and I’ve pushed a patch to fix it, see 
https://gerrit.fd.io/r/c/vpp/+/26480. With my patch the L4 checksum flags that 
come from DPDK rte_mbuf.flags can be passed to VPP vlib_buf.flags so they can 
be used in other graph nodes). In this case it was the software did the TCP 
checksum calculation.
So I think this behavior(checking the checksum flag or doing software validate 
in ip4-local node) is expected. I misunderstand your first email, now I am 
clear with the 2nd question. Thanks for your clarification.

Best Regards,
Sun, Chenmin

From: vpp-dev@lists.fd.io  On Behalf Of Florin Coras
Sent: Tuesday, April 14, 2020 10:24 PM
To: Sun, Chenmin 
Cc: vpp-dev 
Subject: Re: [vpp-dev] VPP checksum behavior problems

Hi Chenmin,

If packets are marked as having a bad csum, or marked as needing a csum and 
that turns out to be wrong after ip-local computes it, ip-local should drop 
them. From the trace lower, l4 csum is reported as bad by dpdk.

So why is this unexpected?

Regards,
Florin


On Apr 14, 2020, at 6:14 AM, Sun, Chenmin 
mailto:chenmin@intel.com>> wrote:

Hi Florin,
But what I saw in current master branch is, the bad checksum packets are all 
dropped in ip4-local node. See log below:

00:06:42:511858: dpdk-input
  1/2 rx queue 0
  buffer 0xfe57e2: current data 0, length 124, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x100
   ext-hdr-valid
  PKT MBUF: port 1, nb_segs 1, pkt_len 124
buf_len 2176, data_len 124, ol_flags 0x8a, data_off 128, phys_addr 
0xbf95f900
packet_type 0x191 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x5bf78172 fdir.hi 0x0 fdir.lo 0x5bf78172
Packet Offload Flags
  PKT_RX_RSS_HASH (0x0002) RX packet with RSS hash result
  PKT_RX_L4_CKSUM_BAD (0x0008) L4 cksum of RX pkt. is not OK
  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
Packet Types
  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
  RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without 
extension headers
  RTE_PTYPE_L4_TCP (0x0100) TCP packet
  IP4: 00:00:01:00:24:00 -> 00:00:00:00:01:01
  TCP: 66.66.66.6 -> 66.66.66.66
tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
fragment id 0x
  TCP: 111 -> 222
seq. 0x0201 ack 0x0200
flags 0x00, tcp header: 20 bytes
window 0, checksum 0xf6b5
00:06:42:512116: ethernet-input
  frame: flags 0x3, hw-if-index 2, sw-if-index 2
  IP4: 00:00:01:00:24:00 -> 00:00:00:00:01:01
00:06:42:512143: ip4-input-no-checksum
  TCP: 66.66.66.6 -> 66.66.66.66
tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
fragment id 0x
  TCP: 111 -> 222
seq. 0x0201 ack 0x0200
flags 0x00, tcp header: 20 bytes
window 0, checksum 0xf6b5
00:06:42:512175: ip4-lookup
  fib 0 dpo-idx 8 flow hash: 0x
  TCP: 66.66.66.6 -> 66.66.66.66
tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
fragment id 0x
  TCP: 111 -> 222
seq. 0x0201 ack 0x0200
flags 0x00, tcp header: 20 bytes
window 0, checksum 0xf6b5
00:06:42:512217: ip4-local
TCP: 66.66.66.6 -> 66.66.66.66
  tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
  fragment id 0x
TCP: 111 -> 222
  seq. 0x0201 ack 0x0200
  flags 0x00, tcp header: 20 bytes
  window 0, checksum 0xf6b5
00:06:42:512280: ip4-drop
TCP: 66.66.66.6 -> 66.66.66.66
  tos 0x00, ttl 64, length 110, checksum 0x71be dscp CS0 ecn NON_ECN
  fragment id 0x
TCP: 111 -> 222
  seq. 0x0201 ack 0x0200
  flags 0x00, tcp header: 20 bytes
  window 0, checksum 0xf6b5
00:06:42:512308: error-drop
  rx:1/2
00:06:42:512323: drop
  ip4-local: bad tcp checksum


Best Regards,
Sun, Chenmin

From: Florin Coras mailto:fcoras.li...@gmail.com>>
Sent: Tuesday, April 14, 2020 12:04 AM
To: Sun, Chenmin mailto:chenmin@intel.com>>
Cc: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: Re: [vpp-dev] VPP checksum behavior problems

Hi Chenmin,

Regarding your second question, some of the device drivers could mark buffers 
for tx csum offload which is honored only if data is about to be delivered to 
the network (or if some other action performed to the buffer requires csums to 
be computed). Otherwise, if packets end up consumed locally, e.g., tunnel or 
host stack termination, the data is assumed to be correct and no checksum is 
computed.

So, for instance, if udp/tcp packets received from a tap interface are 
terminated locally, we don’t try to compute/validate checksum, since there’s 
nothing to validate as the checksum has not yet been filled in.

Regards,
Florin

On Apr 13, 2020, at 12:52 AM, Sun, Chenmin 
mailto:chenmin@intel.com>> wrote:

[Edited Message Follows]
Hi experts,

I am confusing about the L4 checksum behavior in VPP. I noticed the code was 
there for a ve

Re: [vpp-dev] Unknown input `tap connect` #vpp

[steven luong via lists.fd.io]

tapcli has been deprecated few releases ago. It has been replaced by virtio 
over tap. The new cli is

create tap …

Steven

From:  on behalf of "mauricio.solisjr via lists.fd.io" 

Reply-To: "mauricio.soli...@tno.nl" 
Date: Tuesday, April 14, 2020 at 3:55 AM
To: "vpp-dev@lists.fd.io" 
Subject: [vpp-dev] Unknown input `tap connect` #vpp

Hi,
I am trying to connect a tap interface to a vpp using "tap connect tap0" 
command.  I am receive an "Unknown input" error whenever I attempt it.

Am I missing a plugin? I'm on CentOS7 running vpp v20.01 and the following are 
my plugins.

abf_plugin.so gbp_plugin.so  mactime_plugin.so  
sctp_plugin.so

acl_plugin.so gtpu_plugin.so map_plugin.so  
srv6ad_plugin.so

avf_plugin.so hs_apps_plugin.so  mdata_plugin.so
srv6am_plugin.so

builtinurl_plugin.so  http_static_plugin.so  memif_plugin.so
srv6as_plugin.so

cdp_plugin.so igmp_plugin.so nat_plugin.so  
srv6mobile_plugin.so

crypto_ia32_plugin.so ikev2_plugin.sonsh_plugin.so  
stn_plugin.so

crypto_ipsecmb_plugin.so  ila_plugin.so  nsim_plugin.so 
svs_plugin.so

crypto_openssl_plugin.so  ioam_plugin.so oddbuf_plugin.so   
tlsmbedtls_plugin.so

ct6_plugin.so ixge_plugin.so perfmon_plugin.so  
tlsopenssl_plugin.so

dhcp_plugin.sol2e_plugin.so  ping_plugin.so 
tlspicotls_plugin.so

dns_plugin.so l3xc_plugin.so pppoe_plugin.so
unittest_plugin.so

dpdk_plugin.solacp_plugin.so quic_plugin.so 
vmxnet3_plugin.so

flowprobe_plugin.so   lb_plugin.so   rdma_plugin.so

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

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