netdev - Re: [PATCH net-next v3 3/3] geneve: Remote Checksum Offload support

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]

Message-ID: <CALx6S37jRCwwZHDSVY6DOY3u9EUkHnQsupFa5zzx-KWk7pE5AA@mail.gmail.com>
Date:	Wed, 16 Dec 2015 08:41:57 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	Jesse Gross <jesse@...nel.org>
Cc:	David Miller <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Kernel Team <kernel-team@...com>
Subject: Re: [PATCH net-next v3 3/3] geneve: Remote Checksum Offload support

On Thu, Dec 10, 2015 at 1:17 PM, Jesse Gross <jesse@...nel.org> wrote:
> On Thu, Dec 10, 2015 at 12:37 PM, Tom Herbert <tom@...bertland.com> wrote:
>> Add support for remote checksum offload in both the normal and GRO
>> paths. netlinks command are used to enable sending of the Remote
>> Checksum Data, and allow processing of it on receive.
>>
>> Signed-off-by: Tom Herbert <tom@...bertland.com>
>
> Tom, can you please split this patch off and mark it as RFC or similar?
>
> I don't have any objections to implementing remote checksum offload
> for Geneve in general but I think that it's pretty clear that the
> format that you are using here is not the direction that the protocol
> is going to evolve. We don't need to fragment the protocol by applying
> this at this time.

The first two patches were accepted, you should have enough to
implement the remote checksum patches in the TLV format so you can
take it from here.

As for direction, I strongly suggest that you define some TLVs,
implement the TLV processing loop, and begin analyzing performance in
both HW and SW ASAP. As mentioned in the Geneve draft:

"The use of a variable length header and options in a protocol often
raises questions about whether it is truly efficiently implementable
in hardware."

I don't see that you've answered the question of rather TLVs can be
even be efficiently implemented in software much less hardware.
Without answering these questions I don't think we can claim the
protocol is viable or provides any benefit over VXLAN.

Tom
--
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