netdev - Re: [net-next 05/19] ixgbe: Add support for UDP-encapsulated tx checksum offload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 2 Sep 2015 15:34:56 -0700
From:	Tom Herbert <tom@...bertland.com>
To:	Or Gerlitz <gerlitz.or@...il.com>
Cc:	"Rustad, Mark D" <mark.d.rustad@...el.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	"nhorman@...hat.com" <nhorman@...hat.com>,
	"sassmann@...hat.com" <sassmann@...hat.com>,
	"jogreene@...hat.com" <jogreene@...hat.com>
Subject: Re: [net-next 05/19] ixgbe: Add support for UDP-encapsulated tx
 checksum offload

On Wed, Sep 2, 2015 at 2:07 PM, Or Gerlitz <gerlitz.or@...il.com> wrote:
> On Wed, Sep 2, 2015 at 8:38 PM, Tom Herbert <tom@...bertland.com> wrote:
>> On Wed, Sep 2, 2015 at 9:46 AM, Rustad, Mark D <mark.d.rustad@...el.com> wrote:
>
>>> Note: NETIF_F_HW_CSUM is a superset of NETIF_F_IP_CSUM + NETIF_F_IPV6_CSUM.
>>> It means that device can fill TCP/UDP-like checksum anywhere in the packets
>>> whatever headers there might be.
>
>>> The device can't do whatever, wherever. There is always a limit to the offset to the inner headers that can be handled, for instance.
>
>> If the device does NETIF_F_HW_CSUM then inner/outer headers are
>> irrelevant at least in the non-GSO case. All the device needs to do is
>> compute the checksum from start and write the answer at the given
>> offset. No protocol awareness needed in the device, no need to parse
>> headers on transmit.
>
> Tom, could you elaborate a little further on the
> semantics/requirements for devices supporting NETIF_F_HW_CSUM,
> specifically, AFAIU this isn't a TX equivalent of supporting checksum
> complete on RX, right? when you say "write the answer at the given
> offset" what non-common answers are you expecting devices to produce?
> how the kernel is hinting to the device on the nature on the expected
> answer beyond the offset?
>
NETIF_F_HW_CSUM indicates that the device/driver is will to implement
CHECKSUM_PARTIAL on out for the general case. CHECKSUM_PARTIAL is
described in skbuff.h as:

The device is required to checksum the packet as seen by hard_start_xmit()
from skb->csum_start up to the end, and to record/write the checksum at
offset skb->csum_start + skb->csum_offset.

For instance, if we want to offload an inner checksum the stack would
set csum_start to the offset of the the inner transport packet and
csum_offset to the relative offset of the checksum field. The stack
takes care of priming the checksum field with the not of pseudo header
if the transport protocol needs that.

Tom


> Or.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html