Hannes Reinecke wrote:
> Hannes Reinecke wrote:
>> Hi Mike,
>> finally I've managed to track down the lost TTT issue.
>> We're continuing to get responses from the target
>> even after we have send the TMF PDU (no surprise there).
>> However, the target considers all R2Ts send _before_
>> the tmf response is sent as valid, requiring us
>> to finish off the R2T sequence by sending a Data-Out
>> PDU even _after_ we have received the TMF response.
>> So I've implemented a (rather hackish) 'flush data out'
>> function, which flushes all outstanding Data out
>> PDUs for a given LUN. Using this things are much
>> better to the point that the 'dropped R2T' messages
>> disappeared.
> Well, I've been to fast. I'm having a rather unfavourable
> (non-)interaction between the xmit thread and the recv
> side; as the recv side runs effectively asynchronous
> to the xmit thread there is a change that wealready
> received the R2T PDU but haven't had a chance to
> process it as it's waiting on the session spinlock.
> Maybe it's an idea to have a per-task spinlock to
> ease the lock contention on the per-session spinlock.
And, incidentally, what is the reason for
first setting the SUSPEND bit in iscsi_suspend_tx
and _then_ flush the workqueue?
Surely this will just empty the workqueue without
any real work done here (as the xmit thread will
be short-circuited anyway).
As we have to flush in the sense of actually
_transmitting_ outstanding requests this looks
(and, in fact, proves) to be rather detrimental


Dr. Hannes Reinecke                   zSeries & Storage
h...@suse.de                          +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at http://groups.google.com/group/open-iscsi

Reply via email to