[Open-FCoE] [RESUBMIT-v2 PATCH] libfc, fcoe: fixed locking issues with lport->lp_mutex around lport->link_status
vasu.dev at linux.intel.com
Tue Apr 21 02:27:43 UTC 2009
On Sat, 2009-04-18 at 04:30 -0500, 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.
I had intent to get there but first wanted to fix fcoe for this.
> > 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.
I was thinking of each transport might have unique needs therefore
suggested transport class as common place for this kind of logic, some
speculation here since so far I worked with only fcoe as scsi
> > 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 :-)
> 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 won't be able to get to this for next five or may be six weeks, I'll
be glad to work for common scsi-ml solution for this with you all.
> 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.
No more drop due to returning scsi-ml host busy with these patches
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.
> 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