2016-05-12 13:40 GMT-07:00 pravin shelar <pshe...@ovn.org>: > On Thu, May 12, 2016 at 12:59 PM, Jesse Gross <je...@kernel.org> wrote: > > 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. > > > I was thinking of changing dpdk packet object constructor > (ovs_rte_pktmbuf_init()) to initialize the flag according to the > device offload support. This way there should not be any checks needed > in packet receive path. > > It looks like (at least for ixgbe) the flags are reset by the rx routine, even if offloads are disabled.
I don't have a better idea, IMHO losing 1% is not a huge deal Thanks > > 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 > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
