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: <Y22IDLhefwvjRnGX@lunn.ch>
Date:   Fri, 11 Nov 2022 00:23:56 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     John Ousterhout <ouster@...stanford.edu>, netdev@...r.kernel.org
Subject: Re: Upstream Homa?

On Thu, Nov 10, 2022 at 01:25:40PM -0800, Stephen Hemminger wrote:
> On Thu, 10 Nov 2022 11:42:35 -0800
> John Ousterhout <ouster@...stanford.edu> wrote:
> 
> > Several people at the netdev conference asked me if I was working to
> > upstream the Homa transport protocol into the kernel. I have assumed
> > that this is premature, given that there is not yet significant usage of
> > Homa, but they encouraged me to start a discussion about upstreaming
> > with the netdev community.
> > 
> > So, I'm sending this message to ask for advice about (a) what state
> > Homa needs to reach before it would be appropriate to upstream it,
> > and, (b) if/when that time is reached, what is the right way to go about it.
> > Homa currently has about 13K lines of code, which I assume is far too
> > large for a single patch set; at the same time, it's hard to envision a
> > manageable first patch set with enough functionality to be useful by itself.
> > 
> > -John-

Hi John

> The usual upstream problem areas are:
>  - coding style

You can get a good feeling about what sort of coding style review
comments you will get by running ./scripts/checkpatch.pl over your
files. You don't need to be completely checkpatch clean, it does get
things wrong sometimes.

Adding to Stephens list.

- You have reinvented something which the kernel already has. You need
  to throw away your version and use the kernel version.

- You have used deprecated things, like /proc, ioctls rather than
  netlink.

- 32 bit kernel problems. Since this is about data center, your code
  might make assumptions about running on a 64 bit machine. Statistics
  tend to be done wrong, unless you are using the correct kernel
  helpers to deal with 64 bit counters on 32 bit machines.

Andrew