Re: [PATCH RFC] drivers/rufs: add Rust UFS host controller driver

[Andreas Hindborg <a.hindborg@kernel.org>]

Bart Van Assche <bvanassche@acm.org> writes:

> On 9/11/26 8:52 AM, Jaemyung Lee via B4 Relay wrote:
>> Add a Rust UFS host controller driver that exposes UFS logical units as
>> native blk-mq block devices without depending on the SCSI midlayer.
>
> One of the goals in the Linux kernel is *not* to duplicate code.
> Decoupling the UFS driver from the SCSI mid-layer implies duplicating
> the functionality of the SCSI mid-layer. I do not agree with this.

As I answered Greg, the SCSI specific part of this driver is less than
300 lines of code. The driver is 10k lines. That is not really
duplication to be worried about.

>> The driver is written in Rust.
>
> Most UFS driver contributors are not familiar with Rust so I think the
> choice of Rust will make this driver unpopular.

What an excellent opportunity for those developers to get familiar with
Rust in a domain they are already experts in :)

[cut]

>> On Intel UFS 2.1 hardware, 4 KiB direct io_uring at QD32/job gave
>> these optimized-mode ranges over 1/2/4 jobs (three samples):
>> 
>>    Workload  Op     RUFS kIOPS   C kIOPS      Difference
>>    --------  -----  -----------  -----------  ---------------
>>    randread  read   48.91-61.26  41.56-41.60  +17.6% to +47.4%
>>    randwrite write  8.19-8.30    8.21-8.22    -0.4% to +1.1%
>>    randrw    read   5.26-5.34    5.28-5.38    -0.9% to -0.4%
>>    randrw    write  5.27-5.34    5.29-5.37    -0.8% to -0.5%
>
> "Intel UFS 2.1" sounds weird to me since Intel never produced any UFS
> devices as far as I know. Did you perhaps want to write "Intel UFSHCI
> 2.1"? If so, these measurements are not representative since UFSHCI
> 2.1 does not support MCQ. Measurement results for legacy (SDB) mode
> are highly sensitive to whether or not the I/O submitter runs on the
> same CPU core as the completion interrupt.

Of course PCIe attached Intel UFSHCI 2.1. As you probably know, this
target is more simple to bring up due to less platform knobs to turn.

We will provide measurements on recent MCQ based hardware, as soon as
possible. We elected to start the conversation sooner rather than later.


Best regards,
Andreas Hindborg