kernel/linux.git/include/target/target_core_base.h, branch v6.19.11

Merge patch series "target: RW/num_cmds stats improvements"

2025-11-03T03:07:27+00:00

Mike Christie says: The following patches were made over Linus tree. They fix/improve the stats used in the main IO path. The first patch fixes an issue where I made some stats u32 when they should have stayed u64. The rest of the patches improve the handling of RW/num_cmds stats to reduce code duplication and improve performance. Link: https://patch.msgid.link/20250917221338.14813-1-michael.christie@oracle.com Signed-off-by: Martin K. Petersen

scsi: target: Move LUN stats to per-CPU

2025-11-03T03:06:12+00:00

The atomic use in the main I/O path is causing perf issues when using higher performance backend devices and multiple queues (more than 10 when using vhost-scsi) like with this fio workload: [global] bs=4K iodepth=128 direct=1 ioengine=libaio group_reporting time_based runtime=120 name=standard-iops rw=randread numjobs=16 cpus_allowed=0-15 To fix this issue, move the LUN stats to per CPU. Note: I forgot to include this patch with the delayed/ordered per CPU tracking and per device/device entry per CPU stats. With this patch you get the full 33% improvements when using fast backends, multiple queues and multiple IO submiters. Signed-off-by: Mike Christie Reviewed-by: Dmitry Bogdanov Link: https://patch.msgid.link/20250917221338.14813-4-michael.christie@oracle.com Signed-off-by: Martin K. Petersen

scsi: target: Fix LUN/device R/W and total command stats

2025-11-03T03:06:11+00:00

In commit 9cf2317b795d ("scsi: target: Move I/O path stats to per CPU") I saw we sometimes use %u and also misread the spec. As a result I thought all the stats were supposed to be 32-bit only. However, for the majority of cases we support currently, the spec specifies u64 bit stats. This patch converts the stats changed in the commit above to u64. Fixes: 9cf2317b795d ("scsi: target: Move I/O path stats to per CPU") Signed-off-by: Mike Christie Reviewed-by: Dmitry Bogdanov Link: https://patch.msgid.link/20250917221338.14813-2-michael.christie@oracle.com Signed-off-by: Martin K. Petersen

scsi: target: Add WRITE_ATOMIC_16 handler

2025-11-03T02:40:02+00:00

Add the core LIO code to process the WRITE_ATOMIC_16 command. Signed-off-by: Mike Christie jpg: fix return code from sbc_check_atomic, reformat Signed-off-by: John Garry Link: https://patch.msgid.link/20251020103820.2917593-5-john.g.garry@oracle.com Signed-off-by: Martin K. Petersen

scsi: target: Add atomic se_device fields

2025-11-03T02:40:01+00:00

Add atomic fields to the se_device and export them in configfs. Initially only target_core_iblock will be supported and we will inherit all the settings from the block layer. Signed-off-by: Mike Christie jpg: Stop being allowed to configure atomic write alignment, Signed-off-by: John Garry Link: https://patch.msgid.link/20251020103820.2917593-3-john.g.garry@oracle.com Signed-off-by: Martin K. Petersen

scsi: target: core: Constify enabled() in struct target_opcode_descriptor

2025-05-21T02:11:03+00:00

Constify the first argument of the enabled() function in struct target_opcode_descriptor. This is the first step in order to constify struct target_opcode_descriptor. Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/4290cf1dbe100c1b1edf2ede5e5aef19b04ee7f2.1747592774.git.christophe.jaillet@wanadoo.fr Signed-off-by: Martin K. Petersen

scsi: target: Move delayed/ordered tracking to per CPU

2025-04-29T01:47:55+00:00

The atomic use from the delayed/ordered tracking is causing perf issues when using higher perf backend devices and multiple queues. This moves the values to a per CPU counter. Combined with the per CPU stats patch, this improves IOPS by up to 33% for 8K IOS when using 4 or more queues from the initiator. Signed-off-by: Mike Christie Link: https://lore.kernel.org/r/20250424032741.16216-3-michael.christie@oracle.com Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen

scsi: target: Move I/O path stats to per CPU

2025-04-29T01:47:55+00:00

The atomic use in the main I/O path is causing perf issues when using higher performance backend devices and multiple queues. This moves the stats to per CPU. Combined with the next patch that moves the non_ordered/delayed_cmd_count to per CPU, IOPS by up to 33% for 8K IOS when using 4 or more queues. Signed-off-by: Mike Christie Link: https://lore.kernel.org/r/20250424032741.16216-2-michael.christie@oracle.com Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen

scsi: target: Allow userspace to request direct submissions

2023-10-13T19:53:58+00:00

This allows userspace to request the fabric drivers do direct submissions if they support it. With the new device file, submit_type, users can write 0 - 2 to control how commands are submitted to the backend: 0 - TARGET_FABRIC_DEFAULT_SUBMIT - LIO will use the fabric's default submission type. This is the default for compat. 1 - TARGET_DIRECT_SUBMIT - LIO will submit the cmd to the backend from the calling context if the fabric the cmd was received on supports it, else it will use the fabric's default type. 2 - TARGET_QUEUE_SUBMIT - LIO will queue the cmd to the LIO submission workqueue which will pass it to the backend. When using an NVMe drive and vhost-scsi with direct submission we see around a 20% improvement in 4K I/Os: fio jobs 1 2 4 8 10 -------------------------------------------------- defer 94K 190K 394K 770K 890K direct 128K 252K 488K 950K - And when using the queueing mode, we now no longer see issues like where the iSCSI tx thread is blocked in the block layer waiting on a tag so it can't respond to a nop or perform I/Os for other LUs. Signed-off-by: Mike Christie Link: https://lore.kernel.org/r/20230928020907.5730-6-michael.christie@oracle.com Signed-off-by: Martin K. Petersen

scsi: target: Have drivers report if they support direct submissions

2023-10-13T19:53:57+00:00

In some cases, like with multiple LUN targets or where the target has to respond to transport level requests from the receiving context it can be better to defer cmd submission to a helper thread. If the backend driver blocks on something like request/tag allocation it can block the entire target submission path and other LUs and transport IO on that session. In other cases like single LUN targets with storage that can support all the commands that the target can queue, then it's best to submit the cmd to the backend from the target's cmd receiving context. Subsequent commits will allow the user to config what they prefer, but drivers like loop can't directly submit because they can be called from a context that can't sleep. And, drivers like vhost-scsi can support direct submission, but need to keep their default behavior of deferring execution to avoid possible regressions where the backend can block. Make the drivers tell LIO core if they support direct submissions and their current default, so we can prevent users from misconfiguring the system and initialize devices correctly. Signed-off-by: Mike Christie Link: https://lore.kernel.org/r/20230928020907.5730-2-michael.christie@oracle.com Signed-off-by: Martin K. Petersen