On Thu, May 12, 2016 at 6:38 PM, Daniele Di Proietto <diproiet...@ovn.org> wrote: > > > 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 was afraid of that. I guess we do not have option but to set the flag dpif-netdev. > 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
