Message-ID: <CAGXJAmwMNfoRK42veVS5uFgr0dVZ2G=jj6bR-kn2xV2v+TGFww@mail.gmail.com>
Date: Sat, 28 Sep 2024 21:53:22 -0700
From: John Ousterhout <ouster@...stanford.edu>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: netdev@...r.kernel.org
Subject: Re: Advice on upstreaming Homa

On Fri, Sep 27, 2024 at 4:51 AM Przemek Kitszel
<przemyslaw.kitszel@...el.com> wrote:
>
> 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 think Homa is already pretty well known to the netdev community:
I've given talks on it at multiple NetDev conferences and there are a
couple of published papers describing both the overall protocol and
the Linux implementation.There is also a Wiki with lots of links to
topics related to Homa
(https://homa-transport.atlassian.net/wiki/spaces/HOMA/overview). Are
you suggesting that Homa needs RFC standardization before uploading?
I'd prefer to wait on standardization so that the protocol can evolve
a bit more based on user experiences.

> 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

There are a couple of Homa GitHub repos, and I suspect you may be
looking at the one that is implemented in user space using DPDK. The
kernel module I'd like to upstream is in this repo:
https://github.com/PlatformLab/HomaModule. This is an in-kernel
implementation that doesn't use DPDK.

> > 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

I would be happy to have Homa reviewed, but is that likely, given its
size? In any case, Homa has pretty extensive unit tests already.

> 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)

I am the original implementor/maintainer of almost all of those 15K lines.

> 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++)

Most of these are already done; the ones that aren't (e.g., reverse
Xmas-tree formatting, which I only recently discovered) will be done
before I submit anything.

Powered by blists - more mailing lists