[Open-FCoE] [RESUBMIT-v2 PATCH] libfc, fcoe: fixed locking issues with lport->lp_mutex around lport->link_status

Mike Christie michaelc at cs.wisc.edu
Tue Apr 21 04:43:33 UTC 2009


Vasu Dev wrote:
>>> could be another option in its FC transport class but lets get this
>>> fixed on fcoe first.
>> That is exactly the wrong approach. If you do this, I will be jerk and 
>> raise a stink about it on the lists :)  
> 
> I hope you will do same for any other LLD, like for zfcp to push for
> common scsi-ml solution first :-) 
> 

James already asked the zfcp guys in that thread, and they seemed ok 
with doing a common solution. But, if those crooked iscsi guys try to 
get something in for just iscsi, I will bust them :)


>> Also there is still some other issue here. If we return scsi-ml host 
>> busy, we should not experience suck a large drop in performance. I 
>> tested some other drivers to try and simulate something similar where if 
>> there were X commands running then I would return host busy. Throughput 
>> was fine. It is just really odd that if we just send IO until we hit the 
>> queue_depth then it is fine, but if we hit the code that returns scsi-ml 
>> host busy we get a perf drop.
>>
> 
> No more drop due to returning scsi-ml host busy with these patches
> http://www.open-fcoe.org/pipermail/devel/2009-April/002253.html, rather
> some improvement.
> 
> Earlier fcoe had large 1 HZ timer, so fcoe pending queue flushed more
> quickly by having more scsi commands/skb than 1 HZ timer as every new
> skb also tries to flush pending skb from queue.
> 

It makes a giant improvement. I am only down about 5%. There is a weird 
period during the test startup where it takes a couple seconds to get to 
its max throughput. If I just set it to 3 commands there is no delay seen.



More information about the devel mailing list