> Hello Changheun! > > > I want to discuss using max_xfer_blocks instead of opt_xfer_blocks as > > a optional. For example, device reports opt_xfer_blocks is 512KB and > > 1MB as a max_xfer_blocks too. Currently rw_max is set with 512KB only. > > Because that's what the device asks for. If a device explicitly requests > us to use 512 KB I/Os we should not be sending it 1 MB requests. > > The spec is very clear. It says that if you send a command *larger* than > opt_xfer_blocks, you should expect *slower* performance. That makes > max_xfer_blocks a particularly poor choice for setting the default I/O > size. > > In addition to being slower, max_xfer_blocks could potentially also be > much, much larger than opt_xfer_blocks. I understand your 512 KB vs. 1 > MB example. But if the max_xfer_blocks limit is reported as 1 GB, is > that then the right value to use instead of 512 KB? Probably not. > > If a device does not report an opt_xfer_blocks value that suits your > workload, just override the resulting max_sectors_kb in sysfs. This is > intentionally a soft limit so it can be adjusted by the user without > having to change the kernel. > > -- > Martin K. Petersen Oracle Linux Engineering > I understood what you said. I reviewed meaning of opt_xfer_blocks from SCSI spec again. I think below is what you saw in spec. The OPTIMAL TRANSFER LENGTH field indicates the optimal transfer size in logical blocks for a single command shown in table 197. If a device server receives one of these commands with a transfer size greater than this value, then the device server may incur significant delays in processing the command. If the OPTIMAL TRANSFER LENGTH field is set to zero, then there is no reported optimal transfer size. Thank you for kindly feedback. :) --- Changheun Lee Samsung Electronics
