Warren Peece wrote:
It depends on a few things. Increased performance is great, but at
what expense? What constraints define when it can be used, and is
there a downside for where it can’t be used?
Constraint: The client’s buffer must be page aligned and it’s size has
to be a multiple of the page size.
Downside: If the buffer is not aligned, then you do it the old
fashioned way – you DMA into local buffers and MsgReply the stuff
back. So, performance levels should be the same as it is right now in
the “bad” case.
Upside: If everything is properly aligned, then you just cut most of
the CPU overhead and saved a large wasted data copy.
For large non-caching transfers like DVD, it would be worth the effort
to mmap a big page aligned buffer and have the filesystem DMA directly
into your buffers.
At what level are you proposing that this be integrated into the
O.S.? What exactly do you mean by “worth something to QSSL and the
developers”? Who are “the developers”?
We’re trying to put this idea into the open, get feedback and let
QSSL know about it. If it withstands scrutiny, then consider it a
feature suggestion to QSSL. Of course, the more relevant the feature
(“worth something”) is to QSSL’s business and to the developers who
support QSSL, the better chance it will be accepted.
It sounds like you want to sell me an add-on package that does DMA
transfers to network and storage devices.
No, this is not something a 3rd party can do, nor do we want to
“sell” (as in 3rd party product) you anything. We simply wish to
voice an idea we have and get it to the right people.
Any generic solution is probably going to have to involve the QNX
folks, and the odds of this fitting into their schedules any time
soon isn’t very likely, especially considering their emphasis on
the embedded marketplace.
Yes, you’re absolutely right. If it sounds like a sales pitch, it’s
because in a way, it is! If there’s any hope in hell we’re gonna get
taken seriously, we’ve gotta show that we did our homework and
withstand peer review. And again, we have to show that it is relevant
to QSSL’s current business (the embedded marketplace). Why else
would they write a DVD player and port RealPlayer (both of which
would benefit from direct DMA transfers) if it wasn’t relevant to
I have no interest in a third party I/O subsystem whatsoever. I
have no idea where you’re headed with this, so…
As far as applicability goes, it can be used in io-blk and possibly
io-net. So, if you use “large” disk or network I/O in whatever you do,
this would interest you. I hope that you have a better idea where
we’re trying to head with this now.
In response to the original question, there is no way that I’ve ever
heard of for you to get the “gather list” from the kernel (which does
all of the message passing). You would have to send the physical
addresses in the message and then deal with them in your driver.
Right. And trusting the client to give the driver a proper “gather
list” isn’t a good way to do things. There’s no way for the driver to
verify that the physical addresses don’t refer to another address
space. This is why it must be a part of the message passing API,
where the driver can trust the validity of the gather list.
University of Waterloo