netdev - Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Aug 2008 16:45:57 -0400
From:	Andrew Gallatin <gallatin@...i.com>
To:	David Miller <davem@...emloft.net>
CC:	rick.jones2@...com, rdreier@...co.com, jgarzik@...ox.com,
	swise@...ngridcomputing.com, divy@...lsio.com, kxie@...lsio.com,
	netdev@...r.kernel.org, open-iscsi@...glegroups.com,
	michaelc@...wisc.edu, daisyc@...ibm.com, wenxiong@...ibm.com,
	bhua@...ibm.com, dm@...lsio.com, lee@...per.es
Subject: Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator

David Miller wrote:
 > From: Rick Jones <rick.jones2@...com>
 > Date: Mon, 11 Aug 2008 11:13:25 -0700
 >
 >> David Miller wrote:
 >>> And I even wonder, these days, if you probably get %90 or more of the
 >>> gain these "optimized" iSCSI connections obtain from things like LRO.
 >>> And since LRO can be done entirely in software (although stateless
 >>> HW assistence helps), it is even a NIC agnostic performance 
improvement.
 >> Probably depends on whether or not the iSCSI offload solutions are doing
 >> zero-copy receive into the filecache?
 >
 > That's a data placement issue, which also can be solved with
 > stateless offloading.

Speaking of stateless data placement.  Assume you have a page or set
of pages allocated by a network driver which contain exactly the data
a block driver is interested in to fulfill a read request (eg, the NIC
understands the protocol just well enough to split headers).  Is it
possible in the block driver to simply replace the pages that are
attached to the buf with pages allocated by the network driver?

It was my impression that the pages associated with a buf are in
fairly magical states and that you cannot replace them.  Rather,
you actually need to register them with the NIC, so the NIC can
receive into them rather than into an anonymously allocated page.
At this point, the NIC needs to be smart enough to match the block
read requests with the correct buffer, and you need some kind of
side channel between the network driver and the block driver to
pass the DMA address of the buf's pages and associated read request
tag.

Is this true?

Drew
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html