All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karim Yaghmour <karim@opersys.com>
To: James Morris <jmorris@redhat.com>
Cc: Tom Zanussi <zanussi@us.ibm.com>,
	linux-kernel@vger.kernel.org, bob@watson.ibm.com
Subject: Re: [PATCH][RFC] relayfs (1/4) (Documentation)
Date: Thu, 09 Oct 2003 13:42:09 -0400	[thread overview]
Message-ID: <3F859DF1.8000602@opersys.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0310091311440.14415-100000@thoron.boston.redhat.com>


James Morris wrote:
> It should be possible to make Netlink sockets mmapable (like the packet 
> socket).

So would you consider running printk on Netlink sockets? Do you think Netlink
could accomodate something as intensive as tracing? etc.

While I am aware that a lot of people are using Netlink sockets to exchange
data from the kernel to user-space, I don't think Netlink sockets can handle
the type of throughput relayfs can handle. Netlink and other communication
mechanisms (pipes, shared memory pages, etc.) were not designed to handle
the type of throughput relayfs was designed for. If nothing else, the use
of netlink also drags with it lots of networking code (netlink_sendmsg->
alloc_skb->kmalloc->etc. and then memcpy) With relayfs, you get direct
access to the buffer: relay_write->relay_write_direct (which is actually
a macro for memcpy()).

So yes, as you say, "It should be possible to make Netlink sockets mmapable",
but in that case you might as well port the netlink sockets API to relayfs
and you'll probably get better results.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145


  reply	other threads:[~2003-10-09 17:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-07 20:59 [PATCH][RFC] relayfs (1/4) (Documentation) Tom Zanussi
2003-10-09 13:45 ` James Morris
2003-10-09 15:25   ` Tom Zanussi
2003-10-09 17:15     ` James Morris
2003-10-09 17:42       ` Karim Yaghmour [this message]
2003-10-10  7:57         ` David S. Miller
2003-10-10 14:41           ` Karim Yaghmour
2003-10-11 17:34             ` David S. Miller
2003-10-12 23:23               ` Richard J Moore
2003-10-13 17:25                 ` David S. Miller
2003-10-14 11:32                   ` Richard J Moore
2003-10-14 16:44                     ` David S. Miller
2003-10-15 16:56                       ` Richard J Moore
2003-11-13 14:19                       ` Hubertus Franke
2003-10-13 14:53               ` Tom Zanussi
2003-10-10 15:26           ` Tom Zanussi

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=3F859DF1.8000602@opersys.com \
    --to=karim@opersys.com \
    --cc=bob@watson.ibm.com \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zanussi@us.ibm.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.