netdev - Re: [PATCH net-next 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: <CALx6S37o+gQ4BLtphsDzbg-qPsiZo2_7TvhSdweLy8wAEbbjNw@mail.gmail.com>
Date:	Tue, 8 Dec 2015 16:11:56 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	Jesse Gross <jesse@...nel.org>
Cc:	"John W. Linville" <linville@...driver.com>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Jesse Gross <jesse@...ira.com>,
	Kernel Team <kernel-team@...com>
Subject: Re: [PATCH net-next 3/3] geneve: Remote Checksum Offload support

On Tue, Dec 8, 2015 at 3:58 PM, Jesse Gross <jesse@...nel.org> wrote:
> On Tue, Dec 8, 2015 at 11:59 AM, Tom Herbert <tom@...bertland.com> wrote:
>> On Tue, Dec 8, 2015 at 11:31 AM, John W. Linville
>> <linville@...driver.com> wrote:
>>> On Tue, Dec 08, 2015 at 10:27:18AM -0800, Tom Herbert wrote:
>>>> Add support for remote checksum offload in both the normal and GRO
>>>> paths. netlink command are used to enable sending of the Remote
>>>> Checksum Data, and allow processing of it on receive. The Remote
>>>
>> Extraneous.
>>
>>> afsO&^(*&5^a+++NO CARRIER
>>>
>>> Did you mean to finish that sentence? ;-)
>>>
>>>> Signed-off-by: Tom Herbert <tom@...bertland.com>
>>>
>>> Jesse is going to have to comment on your (ab)use of the reserved
>>> fields.  I presume that an RFC would be forthcoming?
>>>
>> I'll spin an I-D once there is agreement on the approach. This is
>> identical to VXLAN excepted the bit flag indicating csum_start is
>> present might be different.
>
> Thanks for doing this - it was also on my to-do list.
>
> We can definitely do better than VXLAN here since there is
> extensibility built into the protocol. I think the right way to do
> this is to define a TLV option and then use the same format as what
> you defined for GUE (and it is also nice to reuse some of the option
> formats to minimize differences across protocols).
>
> I'd like to set up an IANA registry for classes but that's a little
> slow going at this point, so for the next draft update I'm planning on
> adding some initial assignments, including a Linux class. We could
> then allocate remote checksum out of that. The new version of the
> draft should be coming out pretty soon.

I thought about a TLV implementation but there is no base support in
the kernel for it. It would be great if you could implement the TLV
loop. Honestly, though, I'm still very leery of the processing
overhead associated with TLVs in the critical data path. In the worst
case of RCO we would need to fish for the RCO option though the TLV
list in both the GRO and normal path for each packet. If the TLV lists
are long then performance may be negatively affected mitigating the
value of RCO (needs to be measured).
--
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