On Thu, May 12, 2016 at 11:18 AM, pravin shelar <pshe...@ovn.org> wrote: > On Tue, May 10, 2016 at 6:31 PM, Jesse Gross <je...@kernel.org> wrote: >> I'm a little bit torn as to whether we should apply your rx checksum >> offload patch in the meantime while we wait for DPDK to offer the new >> API. It looks like we'll have a 10% gain with tunneling in exchange >> for a 1% loss in other situations, so the call obviously depends on >> use case. Pravin, Daniele, others, any opinions? >> > There could be a way around the API issue and avoid the 1% loss. > netdev API could be changed to set packet->mbuf.ol_flags to > (PKT_RX_IP_CKSUM_BAD | PKT_RX_L4_CKSUM_BAD) if the netdev > implementation does not support rx checksum offload. Then there is no > need to check the rx checksum flags in dpif-netdev. And the checksum > can be directly checked in tunneling code where we actually need to. > Is there any issue with this approach?
I think that's probably a little bit cleaner overall though I don't think that it totally eliminates the overhead. Not all DPDK ports will support checksum offload (since the hardware may not do it in theory) so we'll still need to check the port status on each packet to initialize the flags. The other thing that is a little concerning is that there might be conditions where a driver doesn't actually verify the checksum. I guess most of these aren't supported in our tunneling implementation (IP options comes to mind) but it's a little risky. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
