From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Herbert Subject: Re: Checksum offload queries Date: Tue, 8 Dec 2015 08:43:04 -0800 Message-ID: References: <5665A848.9010001@solarflare.com> <5666FF46.6030702@solarflare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: netdev To: Edward Cree Return-path: Received: from mail-ig0-f172.google.com ([209.85.213.172]:38397 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933318AbbLHQnF (ORCPT ); Tue, 8 Dec 2015 11:43:05 -0500 Received: by igbxm8 with SMTP id xm8so21079675igb.1 for ; Tue, 08 Dec 2015 08:43:04 -0800 (PST) In-Reply-To: <5666FF46.6030702@solarflare.com> Sender: netdev-owner@vger.kernel.org List-ID: On Tue, Dec 8, 2015 at 8:03 AM, Edward Cree wrote: > On 07/12/15 17:29, Tom Herbert wrote: >> On Mon, Dec 7, 2015 at 7:39 AM, Edward Cree wrote: >>> 2) Transmit checksums. >> It's analogous to CHECKSUM_COMPLETE, NETIF_F_HW_CSUM works for all >> cases of checksum offload and any combination of protocol layering. > ... until a protocol combination comes along that doesn't allow all but the innermost checksum to be 0. NETIF_F_HW_CSUM is limited to one checksum per packet. So is NETIF_F_IP[V6]_CSUM, again the interface into the driver to offload a checksum is csum_start, csum_offset. Only one checksum can be offloaded at a time. We have no way to tell the driver that there are two checksums in a packet to be offloaded. Good news is that we probably don't need that. Extensible encapsulation protocols can implement Remote Checksum Offload, and this is never an issue on the receive side since CHECKSUM_COMPLETE can be used to validate and arbitrary number of checksums. Tom