Date: Thu, 14 Oct 1999 00:44:50 +0200 (MET DST) From: Gerard Roudier <groudier@club-internet.fr> To: Randell Jesup <rjesup@wgate.com> Cc: "Justin T. Gibbs" <gibbs@caspian.plutotech.com>, scsi@FreeBSD.ORG Subject: Re: Driver for GDT6517RD RAID controller Message-ID: <Pine.LNX.3.95.991014000724.375A-100000@localhost> In-Reply-To: <ybuu2nvxn2f.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 Oct 1999, Randell Jesup wrote: > "Justin T. Gibbs" <gibbs@caspian.plutotech.com> writes: [ ... ] > >If the accept occurs when all resources are consumed, sure, you know to = return > >busy. But that need not be the case. It could be that you receive the = command > >from the initiator, ship it off to your peripheral driver, and by the ti= me it > >can respond, other peripheral drivers have queued work that will take al= l of > >your resources. >=20 > =09Aha. That makes some more sense. >=20 > > Since FreeBSD-CAM imposes a scheduling for resources, and > >the XPT knows the total number of resources you have, the peripheral dri= ver > >you really want to have a resource doesn't happen to get it. The result= is > >deadlock. To avoid this, the peripheral driver needs to understand that > >it should raise its response to the highest priority level so it is guar= anteed > >to get a resource. >=20 > =09I'll need to look at the FreeBSD-CAM/XPT. None of the driver > designs I've ever done have had any inherent limitations on the number of > active requests (other than physical memory). I wonder if the XPT (or SI= M) > could reserve resources for target-mode driver responses... Part of the > problem is not understanding FreeBSD's XPT's resource-allocation code. I > think I really need to start looking at the code; perhaps this weekend. CAM requires SIM to accept any number of requests from peripheral drivers. There is no status SIM can return on internal resource shortage.= =20 For HBAs (or SIM design) that require a limited number of requests queued to the controller (or devices), the SIM has to maintain in memory a queue of not yet actually queued IOs. All the logical device IO=20 queueing/freezing is to be performed by SIM. On this point, FreeBSD-CAM is _very_ different from CAM. Justin preferred to handle all queuing from memory in the XPT. SIMs indicates the maximum number of outstanding IOs they can handle to XPT. This allows SIMs not to have to handle queues in memory and allows peripheral drivers (and/or XPT)= =20 to implement some sophisticated scheduling any SIM will never want to provide. Such an approach has advantages and disadvantages. I have exchanged several mails with Justin about this topic. Being different from CAM does not mean being not as good as CAM (or worse in essence :) ). I noticed the differences, but donnot have any preferences. I just would have designed the sym_hipd driver differently if the logical device queue handling has had to be performed by SIM. Btw, FreeBSD-CAM looks quite fine to me. G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.991014000724.375A-100000>