netdev - Re: Advice on upstreaming 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] [day] [month] [year] [list]

Message-ID: <577c1d8b-1437-4ff2-b3d1-1261c4f73fec@intel.com>
Date: Fri, 27 Sep 2024 13:51:01 +0200
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: John Ousterhout <ouster@...stanford.edu>
CC: <netdev@...r.kernel.org>
Subject: Re: Advice on upstreaming Homa

On 9/27/24 06:54, John Ousterhout wrote:
> I would like to start the process of upstreaming the Homa transport
> protocol, and I'm writing for some advice.

I would start with a RFC mail stating what Homa is, what it will be used
for in kernel, what are the users, etc.

I saw your github readmes on current OOT module and previous one on DPDK
plugin. Netdev community will certainly ask how it is connected to DPDK,
and how it could be used with assumed value of 0 for DPDK (IOW upstream
does not care about DPDK).

describe what userspace is needed/how existing one is affected

> 
> Homa contains about 15 Klines of code. I have heard conflicting
> suggestions about how much to break it up for the upstreaming process,
> ranging from "just do it all in one patch set" to "it will need to be
> chopped up into chunks of a few hundred lines". The all-at-once
> approach is certainly easiest for me, and if it's broken up, the
> upstreamed code won't be functional until a significant fraction of it
> has been upstreamed. What's the recommended approach here?

the split up into patches is to have it easiest to review, test
incrementally, and so on

if you will have the whole split ready, it's good to link to it,
but you are limited to 15 patches at a time

> 
> I'm still pretty much a newbie when it comes to submitting Linux code.
> Is there anyone with more experience who would be willing to act as my
> guide? This would involve answering occasional questions and pointing
> me to online information that I might otherwise miss, in order to
> minimize the number of stupid things that I do.
> 
> I am happy to serve as maintainer for the code once it is uploaded. Is
> it a prerequisite for there to be at least 2 maintainers?

are you with contact with the original implementers/maintainers of those
15K lines? one thing that needs to be done is proper authorship, and
author is the best first candidate for a maintainer (though they could
be simply unwilling/not working in the topic anymore)

1 maintainer is not a blocker

> 
> Any other thoughts and suggestions are also welcome.

no "inline" functions in .c,
reverse X-mass tree formatting rule
no space after a (cast *)
use a page_pool
avoid variable length arrays
write whole thing in C (or rust, no C++)

> 
> -John-
>