netdev - Re: Upstream Homa?

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: <Y29RBxW69CtiML6I@nanopsycho>
Date:   Sat, 12 Nov 2022 08:53:43 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     John Ousterhout <ouster@...stanford.edu>,
        Stephen Hemminger <stephen@...workplumber.org>,
        netdev@...r.kernel.org
Subject: Re: Upstream Homa?

Fri, Nov 11, 2022 at 08:25:44PM CET, andrew@...n.ch wrote:
>On Fri, Nov 11, 2022 at 10:59:58AM -0800, John Ousterhout wrote:
>> The netlink and 32-bit kernel issues are new for me; I've done some digging to
>> learn more, but still have some questions.
>> 
>
>> * Is the intent that netlink replaces *all* uses of /proc and ioctl? Homa
>> currently uses ioctls on sockets for I/O (its APIs aren't sockets-compatible).

Why exactly it isn't sockets-comatible?


>> It looks like switching to netlink would double the number of system calls that
>> have to be invoked, which would be unfortunate given Homa's goal of getting the
>> lowest possible latency. It also looks like netlink might be awkward for
>> dumping large volumes of kernel data to user space (potential for buffer
>> overflow?).

Netlink is slow, you should use it for fast path. It is for
configuration and stats.