Date: Thu, 23 Sep 1999 13:24:32 -0600 (MDT) From: "Kenneth D. Merry" <ken@kdm.org> To: dillon@apollo.backplane.com (Matthew Dillon) Cc: cmsedore@mailbox.syr.edu (Christopher Sedore), freebsd-hackers@FreeBSD.ORG Subject: Re: mbufs, external storage, and MFREE Message-ID: <199909231924.NAA06294@panzer.kdm.org> In-Reply-To: <199909231731.KAA28739@apollo.backplane.com> from Matthew Dillon at "Sep 23, 1999 10:31:54 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote... > :I have the following question: Let's say that I have a block of user > :memory which I've mapped into the kernel, and would like to send on a > :network socket. I'd like to simply grab an mbuf, point to the memory as > :external storage, and queue it up for transmission. This would work fine, > :except that when MFREE gets called, I have to write an deallocator that > :maintains a table of all the different cases where I've done this, and do > :a reverse mapping back to the original block, and then deal with sending > :more, unmapping, etc. In other words, having MFREE call a deallocator > :with just the data pointer and the size is inconvenient (actually, it > :would make my scenario quite inefficient given the number of mappings back > :to the original block that would have to be done). > : > :Am I missing another mechanism to handle this? Does it not come up enough > :to matter? > : > :-Chris > > This is almost precisely the mechanism that the sendfile() system call > uses. In that case it maps VMIO-backed data rather then user memory, > but it is a very similar problem. > > There has been talk of implementing this type of mechanism not only for > sockets, but for file read()/write() as well. In fact, John Dyson had > delved into the issue with his vfs.ioopt stuff before he ran out of time. > > The one problem with using direct VM page mappings is that currently there > is no way for the socket to prevent the underlying data from being > modified in the middle of a transmission. And, in the same respect for > vfs.ioopt, no way to prevent the data the user ostensibly read() into > his 'private' buffer from changing out from under the user if the > underlying file is modified. How about marking the page copy-on-write? That way, if the user modifies the page while it is being transmitted, it'll just be copied, so the original data will be intact. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909231924.NAA06294>