Date: Tue, 12 Oct 1999 10:42:52 -0600 (MDT) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: Gerard Roudier <groudier@club-internet.fr> Cc: scsi@FreeBSD.org Subject: Re: Driver for GDT6517RD RAID controller Message-ID: <199910121642.KAA34505@narnia.plutotech.com> In-Reply-To: <Pine.LNX.3.95.991011211622.403A-100000@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <Pine.LNX.3.95.991011211622.403A-100000@localhost> you wrote: > > Having to ask a kernel abstraction for providing me a scatter list and > then having to rewalk it for it to conform with the expectations of the > hardware (sometimes modulo device errata) is something that makes me pain > in the ass to run on my Intel machine. For the NCR, I would expect that you wouldn't need to rewalk it at all other than to copy it to your own private storage. With bus-dma, you should be able to specify all of the parameters necessary to get an S/G list that avoids all of your hardware bugs. Other than it being created before the transaction comes to the SIM, this seems very similar to Linux. Having every driver create their own S/G list is problematic when kernel interfaces change. What happens when we change our clustering code to pass down a list of I/O requests to be combined? Hopefully this will just result in the drivers calling a slightly different bus_dma method. > So, even if I ever go with some > BUS abstractions for this kind of stuff, I will keep with the legacy > _simple_ way to do the same thing, conditionnally compilable for my > personnal use (as long as this legacy way will be available, obviously). > > Same pain in the ass if, when doing MMIO I have to call something that > will not only do the memory access, but each time will test for having to > do IO or MMIO. This situation may get just ridiculous for example for a > device that only allows one of the IO methods (only MMIO for example on > PCI). FreeBSD does not cause any penalty for devices that only support a single access method. You just need to include the appropriate header files to indicate this and the extra overhead of supporting additional access methods goes away. Unfortunately, in the generic kernel case, you often need to support multiple access types in the same [PCI] driver as not all machines/chipsets handle the most efficient access method [MMIO]. If the abstraction allows you to create a readable piece of code that can be compiled to run generically but can also be compiled to run optimally this seems ideal. There has been some talk on the lists about adding kernel options that would allow you to globally optimize the access methods so even drivers that sometimes need to support mutliple access methods can be easily tuned for specific machines. Since you seem to have an opinion about these things, perhaps you should join in the discussions. >> The other possible thing I'm considering doing (since a couple of >> the SIM's do have support for target-mode) is to build an IP transport > > You must distinguish between phase cognizant target mode and host target > mode. What I intend to implement in the future is something that avoids > stalling the phase engine as possible, thus host target mode. Note that if > you just read the messages after selection, accept the command and > disconnect prior to signaling the upper layer, then this host target mode > will never stall the phase engine in normal situations when implemented > with 53c8xx chips. This will allow to use both initiator and target mode > on an HBA without wasting uselessly SCSI BUS bandwitch for the target mode > part. I agree phase cognizant isn't that interesting. The aic7xxx driver works in the fashion you describe. > As seen from SIM the handling of the target mode is in fact much simpler > tham initiator mode, since the part that acts as a target has the baton in > SCSI. So, a SIM that will only implement target mode should be > significantly simpler than common ones that only implement initiator mode > (given appropriate hardware). > What is not simple is to provide both modes from a SIM, without the > support for the target mode adding too much complexity (making driver less > reliable) and wasting too much resources. Target mode isn't difficult, but I would refrain from calling it simpler than the initiator role. There are several little gotchas mostly having to do with resource deadlocks when running in both roles at the same time and the initiator tells you that you cannot disconnect. -- Justin 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?199910121642.KAA34505>