On Fri, Jan 03, 2020 at 02:28:03PM +0100, Ilya Maximets wrote: > 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). Thanks, I tested it and it works OK if ovs-vsctl open the device with type=internal or type=tap. Because OVS will re-open the /dev/net/tun and get the tap fd. Below is my script: ovs-vsctl -- add-br br0 -- set Bridge br0 datapath_type=netdev ip tuntap add tap0 mode tap tunctl -t tap1 ovs-vsctl add-port br0 tap0 -- set int tap0 type=internal ovs-vsctl add-port br0 tap1 -- set int tap1 type=tap ip netns add ns0 ip netns add ns1 ip link set tap0 netns ns0 ip link set tap1 netns ns1 ip netns exec ns0 ip addr add 10.1.1.1/24 dev tap0 ip netns exec ns1 ip addr add 10.1.1.2/24 dev tap1 ip netns exec ns0 ip link set dev tap0 up ip netns exec ns1 ip link set dev tap1 up ip netns exec ns0 ifconfig ip netns exec ns0 ping 10.1.1.2 Regards, William > > 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
