>
>"Justin T. Gibbs" <gibbs@freefall.freebsd.org> writes:
>
>> 
>> I think we're missing each other here.  Forcing the device driver to do the
>> copy from a bus_dma_segment_t into its own private format doesn't solve the
>> structure alignment problem.
>
>What `problem'?  Arguably, the device driver shouldn't be using a
>structure at all, since structure packing isn't portable.  Tweaking
>this one specific case misses the larger picture.

Then the SG format 'filters' can be written MI and can not only
be shared among different devices, but different archtectures too.

>> In fact it forces each individual driver to
>> handle it much the same as is done (or not done) now.
>
>No; it removes all knowledge of how the addresses are mapped from the
>device driver.  The point of this interface is to deal with mapping
>arbitrary regions of memory into DMAable regions of memory.

Put it still forces each driver to re-invent the wheel if their SG
format is the same as other driver's.

>> Having a family of
>> functions that can be ported to different architectures and know how to
>> deal with the SG formats completely removes the knowledge of how X arch
>> aligns its data.
>
>I don't see why this even makes *sense*.  The scatter/gather list
>format is very much driver-specific.  Why do you think it belongs in a
>device-neutral interface?

Why do you want to at least double the amount of memory my driver needs
to consume in order to do DMA?

>> I haven't been convinced that there is an architectural comprimize.  Right
>> now I'm looking at more code, [...]
>
>If you consider the general case of N architectures, M busses, and P
>drivers:
>
>* Jason's interface seems to require O(N*M) mapping functions plus
>O(P) bits of code to convert the S/G list.
>
>* An interface such as you suggest would require either O(N*M*P)
>mapping functions, or O(N*M) mapping functions plus O(P) converters,
>as above.  It's possible that a few of these converters may be
>reusable, but most of them won't be.  It other worse, you either have
>significantly more code, or you degenerate to more or less the same
>thing as Jason's interface.

Except that you don't have an extra buffer copy or double the SG space.
You also don't spend your time creating some arbitrary MI format for
the SG list that no-one can directly use.

>So just where do you get your claim of `more code'?

The drivers I know of that use the same SG format are: ncr, aic7xxx,
ahb, and bt drivers.  I would expect that most devices that do PCI
DMA use the same format, but I haven't looked.  So that's four
drivers in the tree right now that have their own SG conversion
routines and would continue to have them in the current proposal.
In my book, that's more code.

>> architechtures.  Furthermore, the interface is not device, bus or
>> machine dependant, it is simply SG format dependant.  The SG format
>> dependencies have to be dealt with *somewhere*.  My point is only
>> that by handling them in the interface itself, you gain efficiency
>> and code reuse.
>
>And you put knowledge of how a device works internally into what would
>otherwise be a device-neutral interface.  That's architecturally
>broken.  Worse, it means that any new device driver is likely to
>require N*M pieces of additional code to be written and integrated,
>making device driver development more difficult.

It will require a new MI filter and a new case statement in any arch
that supports that device.  I really don't see the number of formats
skyrocketting.  There are probably ~3 different formats in the i386
port right now, all three of which can be handled in an MI way and
all three of which would be needed on other archs.  If you add in a
format that takes an arbitrary callback function, you've got a grand
total of four.

>> With my proposal, the driver could only make assumtions about its
>> own SG format and wouldn't even have to know how to build it.
>
>I can't imagine why you think that's a win.  The format is
>device-dependent.  Why should the device driver not know how to create
>it?

Because it invites the code to be MD when it can probably be MI.

>All of the above said, it would be worth investigating the relative
>performance penalty of using a callback, but this needs to be tested
>on more architectures.

Definitely, but I would expect that in some instances the callback would
be the ideal way to construct the SG list.  I just don't want to force
that overhead on devices that can easily use a simple inline filter.

>Since your only comments seem to be about performance,

Performance and memory consumption.

>I'd suggest you
>look at the Irix DMA mapping interface, and compare it with Jason's.
>The Irix interface is more expensive, yet they seem to have achieved
>.5GB/s I/O with it.

Yeah and I would expect that this new supercomputer the govverment
is building can pump even more data then that.  If all of NetBSD's
users had SGI Challenge servers I'm sure that you could justify a
lot of overhead from poorly designed interfaces.

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================