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 (#13331): https://lists.fd.io/g/vpp-dev/message/13331 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] -=-=-=-=-=-=-=-=-=-=-=-
