netdev - Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)

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:	Tue, 16 Sep 2014 16:35:38 +0300
From:	Or Gerlitz <gerlitz.or@...il.com>
To:	Tom Herbert <therbert@...gle.com>
Cc:	David Miller <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)

On Mon, Sep 15, 2014 at 10:15 PM, Tom Herbert <therbert@...gle.com> wrote:
> On Mon, Sep 15, 2014 at 11:08 AM, Or Gerlitz <gerlitz.or@...il.com> wrote:
>> On Mon, Sep 15, 2014 at 6:07 AM, Tom Herbert <therbert@...gle.com> wrote:

>>>   - I really don't expect/want devices to have special support for any
>>>     of this. Generic checksum offload mechanisms (NETIF_HW_CSUM
>>>     and use of CHECKSUM_COMPLETE) should be sufficient. RSS and flow
>>>     steering is provided by commonly implemented UDP hashing. GRO/GSO
>>>     seem fairly comparable with LRO/TSO already.

>> Again, today NICs are advertizing checksum offloads capability in
>> enc_hw_features but aren't capable to compute (say) the TCP checksum
>> of the inner packet regardless of which actual tunneling is used (e.g VXLAN vs
>> GRE), a bit inconsistent?

> I doubt this is true of all NICs! For instance, a NIC that implements
> NETIF_F_HW_CSUM should have no problem computing an encapsulated
> checksums in just about any scenario.

The comment for NETIF_F_HW_CSUM says "Can checksum all the packets" --
so your interpretation is that NICs supporting that will always report
CHECKSUM_COMPLETE, OK. But there are bunch of 10/40Gbs NIC drivers
that don't report the HW_CSUM bit in neither of the ->features and
->hw_enc_features, the system should act in a manner that supports them.

> Both, checksum offload and TSO
> can be supported for arbitrary flavors of UDP encapsulation if NICs
> use protocol agnostic means as opposed to protocol specific means that
> require a lot of parsing the packets themselves. Look at the long
> standing comments in sk_buff about why protocol specific methods like
> CHECKSUM_UNNECESSARY and NETIF_F_IP_CSUM are bad ideas. With the
> emergence of encapsulation these are now *really* bad ideas!

So we go and throw away the HW?

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