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]

Message-ID: <48A38FEF.6090500@opengridcomputing.com>
Date:	Wed, 13 Aug 2008 20:52:47 -0500
From:	Steve Wise <swise@...ngridcomputing.com>
To:	David Miller <davem@...emloft.net>
CC:	tom@...ngridcomputing.com, rdreier@...co.com, rick.jones2@...com,
	jgarzik@...ox.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, 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: Tom Tucker <tom@...ngridcomputing.com>
> Date: Wed, 13 Aug 2008 20:26:51 -0500
>
>   
>> Can you explain how this "information" somehow doesn't qualify as 
>> "state". Doesn't the next expected sequence number at the very least 
>> need to be updated? una? etc...?
>>
>> Could you also include the "non-state-full" information necessary to do 
>> iSCSI header digest validation, data placement, and marker removal? 
>>     
>
> It's stateless because the full packet traverses the real networking
> stack and thus can be treated like any other packet.
>
> The data placement is a side effect that the networking stack can
> completely ignore if it chooses to.
>   
How do you envision programming such a device?  It will need TCP and 
iSCSI state to have any chance of doing useful and productive placement 
of data.  The smarts about the iSCSI stateless offload hw will be in the 
device driver, probably the iscsi device driver.  How will it gather the 
information from the TCP stack to insert the correct state for a flow 
into the hw cache?


--
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