Is there any reason not to use time as an indicator that pending R2Ts need to be processed? Could R2Ts be tagged with a timestamp when received and only given priority over new commands if the age of the R2T at the head exceeds some configurable limit? This would guarantee R2T will eventually be serviced even if the block layer doesn't reduce the submission rate of new commands, it wouldn't remove the performance benefits of the current algorithm which gives priority to new commands and it would be a relatively simple solution. A threshold of 0 could indicate that R2Ts should always be given priority over new commands. Just a thought.. Regards, Adam On Wed, Jun 15, 2022 at 11:37 AM Mike Christie <michael.christie@xxxxxxxxxx> wrote: > > On 6/7/22 8:19 AM, Dmitry Bogdanov wrote: > > In function iscsi_data_xmit (TX worker) there is walking through the > > queue of new SCSI commands that is replenished in parallell. And only > > after that queue got emptied the function will start sending pending > > DataOut PDUs. That lead to DataOut timer time out on target side and > > to connection reinstatment. > > > > This patch swaps walking through the new commands queue and the pending > > DataOut queue. To make a preference to ongoing commands over new ones. > > > > Reviewed-by: Konstantin Shelekhin <k.shelekhin@xxxxxxxxx> > > Signed-off-by: Dmitry Bogdanov <d.bogdanov@xxxxxxxxx> > > Let's do this patch. I've tried so many combos of implementations and > they all have different perf gains or losses with different workloads. > I've already been going back and forth with myself for over a year > (the link for my patch in the other mail was version N) and I don't > think a common solution is going to happen. > > You patch fixes the bug, and I've found a workaround for my issue > where I tweak the queue depth, so I think we will be ok. > > Reviewed-by: Mike Christie <michael.christie@xxxxxxxxxx> > > -- > You received this message because you are subscribed to the Google Groups "open-iscsi" group. > To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@xxxxxxxxxxxxxxxx. > To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/237bed01-819a-55be-5163-274fac3b61e6%40oracle.com. -- "Things turn out best for the people who make the best out of the way things turn out." - Art Linkletter
