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