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.
> 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
