[Open-FCoE] [RESUBMIT-v2 PATCH] libfc, fcoe: fixed locking issues with lport->lp_mutex around lport->link_status
michaelc at cs.wisc.edu
Sat Apr 18 09:30:47 UTC 2009
Vasu Dev wrote:
> 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
> 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