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: <CAEh+42j7jFC1GF_foCanF2H4YZmh-eQ=5RhzH1KEYi=i4oEkFg@mail.gmail.com>
Date:	Tue, 8 Dec 2015 17:13:28 -0800
From:	Jesse Gross <jesse@...nel.org>
To:	Tom Herbert <tom@...bertland.com>
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 4:11 PM, Tom Herbert <tom@...bertland.com> wrote:
> 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
>>>> 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).

There is support for TLVs but only on a per-flow basis. In that case,
TLVs are cheap or at least scale with the amount of metadata that is
in use. I'm planning on implementing support for per-packet TLVs but
since that can't be done completely generically, I need the
registry/draft update that I mentioned before.

In practice, I don't expect the number of options for a single packet
to be particularly large, so the cost of going through the list isn't
high. The main source of variation for TLVs is from new ideas, various
control planes, and differences for control/data/OAM/etc. packets.
--
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