[Open-FCoE] [RESUBMIT-v2 PATCH] libfc, fcoe: fixed locking issues with lport->lp_mutex around lport->link_status
michaelc at cs.wisc.edu
Tue Apr 21 04:43:33 UTC 2009
Vasu Dev wrote:
>>> 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 :-)
James already asked the zfcp guys in that thread, and they seemed ok
with doing a common solution. But, if those crooked iscsi guys try to
get something in for just iscsi, I will bust them :)
>> 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.
It makes a giant improvement. I am only down about 5%. There is a weird
period during the test startup where it takes a couple seconds to get to
its max throughput. If I just set it to 3 commands there is no delay seen.
More information about the devel