[ovs-dev] [PATCH RFC] WIP: netdev-tpacket: Add AF_PACKET v3 support.

William Tu u9012063 at gmail.com
Fri Jan 3 18:36:02 UTC 2020

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 (杨燚)-云服务集团 <yangyi01 at 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 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 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 dev tap0
ip netns exec ns1 ip addr add 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


> 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.

More information about the dev mailing list