[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXJAmycKLobQxYF6Wm9RLgTFCJkhcW1-4Gzwb1Kzh7RDnt6Zg@mail.gmail.com>
Date: Tue, 29 Oct 2024 21:15:09 -0700
From: John Ousterhout <ouster@...stanford.edu>
To: Andrew Lunn <andrew@...n.ch>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net-next 04/12] net: homa: create homa_pool.h and homa_pool.c
On Tue, Oct 29, 2024 at 5:09 PM Andrew Lunn <andrew@...n.ch> wrote:
> > +static inline void set_bpages_needed(struct homa_pool *pool)
>
> Generally we say no inline functions in .c files, let the compiler
> decide. If you have some micro benchmark indicating the compiler is
> getting it wrong, we will then consider allowing it.
I didn't realize that the compiler will inline automatically; I will
remove "inline" from all of the .c files.
> It would be good if somebody who knows about the page pool took a look
> at this code. Could the page pool be used as a basis?
I think this is a different problem from what page pools solve. Rather
than the application providing a buffer each time it calls recvmsg, it
provides a large region of memory in its virtual address space in
advance; Homa allocates buffer space from that region so that it can
begin copying data to user space before recvmsg is invoked. More
precisely, Homa doesn't know which message will be returned as the
response to a recvmsg until a message actually completes (the first
one to complete will be returned). Before this mechanism was
implemented, Homa couldn't start copying data to user space until the
last packet of the message had been received, which serialized the
copy with network transmission and reduced throughput dramatically. If
I understand page pools correctly, I don't think they would be
beneficial here.
-John-
Powered by blists - more mailing lists