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-dev@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-dev@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
Mute This Topic: https://lists.fd.io/mt/32103947/675642
Group Owner: vpp-dev+ow...@lists.fd.io<mailto: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.
/******************************************************************************
* File Name: taptun.c
* Author: å
¬ä¼å·: CloudDeveloper
* Created Time: 2019å¹´02æ23æ¥ ææå
21æ¶28å24ç§
*****************************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <net/if.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <linux/if_tun.h>
int
tun_alloc (char *dev, int flags)
{
assert (dev != NULL);
struct ifreq ifr;
int fd, err;
char *clonedev = "/dev/net/tun";
if ((fd = open (clonedev, O_RDWR)) < 0)
{
return fd;
}
memset (&ifr, 0, sizeof (ifr));
ifr.ifr_flags = flags;
if (*dev != '\0')
{
strncpy (ifr.ifr_name, dev, IFNAMSIZ);
}
if ((err = ioctl (fd, TUNSETIFF, (void *) &ifr)) < 0)
{
close (fd);
return err;
}
// ä¸æ¦è®¾å¤å¼å¯æåï¼ç³»ç»ä¼ç»è®¾å¤åé
ä¸ä¸ªå称ï¼å¯¹äºtun设å¤ï¼ä¸è¬ä¸ºtunXï¼X为ä»0å¼å§çç¼å·ï¼
// 对äºtap设å¤ï¼ä¸è¬ä¸ºtapX
strcpy (dev, ifr.ifr_name);
return fd;
}
int
main ()
{
int tun_fd, nread;
char buffer[4096];
char tun_name[IFNAMSIZ];
tun_name[0] = '\0';
/* Flags: IFF_TUN - TUN device (no Ethernet headers)
* IFF_TAP - TAP device
* IFF_NO_PI - Do not provide packet information
*/
tun_fd = tun_alloc (tun_name, IFF_TUN | IFF_NO_PI);
if (tun_fd < 0)
{
perror ("Allocating interface");
exit (1);
}
printf ("Open tun/tap device: %s for reading...\n", tun_name);
while (1)
{
unsigned char ip[4];
// æ¶å
nread = read (tun_fd, buffer, sizeof (buffer));
if (nread < 0)
{
perror ("Reading from interface");
close (tun_fd);
exit (1);
}
printf ("Read %d bytes from tun/tap device\n", nread);
// ç®å对æ¶å°çå
è°æ¢ä¸ä¸é¡ºåº
memcpy (ip, &buffer[12], 4);
memcpy (&buffer[12], &buffer[16], 4);
memcpy (&buffer[16], ip, 4);
buffer[20] = 0;
*((unsigned short *) &buffer[22]) += 8;
// åå
nread = write (tun_fd, buffer, nread);
printf ("Write %d bytes to tun/tap device, that's %s\n", nread, buffer);
}
return 0;
}
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13330): https://lists.fd.io/g/vpp-dev/message/13330
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]
-=-=-=-=-=-=-=-=-=-=-=-
