netdev - Re: [RFC PATCH v2 00/21] netgpu: networking between NIC and GPU/CPU.

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] [day] [month] [year] [list]

Date:   Tue, 28 Jul 2020 13:43:40 -0700
From:   "Jonathan Lemon" <jonathan.lemon@...il.com>
To:     "Stephen Hemminger" <stephen@...workplumber.org>
Cc:     netdev@...r.kernel.org, kernel-team@...com
Subject: Re: [RFC PATCH v2 00/21] netgpu: networking between NIC and GPU/CPU.

On 28 Jul 2020, at 12:55, Stephen Hemminger wrote:

> On Mon, 27 Jul 2020 15:44:23 -0700
> Jonathan Lemon <jonathan.lemon@...il.com> wrote:
>
>> Current limitations:
>>   - mlx5 only, header splitting is at a fixed offset.
>>   - currently only TCP protocol delivery is performed.
>>   - TX completion notification is planned, but not in this patchset.
>>   - not compatible with xsk (re-uses same datastructures)
>>   - not compatible with bpf payload inspection
>
> This a good summary of why TCP Offload is not a mainstream solution.
> Look back in archives and you will find lots of presentations about
> why TOE sucks.

I.. agree with this?  But I'm failing to see what TCP offload
(or any HW offload) has to do with the change.  I'm trying to do
the opposite of HW offload here - keeping the protocol in the kernel.
Although obviously what I'm doing is not suitable for all use cases.

>
> You also forgot no VRF, no namespaes, no firewall, no containers, no 
> encapsulation.
> It acts as proof that if you cut out everything you can build 
> something faster.
> But not suitable for upstream or production.
-- 
Jonathan