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 for Android: free password hash cracker in your pocket

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

Message-ID: <48A47925.3000409@vlnb.net>
Date:	Thu, 14 Aug 2008 22:27:49 +0400
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	David Miller <davem@...emloft.net>
CC:	open-iscsi@...glegroups.com, rdreier@...co.com, rick.jones2@...com,
	jgarzik@...ox.com, swise@...ngridcomputing.com, kxie@...lsio.com,
	netdev@...r.kernel.org, michaelc@...wisc.edu, daisyc@...ibm.com,
	wenxiong@...ibm.com, bhua@...ibm.com, dm@...lsio.com,
	leedom@...lsio.com, linux-scsi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator

David Miller wrote:
> From: Vladislav Bolkhovitin <vst@...b.net>
> Date: Wed, 13 Aug 2008 22:35:34 +0400
> 
>> This is because the target sends data in a zero-copy manner, so its
>> CPU is capable to deal with the load, but on the initiator there are
>> additional data copies from skb's to page cache and from page cache
>> to application.
> 
> If you've actually been reading at all what I've been saying in this
> thread you'll see that I've described a method to do this copy
> avoidance in a completely stateless manner.
> 
> You don't need to implement a TCP stack in the card in order to do
> data placement optimizations.  They can be done completely stateless.

Sure, I read what you wrote before writing (although, frankly, didn't 
get the idea). But I don't think that overall it would be as efficient 
as full hardware offload. See my reply to Jeff Garzik about that.

> Also, large portions of the cpu overhead are transactional costs,
> which are significantly reduced by existing technologies such as
> LRO.

The test used Myricom Myri-10G cards (myri10ge driver), which support 
LRO. And from ethtool -S output I conclude it was enabled. Just in case, 
I attached it, so you can recheck me.

Thus, apparently, LRO doesn't make a fundamental difference. Maybe this 
particular implementation isn't too efficient, I don't know. I don't 
have enough information for that.

Vlad


View attachment "ethtool_initiator.txt" of type "text/plain" (1499 bytes)