On Thu, 2015-01-22 at 20:14 +0200, Sagi Grimberg wrote: > 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. > <nod> > 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? > If it's a just multi-login performance improvement, vs. a functional correctness change, then probably not. --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
