Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Oct 1999 21:53:46 +0200 (MET DST)
From:      Gerard Roudier <groudier@club-internet.fr>
To:        "Justin T. Gibbs" <gibbs@narnia.plutotech.com>
Cc:        scsi@FreeBSD.org
Subject:   Re: Driver for GDT6517RD RAID controller
Message-ID:  <Pine.LNX.3.95.991012210439.377A-100000@localhost>
In-Reply-To: <199910121642.KAA34505@narnia.plutotech.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On Tue, 12 Oct 1999, Justin T. Gibbs wrote:

> In article <Pine.LNX.3.95.991011211622.403A-100000@localhost> you wrote:
> >=20
> > 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 pa=
in
> > in the ass to run on my Intel machine.
>=20
> 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.
>=20
> 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.

The bus dma method I have seen requires the caller to wait for a call back
for the resources to be available. This moves the burden of having to deal
with such resources leakage in the SIM. This should be an option, in my
opinion and optionnally handled from the caller (that will provide a
scatter list to the SIM).

I read that such bus dma method was also intended to deal with host bridge
that does not ensure cache consistency or any other weirdnesses that can
be encountered with existing bridges.=20

Let me give you an example:
Let consider a host bridge (such does exist) that posts both IO and MMIO
and MMIO transactions (By the way, the PCI specs allows host bridge to
also post IOs). Let this crap also not implement the PCI ordering rules,
but wan to be able to interface properly with PCI-2.1/2.2 PCI-to-PCI
bridges. Let then this utter crap allow to force flushing of transactions
by the host bridge by tampering some specific hardware registers, in order
to ensure a consistent view of data when needed.=20

If you want a PCI device driver to really work on such weirdness, then
abstractions will not help at all. On the contrary, you must allow the
drivers to have a real handle on the hardware (including host bridge), and
using normal IOs will not be enough at all. If it was possible for us to
look into proprietary PCI device drivers, may-be we will discover how such
situation is actually handled the kinds of hardware I am speaking about.

There are errata everywhere and one who wants to provide reliable PCI
device driver for portable O/S must be aware on the erratas of the PCI
device and at least of the functionnal description of existing host
bridges when available (erratas will be a plus but aren't always
available). The way the CPU handles write buffers must also be considered,
especially when using MMIOs. Even a feature can become a bug, given all
that mess.

Drivers that are actually maintained are generally converted to new O/S
requirements very quickly, in my experience.=20

By the way, some constraints as the max size of scatter entries, the
clustering of scatter entries, not traversing some address boundary, etc
=2E.., when building a scatter list may affect performances and/or trigger
erratas. I just wanted not to have to do the work twice, even if this may
seem to possibly happen on Linux. In fact under Linux, scatter entries are
aligned on some nice address boundaries and you can tell the upper layer
not to clusterize entries.=20

Some O/S designed to be portable (but seems no longer to be so) got slow
probably due to some infinite of epsilonish design and implementation
errors. I would be sad to ever see any free UNIX O/S to get NTified this
way.

> > 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)=
=2E=20
> > =20
> > 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).
>=20
> 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.

Sorry and Thanks. I missed that. Will look into the sources.

> >> =09The 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
> >=20
> > You must distinguish between phase cognizant target mode and host targe=
t
> > 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 mo=
de
> > will never stall the phase engine in normal situations when implemented
> > with 53c8xx chips. This will allow to use both initiator and target mod=
e
> > on an HBA without wasting uselessly SCSI BUS bandwitch for the target m=
ode
> > part.
>=20
> I agree phase cognizant isn't that interesting.  The aic7xxx driver works
> in the fashion you describe.

I am very glad of that and believe me I ignored it.

> > As seen from SIM the handling of the target mode is in fact much simple=
r
> > 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 mo=
de=20
> > (given appropriate hardware).=20
> > 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 l=
ess
> > reliable) and wasting too much resources.
>=20
> Target mode isn't difficult, but I would refrain from calling it simpler
> than the initiator role.  There are several little gotchas mostly having

I mean simpler to act as target than as initiator regarding the SCSI
protocol and simpler to write a driver that _only_ implements target role
than a driver than _only_ implements initiator role.

> to do with resource deadlocks when running in both roles at the same time
> and the initiator tells you that you cannot disconnect.

Move 10 lines above, and you will see that I didn't write that support=20
for both roles was simple.

AFAIR, in CAM3, the target peripheral driver can require disconnections to
be used. In this situation the initiator must just be refused to be served
when it disallows disconnections. And if both target and initiator parts
actually want to waste SCSI bandwitch, we just have to 'dont_care' and
behave as both parts did agree.

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.991012210439.377A-100000>