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  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 <>
To:	Tom Herbert <>
Cc:	David Miller <>,
	Linux Netdev List <>
Subject: Re: [PATCH v2 net-next 0/7] net: foo-over-udp (fou)

On Mon, Sep 15, 2014 at 10:15 PM, Tom Herbert <> wrote:
> On Mon, Sep 15, 2014 at 11:08 AM, Or Gerlitz <> wrote:
>> On Mon, Sep 15, 2014 at 6:07 AM, Tom Herbert <> 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?

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists