On 03.01.2020 00:54, William Tu wrote: > On Mon, Dec 23, 2019 at 5:22 PM Yi Yang (杨燚)-云服务集团 <yangy...@inspur.com> > wrote: >> >> William, maybe you don't know that kind of tap interface you're saying only >> can be used for VM, that is why openvswitch has to introduce internal type >> for the case I'm saying.
There is no such thing as "only can be used for VM". QEMU creates usual tap interface and OVS could open it with AF_PACKET/XDP socket as usual. See below. >> >> In OVS DPDK case, if you create the below interface, it is a tap interface. >> >> ovs-vsctl add-port tapX -- set interface type=internal >> >> It won't work if you create tap interface in the below way >> >> Ip tuntap add tapX node tap >> ovs-vsctl add-port br-int tapX >> > Hi Yi, > > I think this is mentioned in Documentation/faq/issues.rst, > see > Q: I created a tap device tap0, configured an IP address on it, and added it > to > a bridge, like this:: > > $ tunctl -t tap0 > $ ip addr add 192.168.0.123/24 dev tap0 > $ ip link set tap0 up > $ ovs-vsctl add-br br0 > $ ovs-vsctl add-port br0 tap0 > > I expected that I could then use this IP address to contact other hosts on the > network, but it doesn't work. Why not? You're doing something really strange here. TUN/TAP interface is a way to communicate between userspace application that creates it and the kernel network stack. In the command sequence above there is no application that actually listens on the other side of this tap0 network interface. And it's effectively in DOWN state and can not be used. 'tunctl' just allows you to create a persistent tap interface that will survive restart of the owning application without loosing ip address and other configuration. $ tunctl -t tap0 $ ip addr add 192.168.0.123/24 dev tap0 $ ip link set tap0 up $ ip link show tap0 5: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000 link/ether 82:51:60:3a:08:e0 brd ff:ff:ff:ff:ff:ff To make it work some application needs to open /dev/net/tun and perform an TUNSETIFF ioctl to open this or create new tap interface. OVS will not do that, it will just open usual AF_PACKET socket that will try to get packets from the DOWN kernel interface (interface type=system by default). Same will happen if you'll try to open it with type=afxdp. OVS will open and configure the tap interface correctly only if you'll provide type=tap. In this case, OVS will open /dev/net/tun and will perform TUNSETIFF ioctl to open persistent or create new tap interface. Retrieved tap_fd will be used for data transmission. After that tap0 will get the carrier and the state will finally become UP. (type=internal is equal to type=tap for userspace datapath). In case of tap interface created by QEMU, OVS is able to open it with usual AF_PACKET/XDP socket just because QEMU is the userspace application that owns it (opens /dev/net/tun and performs TUNSETIFF ioctl). The interface is in UP state as long as QEMU process alive. TAP interface is not a stand-alone entity, it's a pipe between particular userspace application and the kernel network stack. And it will obviously not work if you're connecting to it from the kernel side (via socket) without any application listening from the userspace. Best regards, Ilya Maximets. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev