From: James Smart <James.Smart@Emulex.Com>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: linux-scsi@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] Netlink and user-space buffer pointers
Date: Thu, 20 Apr 2006 10:33:12 -0400 [thread overview]
Message-ID: <44479BA8.1000405@emulex.com> (raw)
In-Reply-To: <4446AC80.6040604@cs.wisc.edu>
Mike Christie wrote:
> For the tasks you want to do for the fc class is performance critical?
No, it should not be.
> If not, you could do what the iscsi class (for the netdev people this is
> drivers/scsi/scsi_transport_iscsi.c) does and just suffer a couple
> copies. For iscsi we do this in userspace to send down a login pdu:
>
> /*
> * xmitbuf is a buffer that is large enough for the iscsi_event,
> * iscsi pdu (hdr_size) and iscsi pdu data (data_size)
> */
Well, the real difference is that the payload of the "message" is actually
the payload of the SCSI command or ELS/CT Request. Thus, the payload may
range in size from a few hundred bytes to several kbytes (> 1 page) to
Mbyte's in size. Rather than buffer all of this, and push it over the socket,
thus the extra copies - it would best to have the LLDD simply DMA the
payload like on a typical SCSI command. Additionally, there will be
response data that can be several kbytes in length.
> ... I think there may be issues with packing structs or 32 bit
> userspace and 64 bit kernels and other fun things like this so the iscsi
> pdu and iscsi event have to be defined correctly and I guess we are back
> to some of the problems with ioctls :(
Agreed. In this use of netlink, there's not a lot of wins for netlink over
ioctls. It all comes down to 2 things: a) proper portable message definition;
and b) what do you do with that non-portable user space buffer pointer ?
-- james s
next prev parent reply other threads:[~2006-04-20 14:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-17 20:44 [RFC] FC Transport : Async Events via netlink interface James Smart
2006-04-18 16:01 ` Mike Anderson
2006-04-19 12:52 ` James Smart
2006-04-19 12:57 ` [RFC] Netlink and user-space buffer pointers James Smart
2006-04-19 16:22 ` Patrick McHardy
2006-04-19 17:08 ` James Smart
2006-04-19 17:16 ` Patrick McHardy
2006-04-19 16:26 ` Stephen Hemminger
2006-04-19 17:05 ` James Smart
2006-04-19 21:32 ` Mike Christie
2006-04-20 14:33 ` James Smart [this message]
2006-04-20 17:45 ` Mike Christie
2006-04-20 17:52 ` Mike Christie
2006-04-20 17:58 ` Mike Christie
2006-04-20 20:03 ` James Smart
2006-04-20 20:35 ` Mike Christie
2006-04-20 20:40 ` Mike Christie
2006-04-20 21:41 ` Mike Christie
2006-04-20 21:51 ` Mike Christie
2006-04-20 23:07 ` Mike Christie
2006-04-20 23:44 ` Andrew Vasquez
2006-04-20 20:18 ` Douglas Gilbert
2006-04-19 14:59 ` [RFC] FC Transport : Async Events via netlink interface Matthew Wilcox
2006-04-19 16:11 ` James Smart
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=44479BA8.1000405@emulex.com \
--to=james.smart@emulex.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
--cc=netdev@vger.kernel.org \
/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.