On Fri, Jan 3, 2020 at 5:28 AM Ilya Maximets <i.maxim...@ovn.org> 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). > > 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. > Thanks Ilya! Lots of people get confused when using tap device and internal. It's very clear with you explanation! Do you want to consider adding these text to Documentation/faq/issues.rst?
William _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
