Nicholas A. Bellinger <nab <at> daterainc.com> writes: > Hi HCH & Co, > > Here is RFC code for adding target_core_fabric_ops->complete_irq > bypass that allows fabrics to invoke response callbacks directly > from target_complete_cmd() IRQ context. > > It breaks up existing target_complete_ok_work() code into three > pieces: > > - transport_complete_task_attr() > - target_complete_ok_pre() > - target_complete_irq() > > and allows target_complete_irq() be called directly from IRQ context > if no special case se_cmd handling requirements exist. > > The three cases that trigger queue_work() process context are: > > - non GOOD status > - ORDERED task sync > - non NULL se_cmd->transport_complete_callback() > > It also includes converting target_restart_delayed_cmds() to use > llist_head, and checking within transport_complete_task_attr() to > determine if dev_ordered_sync is non zero, ahead of doing the > llist_del_all() -> cmpxchg of outstanding ordered tags. > > This allows loopback LLD code to bypass the extra queue_work, and > invoke it's ->scsi_done() callback directly from IRQ context. > > WDYT..? Sorry Nic but I am not convinced that this approach is a good approach. What I have learned by optimizing target software is that achieving maximum IOPS is only possible by engaging multiple threads in command processing. Achieving minimum latency means avoiding context switches. This means that the decision whether or not to process SCSI command completion in the same context or not could e.g. be based on the queue depth. A possible approach is to let the target driver decide in which context command completion should be executed and to pass that information as a parameter to the LIO core. This is why in SCST the enumeration type "scst_exec_context" exists. This makes me wonder whether we need something similar in LIO ? Bart. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
