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: <CAGXJAmykXGrd-sQO-Q1TvEwbBwnOZXTcegfh2OxjhAQ8dUH9Yw@mail.gmail.com>
Date: Mon, 4 Nov 2024 15:57:08 -0800
From: John Ousterhout <ouster@...stanford.edu>
To: Przemek Kitszel <przemyslaw.kitszel@...el.com>
Cc: Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 04/12] net: homa: create homa_pool.h and homa_pool.c

On Mon, Nov 4, 2024 at 5:13 AM Przemek Kitszel
<przemyslaw.kitszel@...el.com> wrote:
> >
> > Homa doesn't allocate or free pages for this: the application mmap's a
> > region and passes the virtual address range to Homa. Homa doesn't need
> > to pin the pages. This memory is used in a fashion similar to how a
> > buffer passed to recvmsg would be used, except that Homa maintains
> > access to the region for the lifetime of the associated socket. When
> > the application finishes processing an incoming message, it notifies
> > Homa so that Homa can reuse the message's buffer space for future
> > messages; there's no page allocation or freeing in this process.
>
> nice, and I see the obvious performance gains that this approach yields,
> would it be possible to instead of mmap() from user, they will ask Homa
> to prealloc? That way it will be harder to unmap prematurely, and easier
> to port apps between OSes too.

Can you say a bit more about how your proposal would work? I'm not
familiar enough with Linux internals to know how Homa could populate a
region of address space on behalf of the user.

Having the application mmap the region is pretty clean and simple and
gives the application total control over the type and placement of the
region (it doesn't necessarily even have to be a separate mmapped
region). If the application messes things up by unmapping prematurely,
it won't cause any problems for Homa: this will be detected when Homa
tries to copy info out to the bogus addresses, just as would happen
with a bogus buffer in a traditional approach to buffer management.
And, the mmapping is likely to be done automatically by a user-space
library, so it shouldn't impose additional complexity on the main
application.

-John-

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ