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

[Ilya Maximets]

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.

Best regards, Ilya Maximets.