All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: "Eric W. Biederman" <ebiederm+eric@ccr.net>
Cc: Weimin Tchen <wtchen@giganet.com>, linux-mm@kvack.org
Subject: Re: questions on having a driver pin user memory for DMA
Date: Thu, 20 Apr 2000 13:30:17 +0100	[thread overview]
Message-ID: <20000420133017.D16473@redhat.com> (raw)
In-Reply-To: <m1g0shi8cm.fsf@flinx.biederman.org>; from ebiederm+eric@ccr.net on Thu, Apr 20, 2000 at 01:39:53AM -0500

Hi,

On Thu, Apr 20, 2000 at 01:39:53AM -0500, Eric W. Biederman wrote:
> 
> The rules of thumb on this issue are:
> 1) Don't pin user memory let user space mmap driver memory.

map_user_kiobuf is intended to allow user space buffers to be mapped
the other way safely.

> 2) If you must have access to user memory use the evolving kiobuf
>    interface.  But that is mostly useful for the single shot
>    read/write case.  

There are not many problems with long-lived buffers mapped by kiobufs.
The fork problem is the main one, but we already have patches for that.

> I'm a little dense, with all of the headers and trailers
> that are put on packets how can it be efficient to DMA to/from
> user memory?  You have to look at everything to compute checksums
> etc.  

VIA != IP.

> Your interface sounds like it walks around all of the networking
> code in the kernel.  How can that be good?

VIA != networking.  VIA == messaging.  It provides for very (VERY) 
low latency user-space-to-user-space transfers, bypassing the O/S
entirely by allowing the O/S to grant the application direct, 
limited access to the HW control queues.

--Stephen

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  parent reply	other threads:[~2000-04-20 12:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-04-19 23:02 questions on having a driver pin user memory for DMA Weimin Tchen
2000-04-20  6:39 ` Eric W. Biederman
2000-04-20  9:20   ` Ingo Oeser
2000-04-20 12:30   ` Stephen C. Tweedie [this message]
2000-04-20 12:27 ` Stephen C. Tweedie
2000-04-20 23:43   ` Weimin Tchen
2000-04-21 18:20     ` Kanoj Sarcar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000420133017.D16473@redhat.com \
    --to=sct@redhat.com \
    --cc=ebiederm+eric@ccr.net \
    --cc=linux-mm@kvack.org \
    --cc=wtchen@giganet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.