On 11/20/24 04:08, Bart Van Assche wrote: > On 11/19/24 12:01 AM, Damien Le Moal wrote: >> Impressive improvements but the changes are rather invasive. Have you tried >> simpler solution like forcing unplugging a zone write plug from the driver once >> a command is passed to the driver and the driver did not reject it ? It seems >> like this would make everything simpler on the block layer side. But I am not >> sure if the performance gains would be the same. > > Hi Damien, > > I'm not sure that the approach of submitting a new zoned write if the > driver did not reject the previous write would result in a simpler > solution. SCSI devices are allowed to respond to any command with a unit > attention instead of processing the command. If a unit attention is > reported, the SCSI core requeues the command. In other words, even with > this approach, proper support for requeued zoned writes in the block > layer is required. Yes, but it would be vastly simpler because you would be guaranteed to having only a single write request per zone being in-flight between the write plug and the device at any time. So the requeue would not need reordering, and likely not need any special code at all. nless I am missing something, this would be simpler, no ? The main question though with such approach is: does it give you the same performance improvements as your current (more invasive) approach ? > Additionally, that approach is not compatible with using .queue_rqs(). > While the SCSI core does not yet support a .queue_rqs() callback, I > think it would be good to have this support in the SCSI core. I do not understand why it is not compatible. What is the problem ? > If we need requeuing support anyway, why to select an approach that > probably will result in lower performance than what has been implemented > in this patch series? I am only trying to see if there is not a simpler approach than what you did. The less changes, the better, right ? -- Damien Le Moal Western Digital Research
