diff options
author | 2024-05-30 17:25:07 +0300 | |
---|---|---|
committer | 2024-05-30 20:34:38 -0400 | |
commit | 9ec54934ce857065e38523a2010e20182e76f515 (patch) | |
tree | c2895352ebdb62596722f0aaaf7f8a84027a88bb /rust/helpers/build_bug.c | |
parent | Linux 6.10-rc1 (diff) | |
download | wireguard-linux-9ec54934ce857065e38523a2010e20182e76f515.tar.xz wireguard-linux-9ec54934ce857065e38523a2010e20182e76f515.zip |
scsi: ufs: core: Allow RTT negotiation
The rtt-upiu packets precede any data-out upiu packets, thus synchronizing
the data input to the device: this mostly applies to write operations, but
there are other operations that requires rtt as well.
There are several rules binding this rtt - data-out dialog, specifically
There can be at most outstanding bMaxNumOfRTT such packets. This might
have an effect on write performance (sequential write in particular), as
each data-out upiu must wait for its rtt sibling.
UFSHCI expects bMaxNumOfRTT to be min(bDeviceRTTCap, NORTT). However, as of
today, there does not appears to be no-one who sets it: not the host
controller nor the driver. It wasn't an issue up to now: bMaxNumOfRTT is
set to 2 after manufacturing, and wasn't limiting the write performance.
UFS4.0, and specifically gear 5 changes this, and requires the device to be
more attentive. This doesn't come free - the device has to allocate more
resources to that end, but the sequential write performance improvement is
significant. Early measurements shows 25% gain when moving from rtt 2 to
9. Therefore, set bMaxNumOfRTT to be min(bDeviceRTTCap, NORTT) as UFSHCI
expects.
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Link: https://lore.kernel.org/r/20240530142510.734-2-avri.altman@wdc.com
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'rust/helpers/build_bug.c')
0 files changed, 0 insertions, 0 deletions