On Aug 27, 2011, at 6:59 AM, Jesse Gross wrote: > What I'm thinking about is what happens when we actually implement > this optimization, assuming that the userspace/kernel interface is > locked down. When userspace stops disabling LRO, these checks will > start triggering and will drop packets. To support this we'll have to > remove or relax those checks, which is fine because we're just > implementing a feature that was previously unsupported. However, in > order to use this feature userspace will need to detect whether it > exists, which in this case means some kind of kernel version check > because there's nothing directly visible from userspace. > > To avoid the above mess, I thought that maybe we should just implement > the kernel portion of this since it's fairly simple and then the > problem just goes away. The easiest way to do that is just drop the > checks but they actually are somewhat useful for debugging > configuration problems. The MTU check is really only useful in the > netdev case because that's where we hit real devices with MTUs and is > the place where LRO is actually a problem. The optimization that I > have in mind is useful for internal devices (which have an MTU but > don't care) and it's already a no-op for OVS virtual devices like > tunnels and patch ports because they don't have MTUs at all. That's > why I think that pushing the check into the netdev vport code only > solves the problem.
Thanks for the explanation. Makes sense to me now. > The patch is basically what I had in mind, though you can now remove > the test for no MTU and I would also drop the packet and record the > error if skb_warn_if_lro() triggers (it returns a bool). Great. I'll make those changes tomorrow and resend the entire series. --Justin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
