netdev - Re: [PATCH net-next 08/12] net: homa: create 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: <CAGXJAmwaqMs12YtHMZRN5bbqOor2gVe+cCo=JqduaoXsErCY=w@mail.gmail.com>
Date: Tue, 29 Oct 2024 21:51:02 -0700
From: John Ousterhout <ouster@...stanford.edu>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net-next 08/12] net: homa: create homa_incoming.c

On Tue, Oct 29, 2024 at 6:13 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > +int homa_copy_to_user(struct homa_rpc *rpc)
> > +{
> > +#ifdef __UNIT_TEST__
> > +#define MAX_SKBS 3
> > +#else
> > +#define MAX_SKBS 20
> > +#endif
>
> I see you have dropped most of your unit test code. I would remove
> this all well. I suspect your unit test code is going to result in a
> lot of discussion. So i think you want to remove it all.

Makes sense; will do.

> > +//           tt_record3("Preparing to poll, socket %d, flags 0x%x, pid %d",
> > +//                           hsk->client_port, flags, current->pid);
>
> I also think your tt_record code will be rejected, or at least there
> will be a lot of push back. I expect you will be asked to look at
> tracepoints.

Oops, I have a script that strips out all of the tt_record calls, but
it missed the ones that were commented out. I'll take them out.

BTW, I did some experiments with tracepoints to see if they could
replace timetraces. Unfortunately, the basic latency for a tracepoint
is about 100-200 ns, whereas for tt_record it's about 8-10 ns.
Tracepoints appear to be more flexible than timetracing in some ways,
slightly worse in others, but a 10-20x performance hit is a
showstopper for the kinds of performance analysis I do. I can imagine
people won't want 2 different tracing mechanisms in the kernel, so for
now I plan to keep timetraces in the GitHub repo but leave them out of
what's upstreamed. The downside of this is that it will restrict my
ability to debug problems that occur with the upstreamed version.
Maybe we can revisit this at some point in the future...

One of the issues I face is that acceptable latencies for Homa are
often 10x or more smaller than acceptable latencies elsewhere in the
kernel, so it's hard for Homa to use existing kernel mechanisms
without sacrificing its latency potential.

> > +             UNIT_HOOK("found_rpc");
>
> I would also take all such calls out.

Will do.

-John-