[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080813.150831.193391799.davem@davemloft.net>
Date: Wed, 13 Aug 2008 15:08:31 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: rdreier@...co.com
Cc: rick.jones2@...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, leedom@...lsio.com, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator
From: Roland Dreier <rdreier@...co.com>
Date: Wed, 13 Aug 2008 14:27:50 -0700
> I don't see how this could work. First, it seems that you have to let
> the adapter know which connections are iSCSI connections so that it
> knows when to try and parse iSCSI headers.
It always starts from offset zero for never seen before connections.
> So you're already not totally stateless.
Yes, we are.
> Then, since (AFAIK -- I'm not an expert on iSCSI and
> especially I'm not an expert on what common practice is for current
> implementations) the iSCSI PDUs can start at any offset in the TCP
> stream, I don't see how a stateless adapter can even find the PDU
> headers to parse -- there's not any way that I know of to recognize
> where a PDU boundary is without keeping track of the lengths of all the
> PDUs that go by (ie you need per-connection state).
Like I said, you retain a "flow cache" (say it a million times, "flow
cache") that remembers the current parameters and the buffers
currently assigned to that flow and what offset within those buffers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists