netdev - Re: [PATCH] net: Add ndo_gso

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:	Mon, 29 Sep 2014 13:47:30 -0700
From:	Tom Herbert <therbert@...gle.com>
To:	Jesse Gross <jesse@...ira.com>
Cc:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Or Gerlitz <gerlitz.or@...il.com>
Subject: Re: [PATCH] net: Add ndo_gso_check

On Mon, Sep 29, 2014 at 1:13 PM, Jesse Gross <jesse@...ira.com> wrote:
> On Sun, Sep 28, 2014 at 8:50 PM, Tom Herbert <therbert@...gle.com> wrote:
>> Add ndo_gso_check which a device can define to indicate whether is
>> is capable of doing GSO on a packet. This funciton would be called from
>> the stack to determine whether software GSO is needed to be done. A
>> driver should populate this function if it advertises GSO types for
>> which there are combinations that it wouldn't be able to handle. For
>> instance a device that performs UDP tunneling might only implement
>> support for transparent Ethernet bridging type of inner packets
>> or might have limitations on lengths of inner headers.
>>
>> Signed-off-by: Tom Herbert <therbert@...gle.com>
>
> Offloads that might have limitations extend beyond GSO - checksum is
> another possibility that could need something like a length check.
>
There are several examples of drivers that advertise checksum offload
but then in TX path decide that they can't do it for various reasons--
in this case they need to do software checksum calculation themselves.
Applying this model to GSO, that is drivers do software GSO when they
need to punt on packet, seems pretty hard to me, but maybe someone can
look at it.

> In addition, while I would also like to be optimistic about the
> capabilities of existing NICs it's unlikely that any of them that are
> advertising SKB_GSO_UDP_TUNNEL can actually do it with full
> generality. So unless we can get the driver writers to chime in about
> their capabilities (maybe we can, there's only a handful of them right
> now), we probably need to provide a more conservative implementation
> for those drivers. I guess I would probably do length equal to VXLAN
> and perhaps containing Ethernet as a balance between the most
> conservative and the most optimistic.

Checking header length in ndo_gso_check would be trivial.
--
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