On Wed, Jun 12, 2019 at 10:53:52AM -0700, Gregory Rose wrote:
>> OK. The tap driver is backed by a character device in /dev/net/tun, right?
>> Could I strace ovs-vswitchd and see what it reads, or is there a fast path
>> here in the kernel driver so I wouldn't see it?
> OVS works on the standard Linux kernel network skb (socket buffer). The
> data read from user space by the tun driver will be put into an skb for
> delivery to OVS. The packet would be upcalled to the ovs-vswitchd daemon
> via generic netlink.
>
> http://vger.kernel.org/~davem/skb.html
I think we're talking about different things now.
There's nothing in userspace _writing_ packets to /dev/net/tun here
(except for the return packets from the VM, but let's ignore those for the
time being). The TCP stack generates the packet on the vlan1 tap interface,
which would normally mean that a userspace program could pick it up with a
read() on /dev/net/tun. But you're saying that's not what happens, right?
You intercept the skb and switch it instead, since vlan1 is connected to a
bridge?
My understanding of what happens, then, is:
1. The TCP stack doesn't care to pad the skb when creating it, since that's
the job of the output NIC.
2. openvswitch doesn't care to pad the skb when bridging it, since it only
shuffles packets.
3. When the skb reaches vnet1 (also a tap interface, but this time used in
the traditional sense -- the skb is linearized, written to userspace and
then picked up by qemu using either hostnet or /dev/net/tun), it doesn't
care to pad it, since it just takes in whatever comes from the bridge and
punts it to userspace; ie., it only shuffles packets.
4. qemu reads the packet, and doesn't care to pad it before sending it down
to the VM, since it only shuffles packets.
So everybody in the chain really thinks it's someone else's job?
/* Steinar */
--
Homepage: https://www.sesse.net/
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
