> 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.
>
Speaking of RH - RHEL 7.1 doesn't handle cable pulls and lost connections very well. I was just
trying to figure out what to do about that, since the fixes are in 3.19, when Nic's 3.10 patches
showed up on the list. At first glance it looks like these patches will fix the issues, but I
haven't tried them yet. If they do, it would be great if we can get RH to pick these up in RHEL 7.1.
Chris
��.n��������+%������w��{.n����j� ����{ay� ʇڙ���f���h������_�(�階�ݢj"��������G����?���&��
