Date: Mon, 19 Jun 2000 16:43:29 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Mike Smith <msmith@FreeBSD.ORG> Cc: "Kenneth D. Merry" <ken@kdm.org>, arch@FreeBSD.ORG Subject: Re: kblob discussion. Message-ID: <20000619164329.F37084@prism.flugsvamp.com> In-Reply-To: <200006192103.OAA09596@mass.osd.bsdi.com> References: <20000619143437.A80133@panzer.kdm.org> <200006192103.OAA09596@mass.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 19, 2000 at 02:03:07PM -0700, Mike Smith wrote:
> > On Mon, Jun 19, 2000 at 13:09:11 -0700, Alfred Perlstein wrote:
> > > * Kenneth D. Merry <ken@kdm.org> [000619 12:40] wrote:
> > > > I would like to see something more generic as well, especially something
> > > > that could work for both sending and receiving.
> > >
> > > As would I.
>
> Receiving into a kernel-side buffer is somewhat pointless, really. You
> want stuff to go into userspace. This is an output accelerator, not a
> new I/O method.
*cough*. Are you sure about that? An output accelerator is a new I/O
method regardless of what you want to call it. And for a lot of cases
you don't need stuff to actually go to user space. In many situations,
you will receive data, perform operations on a very small part of it,
and then send the data elsewhere, whether to disk or network.
In this case, why bother sending things to user space if you're just
going to end up sending them back out again? I can assure you that
receiving into a kernel-side buffer is a win in this case.
Kblob only addresses part of the problem.
Also, if I want to send data from disk -> network, with the kblob
API, I essentially have the following sequence of calls:
read(fd, address, length)
kblob(address, length)
kblobsend(...)
which is to say, the data is copied from
disk -> userspace (assuming direct I/O)
userspace -> kernel,
kernel -> network.
Why shouldn't I be able to bypass second copy entirely and do:
disk -> kernel (data now in kernel 'blob')
kernel -> network
Again, this is not addressed in the kblob API. Don't throw sendfile()
up as an example, because I want the data to be kept in the kernel
after being read from disk.
> > > > Another thing that I would like to see is the ability to get notification
> > > > of when the I/O is done, like async I/O.
> > >
> > > That can be easily put into kblob at the expense of some performance,
> > > however it would require a side allocation per send which negates
> > > the whole purpose of it as a low overhead extremely fast way to send
> > > data.
> >
> > This gets into the generic API versus specific API issue.
>
> It would be fairly trivial to add a mechanism for generating kevents when
> points in the socket transmit buffer are reached, which would then allow
> you to do this. I don't think that it should be added to the kblob code
> as a specific hack, however.
Actually, I would prefer that you register a kevent on the send() or
recv() call, so that an event can be generated which contains the entire
state of the transfer. But that's kind of orthogonal to the issue.
> > > > Anyway, those are just some ideas, I think there's some room for
> > > > discussion here.
> > >
> > > I'd rather not, I've already discussed it a lot and many people
> > > want this functionality. The people that want more flexibility
> > > don't realize that the interface is easily extendable (or don't
> > > want to extend it themselves), and the people that don't like it
> > > on principle don't see the need for changes to get real world
> > > performance increases.
> >
> > I'd be more in favor of doing it right the first time, rather than
> > continually revising and extending the interface.
>
> As it stands, kblob is "right". It's lean and to-the-point. I'd rather
> not see it undergo second-system syndrome before it's even made it to
> first base. If you plan to implement an efficient zero-copy network I/O
> interface, then it should be done from scratch, not as a wart on the side
> of what is really fairly specific feature.
I disagree on your definition of "right". I would argue that if we're
going to implement an I/O accelerator of any form, it should not be so
specific purpose that it precludes any other possible applications.
- How do I receive data _into_ a kblob (either from a network or a disk?)
- Once data is in a kblob, is there any possibility of editing it?
Do I have to throw it all away and reload if I want to make a minor
change to the data?
- Can I retrieve data from a kblob?
- Can kblobs be transferred to disk?
--
Jonathan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000619164329.F37084>