On 6/12/2019 11:16 AM, Steinar H. Gunderson wrote:
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 netlin
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?
No, I'm not saying that. I just pointed out that OVS works on Linux
kernel skbs.
You intercept the skb and switch it instead, since vlan1 is connected to a
bridge?
It's not "intercepted", it's sent to us by the device attached to our
OVS bridge and then OVS switches it
because that's what it does.
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.
Yes, switches shuffle packets. By definition.
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?
Ahem... well, I can say it isn't the switches' job. Switches do not fix
the packets sent to them. They should
drop undersized frames, so we will be fixing that and appreciate your
help in pointing out the problem.
Thanks,
- Greg
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
