On 1/22/2015 7:44 PM, Nicholas A. Bellinger wrote:
On Thu, 2015-01-22 at 19:19 +0200, Sagi Grimberg wrote:
On 1/22/2015 6:15 AM, Nicholas A. Bellinger wrote:
From: Sagi Grimberg <sagig@xxxxxxxxxxxx>
commit 2371e5da8cfe91443339b54444dec6254fdd6dfc upstream.
There is no point in accepting a new CM request only
when we are completely done with the last iscsi login.
Instead we accept immediately, this will also cause the
CM connection to reach connected state and the initiator
is allowed to send the first login. We mark that we got
the initial login and let iscsi layer pick it up when it
gets there.
This reduces the parallel login sequence by a factor of
more then 4 (and more for multi-login) and also prevents
the initiator (who does all logins in parallel) from
giving up on login timeout expiration.
In order to support multiple login requests sequence (CHAP)
we call isert_rx_login_req from isert_rx_completion insead
of letting isert_get_login_rx call it.
I'm a bit concerned with this one...
Is this an absolute must? this fixes *mutliple* login requests.
I'm afraid that this will actually work it is a long shot given
iscsi properly multi-plexing across multiple sockets during
login stage.
The next patch would also be redundant if we skip this...
Mmmm, good point.
Your call if patch #5 + #6 should be dropped here..
These would be the first candidates to drop if I see a noticeable
regression.
Just wandering, if we get RH to get the target stack (or at least the
iscsit + isert) stacks to kernel 3.19, is this really necessary?
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
