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

James Smart James.Smart at Emulex.Com
Mon Apr 20 14:48:56 UTC 2009



Mike Christie wrote:
> Vasu Dev wrote:
>   
>> Mike, 
>>
>> 	You have hinted some very good pointers to get queue_depth issue fixed
>> in fcoe and this will be very helpful Thanks. I couldn't spend much time
>> on this and will be looking into this to fix fcoe for now until some
>> common scsi-ml solution is available for all LLD to use. I noticed
>>     
>
> If you are talking about fixes for the queue depth rampup/down, then you 
> should make a common scsi-ml solution.
>
>   
>> similar discussion started on linux-scsi mail list but doesn't seem any
>> common solution will be available any time soon as indicated in that
>>     
>
>   I was thinking the opposite. I think people are going to start raising 
> a stink if driver writers try to put this in their drivers. And it 
> sounded like the zfcp guys were interested in working on it, and I think 
> they are normally good about those type of things.
>
>
>   
>> discussion that same thing was discussed 2 years ago, therefore will go
>> with fcoe solution for now, going for a common alog for all FC devices
>>     
>
> It should not be common for just FC drivers. It should be common for all 
> scsi drivers.
>
>   
>> 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 :)  This goes back to what JamesS 
> was talking about when he gave us the review comment to do this during 
> the libfc reivew, right? We said if we can defer it until after the 
> merge we would work on a common solution after we are merged.
>
> If you are going to spend time on this for fcoe, you should instead work 
> with the zfcp guys on a common solution. Fixing it in only one driver is 
> not the right solution.
>   
Agree completely.  This *should not be fixed only in fcoe*.  If you are 
to spend any time on it at all, it should be on the generic midlayer 
implementation - especially as we have yourselves and the zfcp folks in 
immediate need of it.

-- james s
> You are going to have to look at qla2xxx and lpfc to check out their 
> code right? The implementations are probably not that much different. It 
> should not be that difficult to get something that works for everyone 
> that is at least as good as what they have now initially.
>
> If you do not have time, let me know. I will work on it when I am done 
> with some iscsi work stuff next week. Do not waste time coding something 
> that only works for fcoe.
>
>
> 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.
>
> All the can_queue and queue_depth ramp up/down code will not always 
> prevent us from hitting this problem. We should find the root issue 
> here, and also do the queue_depth rampup/down stuff.
> _______________________________________________
> devel mailing list
> devel at open-fcoe.org
> http://www.open-fcoe.org/mailman/listinfo/devel
>
>   



More information about the devel mailing list