I can't speak for Lijian, but I ran into this issue on a server with vhost-net 
support:
jlinkes@s27-t13-sut1:~/fdio/csit$ grep VHOST /boot/config-4.15.0-46-generic
CONFIG_VHOST_RING=m
CONFIG_VHOST_NET=m
CONFIG_VHOST_SCSI=m
CONFIG_VHOST_VSOCK=m
CONFIG_VHOST=m
# CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set

Then in my test container (it's also reproducible outside of container):
root@3f230f2af45f:~/download_dir# lsmod | grep vhost
vhost_net              24576  1
vhost                  61440  1 vhost_net
tap                    28672  1 vhost_net

The server is using a standard Ubuntu18.04 distro and I think Lijian is using 
something similar, if not the same.

Juraj

-----Original Message-----
From: Benoit Ganne (bganne) <bga...@cisco.com> 
Sent: Wednesday, June 19, 2019 10:04 AM
To: Lijian Zhang <lijian.zh...@arm.com>; Dave Barach (dbarach) 
<dbar...@cisco.com>; Damjan Marion <dmar...@me.com>
Cc: vpp-dev@lists.fd.io; Juraj Linkeš <juraj.lin...@pantheon.tech>
Subject: RE: [vpp-dev] VPP tap interface issue on Arm servers

VPP TAP code is using virtio rings for datapath (vhost-net), not read/write on 
fd as your code does.
This is for performance reasons, issuing a syscall for every packet is very 
slow.
As mentioned by Damjan, did you check if vhost-net is supported on your kernel?

ben

> -----Original Message-----
> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Lijian 
> Zhang
> Sent: mercredi 19 juin 2019 09:13
> To: Dave Barach (dbarach) <dbar...@cisco.com>; Damjan Marion 
> <dmar...@me.com>
> Cc: vpp-dev@lists.fd.io; Juraj Linkeš <juraj.lin...@pantheon.tech>
> Subject: Re: [vpp-dev] VPP tap interface issue on Arm servers
> 
> Thanks Dave and Damjan for your time investigating this issue.
> 
> We can reproduce the issue on several Arm servers, ThunderX, 
> ThunderX2, Qualcomm, etc.
> 
> 
> 
> On ThunderX2 (Ubuntu 18.04, kernel-4.18.0), I verified tap/tun with 
> attached code and below commands, and seems tap/tun is working on Arm 
> servers, but still there’s the issue with tap interface in VPP.
> 
> We are trying to understand the tap code in VPP.
> 
> 
> 
> Any suggestions on helping root cause the issue are appreciated.
> 
> 
> 
> gcc taptun.c -o taptun
> 
> sudo ./taptun
> 
> 
> 
> sudo ip a add 16.0.10.1/24 dev tun0
> 
> sudo ip link set tun0 up
> 
> ping 16.0.10.2
> 
> 
> 
> Thanks.
> 
> 
> 
> From: Dave Barach (dbarach) <dbar...@cisco.com>
> Sent: 2019年6月18日 23:54
> To: Damjan Marion <dmar...@me.com>
> Cc: Lijian Zhang (Arm Technology China) <lijian.zh...@arm.com>; vpp- 
> d...@lists.fd.io
> Subject: RE: [vpp-dev] VPP tap interface issue on Arm servers
> 
> 
> 
> Ack.
> 
> 
> 
> On the [single remaining] 18.04 LTS ThunderX system – 10.30.51.65 - 
> vpp manages to create the Linux interface, configures its IP address, 
> and creates plausible-looking linux-side routing table entries.
> 
> 
> 
> Clue #1: pinging an IP address on correct subnet from Linux results in 
> zero packets transmitted on the vhost interface.
> 
> 
> 
> This isn’t a vpp problem AFAICT.
> 
> 
> 
> HTH... Dave
> 
> 
> 
> From: Damjan Marion <dmar...@me.com <mailto:dmar...@me.com> >
> Sent: Tuesday, June 18, 2019 11:35 AM
> To: Dave Barach (dbarach) <dbar...@cisco.com 
> <mailto:dbar...@cisco.com> >
> Cc: Lijian Zhang <lijian.zh...@arm.com <mailto:lijian.zh...@arm.com> 
> >; vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] VPP tap interface issue on Arm servers
> 
> 
> 
> 
> 
> 
> 
> Vhost-net kernel module is around for years  so I will not he 
> surprised that it is simply disabled in custom kernel built for mcbin.
> 
> —
> 
> Damjan
> 
> 
> On Jun 18, 2019, at 4:41 PM, Dave Barach via Lists.Fd.Io 
> <dbarach=cisco....@lists.fd.io <mailto:dbarach=cisco....@lists.fd.io> 
> >
> wrote:
> 
>       Dear Lijan,
> 
> 
> 
>       The aarch64 development resources in the LF data center are in need 
> of cleanup. I tried to use fdio-cavium5 @ 10.30.51.66 (Ubuntu1804), 
> but I find that the login credentials have been changed.
> 
> 
> 
>       I finally managed to gain access to fdio-mcbin3 @ 10.30.51.43 
> (Ubuntu1604). It is in fact running Ubuntu 16.04, which is unsupported 
> at this point. The Linux 4.4 kernel can be expected to cause trouble.
> 
> 
> 
>       I had difficulty building a master/latest vpp image due to several 
> warnings not seen elsewhere. Since we validate every patch for 
> aarch64, it’s likely a case of tool chain bit rot. Anyhow, I finally 
> managed to build an image.
> 
> 
> 
>       Here’s what I see:
> 
> 
> 
>       DBGvpp# create tap host-if-name lstack host-ip4-addr 192.168.10.2/24
> 
>       create tap: ioctl(VHOST_NET_SET_BACKEND): Bad address
> 
> 
> 
>       This error comes from virtio_vring_init (...), and seems completely 
> consistent with running over an old kernel, instead of a 4.15 kernel. 
> This may or may not have anything to do with the issue you reported.
> 
> 
> 
>       Unless folks clean up LF data center aarch64 development resources, 
> we won’t be able to help. It’s pretty clear that the issues with the 
> tap/virtio driver are aarch64-specific. Clean up includes making sure 
> that credentials are properly communicated, systems up to date / running e.g.
> Ubuntu 18.04, and master/latest builds without having to hack things.
> 
> 
> 
>       Although it’s possible to build aarch64 vpp images on a Raspberry-Pi 
> – I have one, and I’ve done that – it takes measured-in-hours to build 
> an image. I don’t have that kind of time available.
> 
> 
> 
>       HTH... Dave
> 
> 
> 
> 
> 
>       From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>  <vpp- 
> d...@lists.fd.io <mailto:vpp-dev@lists.fd.io> > On Behalf Of Lijian Zhang
>       Sent: Tuesday, June 18, 2019 1:35 AM
>       To: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
>       Cc: nd <n...@arm.com <mailto:n...@arm.com> >
>       Subject: [vpp-dev] VPP tap interface issue on Arm servers
> 
> 
> 
>       Hi,
> 
>       We tried to create a VPP tap interface, assigned ip address to both 
> VPP and Linux side, and then ping VPP tap interface via host 
> interface, and vice versa.
> 
>       But ping failed on both side.
> 
> 
> 
>       With below ping via VPP tap interface for example, it seems VPP has 
> sent out packets, but there’s no any counter increasing on the 
> interface of host side.
> 
> 
> 
>       Could you please suggest on this issue?
> 
> 
> 
>       DBGvpp# create tap
> 
>       DBGvpp# set int ip address tap0 16.0.10.2/24
> 
>       DBGvpp# set int state tap0 up
> 
> 
> 
>       $ sudo ip a add 16.0.10.1/24 dev tap0
> 
> 
> 
>       DBGvpp# clear interfaces
> 
>       DBGvpp# clear errors
> 
>       DBGvpp# clear runtime
> 
>       DBGvpp# ping 16.0.10.1
> 
> 
> 
>       Statistics: 5 sent, 0 received, 100% packet loss
> 
> 
> 
>       DBGvpp# show runtime
> 
>       Thread 0 vpp_main (lcore 2)
> 
>       Time 88.2, average vectors/node 1.00, last 128 main loops 0.00 per 
> node 0.00
> 
>         vector rates in 0.0000e0, out 5.6688e-2, drop 5.6688e-2, punt
> 0.0000e0
> 
>                    Name                 State         Calls
> Vectors        Suspends         Clocks       Vectors/Call
> 
>       api-rx-from-ring                any wait                 0
> 0               4          8.05e1            0.00
> 
>       dhcp-client-process             any wait                 0
> 0               1          8.00e1            0.00
> 
>       dpdk-process                    any wait                 0
> 0              30          3.45e1            0.00
> 
>       drop                             active                  5
> 5               0          6.30e1            1.00
> 
>       error-drop                       active                  5
> 5               0          7.24e1            1.00
> 
>       fib-walk                        any wait                 0
> 0              44          4.35e1            0.00
> 
>       ikev2-manager-process           any wait                 0
> 0              88          2.78e1            0.00
> 
>       ip-neighbor-scan-process        any wait                 0
> 0               2          6.50e1            0.00
> 
>       ip-route-resolver-process       any wait                 0
> 0               1          8.20e1            0.00
> 
>       ip4-glean                        active                  5
> 5               0          9.50e2            1.00
> 
>       ip4-lookup                       active                  5
> 5               0          1.39e2            1.00
> 
>       ip4-reassembly-expire-walk      any wait                 0
> 0               9          4.09e1            0.00
> 
>       ip6-icmp-neighbor-discovery-ev  any wait                 0
> 0              88          2.46e1            0.00
> 
>       ip6-reassembly-expire-walk      any wait                 0
> 0               9          4.06e1            0.00
> 
>       statseg-collector-process       time wait                0
> 0               9          6.33e1            0.00
> 
>       tap0-output                      active                  5
> 5               0          8.16e1            1.00
> 
>       tap0-tx                          active                  5
> 5               0          7.20e1            1.00
> 
>       unix-cli-stdin                   active                  0
> 0              56          6.18e2            0.00
> 
>       unix-epoll-input                 polling          25126436
> 0               0          3.14e1            0.00
> 
>       ---------------
> 
>       Thread 1 vpp_wk_0 (lcore 6)
> 
>       Time 88.2, average vectors/node 0.00, last 128 main loops 0.00 per 
> node 0.00
> 
>         vector rates in 0.0000e0, out 0.0000e0, drop 0.0000e0, punt
> 0.0000e0
> 
>                    Name                 State         Calls
> Vectors        Suspends         Clocks       Vectors/Call
> 
>       unix-epoll-input                 polling             45817
> 0               0          1.47e1            0.00
> 
>       virtio-input                     polling          46962827
> 0               0          2.96e1            0.00
> 
>       -=-=-=-=-=-=-=-=-=-=-=-
>       Links: You receive all messages sent to this group.
> 
>       View/Reply Online (#13323): https://lists.fd.io/g/vpp-
> dev/message/13323 <https://lists.fd.io/g/vpp-dev/message/13323>
>       Mute This Topic: https://lists.fd.io/mt/32103947/675642
>       Group Owner: vpp-dev+ow...@lists.fd.io
>       Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dmar...@me.com 
> <mailto:dmar...@me.com> ]
>       -=-=-=-=-=-=-=-=-=-=-=-
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose 
> the contents to any other person, use it for any purpose, or store or 
> copy the information in any medium. Thank you.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

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

Reply via email to