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

William Tu u9012063 at gmail.com
Fri Jan 3 17:19:32 UTC 2020


On Fri, Jan 3, 2020 at 5:28 AM Ilya Maximets <i.maximets at ovn.org> 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 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


More information about the dev mailing list