[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
Sat Apr 18 09:30:47 UTC 2009


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.

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.



More information about the devel mailing list