[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72=g0vw3fPh7ZHckqsdU+XgqHnnvbFPk+7YYmQZ6fYyz6Q@mail.gmail.com>
Date: Fri, 16 Jun 2023 18:01:10 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, kuba@...nel.org, netdev@...r.kernel.org,
rust-for-linux@...r.kernel.org, aliceryhl@...gle.com
Subject: Re: [PATCH 0/5] Rust abstractions for network device drivers
On Fri, Jun 16, 2023 at 4:43 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> I said in another email, i don't want to suggest premature
> optimisation, before profiling is done. But in C, these functions are
> inline for a reason. We don't want the cost of a subroutine call. We
> want the compiler to be able to inline the code, and the optimiser to
> be able to see it and generate the best code it can.
See my reply in v2 to your message where I mentioned some of the
options we are considering [1] -- not sure if you saw it:
> Yeah, other use cases will also need that solved, e.g. Andreas for his
> NVMe work.
>
> We discussed reimplementing performance-critical bits in Rust as you
> suggest, as well as cross-language LTO. We also talked about possible
> alternative approaches like "manual local LTO" for the helpers only
> via feeding their LLVM IR to `rustc`, which may recover most of the
> performance without having to go for full LTO and its associated
> kernel link times.
[1] https://lore.kernel.org/rust-for-linux/CANiq72kyUhvmG6KB32X1vuhNzOOJbs7R1JbK+vnPELX4tG73RA@mail.gmail.com/
Cheers,
Miguel
Powered by blists - more mailing lists