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

Vasu Dev 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
transport. 

> > 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
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.

	Vasu

> 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