Maximum number of targets available/usable

[Shreyansh]

Hi list,

This post is a continuation of a discussion on open-iscsi list at
http://groups.google.com/group/open-iscsi/browse_thread/thread/529e66f7be553db9/1ef9bcb5dde6853e?hl=en#1ef9bcb5dde6853e.
I was suggested by folks at open-iscsi to try this question here.

Environment:
A machine running open-iscsi-2.0-869 initiator another running
iscsitarget-0.4.16 as target driver. These are connected using a 10G
ethernet. Target machine has a couple of SCSI devices connected
through a HBA.

*I am trying to find the maximum number of devices that can be added
by an initiator*. OR, maximum number of devices that a target can
detect and initiator can discover - if any limits exists on this. For
this I tried a  mini-experiment as follows:

On the target machine:
1. I created softlinks for a device such that they are named /dev/link
$i_$j where i varies from 1-100 and j varies from 0-10. Thus, I had
links like "link1_0, link1_1, ...,link30_0,..., link99_0,
...link100_10".
2. Each link was a softlink of a valid SCSI device on the target. All
this was pushed into the /etc/ietd.conf file and service iscsi-target
was restarted. (Yup, I am using iscsi-target-0.4.16 on the target
side.)
3. This gave me 100 targets, each having 10 LUNs - starting from
mydisk1 to mydisk100 (as target names).

On the initiator:
1. I set the discovery on this target machine IP. and tried to log in.

result:
Discovery itself is not able to add more than 89 (twice I got 90)
devices. It simply doesn't get any information about the top 11
devices from the ietd.conf file. On the target, the message log
contained something like "Dropping key (target ___ )" which, I found,
was appearing from text_key_add() function from the iscsi-target
package.

The code is something like:
---8<---
   if (conn->rsp.datasize + len > INCOMING_BUFSIZE) {
             log_warning("Dropping key (%s=%s)", key, value);
             return;
     }
---8<---

Initiator doesn't show any error, and infact the node list (iscsiadm
-m node) doesn't display any device starting from mydevice1 -
mydevice11 in the list.

I tried this experiment many times by
1. changing the number of LUNs,
2. changing the device being pointed to by the soft links,
3. changing the number of target devices defined in ietd,
4. Changing the name of the targets, reducing them in length (which in
fact initially had about 40 characters only)
4. making half the links point to one device, and other half to other
5. Shuffling the order of ietd defined target names (and each time

starting 10-11 devices, according to definition in ietd.conf, are not
send by target, whatever there name be).

Each time the result was same (at least) - 89-90 can only be added at
the initiator side.

I am still trying to find what could be the possible bottleneck that
is preventing me to add more devices - till then, I would really
appreciate if there is anything anyone would like to point out. Any
hints or mistakes I am making? Hopefully, using dummy (links) is not
something "not-allowed" as per target/initiator implementation.

Please feel free to ping me in case you need any more information.

Thanks for any help.

--
Shreyansh

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Shreyansh]

Hi List,

There is a minor update folllowing further experiments.

> The code is something like:
> ---8<---
>   if (conn->rsp.datasize + len > INCOMING_BUFSIZE) {
>             log_warning("Dropping key (%s=%s)", key, value);
>             return;
>     }
> ---8<---
>
> Initiator doesn't show any error, and infact the node list (iscsiadm
> -m node) doesn't display any device starting from mydevice1 -
> mydevice11 in the list.

I changed the INCOMING_BUFSIZE variable in usr/iscsid.h file to be
equal to 16384. This change affected the number of device which were
now discoverable at the initator from 89 targets to 178 targets.

Also, I did one more minor change - I changed the target names such
that they contained max 15 characters. Initially the names were nearly
44 characters long. IN this case (15 char length with
INCOMING_BUFSIZE=8192) I was able to add 130 targets as against 89
targets previously.

By all this all I can say is that the amount of data being transferred
in a PDU (rsp being variable of PDU) to the initiator limits the
number of devices which are discoverable by the initiator. Please
correct me if my understanding is wrong.

Assuming my understaing is correct - Can someone help in me
understanding my INCOMING_BUFSIZE is set to 8192 (and nothing higher)
- any specific reason?
Can I modify it using any external variable?

If it is a non-specific choice, I was wondering 89 devices
discoverable is quite a small number for an enterprise. There has to
be rationale behind this which I am missing. is it?

Thanks for any help

--
Shreyansh

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich-2]

"Shreyansh Jain" <shrey.linux+iscsitarget@...> writes:

> result:
> Discovery itself is not able to add more than 89 (twice I got 90)
> devices. It simply doesn't get any information about the top 11
> devices from the ietd.conf file. On the target, the message log
> contained something like "Dropping key (target ___ )" which, I found,
> was appearing from text_key_add() function from the iscsi-target
> package.

This is a known limitation of IET: it doesn't support PDUs > 8k during
discovery sessions (or using several PDUs for that matter). Hence the
"Dropping key" warning message.

HTH,
Arne

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Shreyansh]

Hi Arne and list,

Arne Redlich <agr <at> powerkom-dd.de> writes:

>
> "Shreyansh Jain" <shrey.linux+iscsitarget <at> gmail.com> writes:
>
> > result:
> > Discovery itself is not able to add more than 89 (twice I got 90)
> > devices. It simply doesn't get any information about the top 11
> > devices from the ietd.conf file. On the target, the message log
> > contained something like "Dropping key (target ___ )" which, I found,
> > was appearing from text_key_add() function from the iscsi-target
> > package.
>
> This is a known limitation of IET: it doesn't support PDUs > 8k during
> discovery sessions (or using several PDUs for that matter). Hence the
> "Dropping key" warning message.

Thanks for your reply.

I tried changing the code of iscsitarget for setting INCOMING_BUFFER=16384
and it worked perfectly OK. I was able to add (discoverable) more devices
(178 targets) on the initiator.

Can you elaborate "it doesn't support PDUs" ?
If it did not support, probably something unexpected should have happened
when I changed the buffer size. I did not notice anything (and my experiment
was not that intense to show me something unusual). Any hints or problems
as to why this is not supported (if you have) would be simply great.

Thanks once again,

Shreyansh


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich-2]

Shrey <shrey.linux+iscsitarget@...> writes:

> Hi Arne and list,
>
> Arne Redlich <agr <at> powerkom-dd.de> writes:
>
>>
>> "Shreyansh Jain" <shrey.linux+iscsitarget <at> gmail.com> writes:
>>
>> > result:
>> > Discovery itself is not able to add more than 89 (twice I got 90)
>> > devices. It simply doesn't get any information about the top 11
>> > devices from the ietd.conf file. On the target, the message log
>> > contained something like "Dropping key (target ___ )" which, I found,
>> > was appearing from text_key_add() function from the iscsi-target
>> > package.
>>
>> This is a known limitation of IET: it doesn't support PDUs > 8k during
>> discovery sessions (or using several PDUs for that matter). Hence the
>> "Dropping key" warning message.
>
> Thanks for your reply.
>
> I tried changing the code of iscsitarget for setting INCOMING_BUFFER=16384
> and it worked perfectly OK. I was able to add (discoverable) more devices
> (178 targets) on the initiator.
>
> Can you elaborate "it doesn't support PDUs" ?
> If it did not support, probably something unexpected should have happened
> when I changed the buffer size.

No, I was just a bit inaccurate. Of course it should've read "[...] doesn't
support PDUs > INCOMING_BUFSIZE (which is 8k)".

> I did not notice anything (and my experiment
> was not that intense to show me something unusual). Any hints or problems
> as to why this is not supported (if you have) would be simply great.

To shed some more light into this: IET consists of a user space daemon
that is responsible for iSCSI login and discovery sessions. and a kernel
module that handles normal sessions in full feature phase (IOW, mainly the
actual data transfers).
iSCSI login is performed using 8k PDUs (hence the
INCOMING_BUFSIZE). While discovery sessions might use larger PDUs /
several PDUs to transfer the target lists IIRC, it just wasn't
implemented yet.

HTH,
Arne

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Shreyansh]

Hi Arne and List,

Arne Redlich <agr <at> powerkom-dd.de> writes:
> >
> > Can you elaborate "it doesn't support PDUs" ?
> > If it did not support, probably something unexpected should have happened
> > when I changed the buffer size.
>
> No, I was just a bit inaccurate. Of course it should've read "[...] doesn't
> support PDUs > INCOMING_BUFSIZE (which is 8k)".

Oops, I think I wrongly quoted my question. I Apologize for that. I wanted
to ask
"Can you elaborate "it doesn't support PDUs **> 8K** ?""
and ended up asking
> "Can you elaborate "it doesn't support PDUs?" "

>
> > I did not notice anything (and my experiment
> > was not that intense to show me something unusual). Any hints or problems
> > as to why this is not supported (if you have) would be simply great.
>
> To shed some more light into this: IET consists of a user space daemon
> that is responsible for iSCSI login and discovery sessions. and a kernel
> module that handles normal sessions in full feature phase (IOW, mainly the
> actual data transfers).

Thanks for the clarification.

> iSCSI login is performed using 8k PDUs (hence the
> INCOMING_BUFSIZE). While discovery sessions might use larger PDUs /
> several PDUs to transfer the target lists IIRC, it just wasn't
> implemented yet.

Hope this does not count as cross-question, but is there any specific reason
as to why 8K size of PDU has been preferred. I agree it could have been a
decision keeping in mind the resulting network overload, but probably, if one
is not able to add more than 90-100 devices using this on an enterprise level,
it would not serve the purpose of being enterprise applicable.

To clarify, assuming that I manage to collect that many target devices,
Can I simply change INCOMING_BUFSIZE to something like 131072?

Besides the network load, do you think that it would harm any other component
or working of IETd? I have a 10G network at disposal and a 4GBps FC card
on the target machine. Both, initiator and target, are running SLES10SP1.

Also, one naive question, is there some kind of test-suite which I can run to
confirm that the effect of this change (INCOMING_BUFSIZE = 131072) is not
adverse on any other working component of IET.

>
> HTH,
I certainly did, thanks!!

--
Shreyansh


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich-2]

Hi Shrey,

Shrey <shrey.linux+iscsitarget@...> writes:

> Hi Arne and List,
>
> Arne Redlich <agr <at> powerkom-dd.de> writes:
>> iSCSI login is performed using 8k PDUs (hence the
>> INCOMING_BUFSIZE). While discovery sessions might use larger PDUs /
>> several PDUs to transfer the target lists IIRC, it just wasn't
>> implemented yet.
>
> Hope this does not count as cross-question, but is there any specific reason
> as to why 8K size of PDU has been preferred.

Yes - as I wrote before (see above), 8k is the PDU size used during
login negotiation. This is mandated by the spec.

During this login negotiation initiator and target each declare the
maximum PDU size they're willing to receive (MaxRecvDataSegmentLength)
which  controls (together with other parameters) the segmentation of the
data to be transferred for both normal (SCSI-data transferring) as well as
discovery sessions. As I also wrote before, the latter is unfortunately
not fully implemented.
More details concerning the params can be found in the ietd.conf manpage
and of course in the iSCSI spec.

> I agree it could have been a
> decision keeping in mind the resulting network overload, but probably, if one
> is not able to add more than 90-100 devices using this on an enterprise level,
> it would not serve the purpose of being enterprise applicable.
>
> To clarify, assuming that I manage to collect that many target devices,
> Can I simply change INCOMING_BUFSIZE to something like 131072?

Ah well. It might work under some conditions, but with the above
explanation you'll hopefully understand that it violates the spec even
more than the current state of affairs for discovery sessions. In
particular you'll lose some sanity checks during login negotiation that
might lead to instabilities in conjunction with certain initiator
configurations. So you really shouldn't do that, except for toying around.

> Besides the network load, do you think that it would harm any other component
> or working of IETd? I have a 10G network at disposal and a 4GBps FC card
> on the target machine. Both, initiator and target, are running SLES10SP1.
>
> Also, one naive question, is there some kind of test-suite which I can run to
> confirm that the effect of this change (INCOMING_BUFSIZE = 131072) is not
> adverse on any other working component of IET.

Not that I know of, sorry.

Cheers,
Arne

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Boaz Harrosh-5]

Arne Redlich wrote:
> Shrey <shrey.linux+iscsitarget@...> writes:
<snip>
>> Also, one naive question, is there some kind of test-suite which I can run to
>> confirm that the effect of this change (INCOMING_BUFSIZE = 131072) is not
>> adverse on any other working component of IET.
>
> Not that I know of, sorry.
>
> Cheers,
> Arne
>

I use the regression test that comes with open-iscsi initiator. It is quite
heavy and found lots of bugs for me.

It's at test/regression.sh at your open-iscsi folder. It needs a couple of
external programs to run. Tell me if you don't manage to find everything.

Boaz


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Shreyansh]

Hi Boaz and List,

On Thu, May 22, 2008 at 10:01 PM, Boaz Harrosh <bharrosh@...> wrote:

> Arne Redlich wrote:
>> Shrey <shrey.linux+iscsitarget@...> writes:
> <snip>
>>> Also, one naive question, is there some kind of test-suite which I can run to
>>> confirm that the effect of this change (INCOMING_BUFSIZE = 131072) is not
>>> adverse on any other working component of IET.
>>
>> Not that I know of, sorry.
>>
>> Cheers,
>> Arne
>>
>
> I use the regression test that comes with open-iscsi initiator. It is quite
> heavy and found lots of bugs for me.
>
> It's at test/regression.sh at your open-iscsi folder. It needs a couple of
> external programs to run. Tell me if you don't manage to find everything.

Thanks for the information. I will certainly respond back once I have
studied everything.

Currently I am still searching through the code for possible
consequences of changing INCOMING_BUFSIZE to larger value and would it
actually affect any communication with the clients and devices. This
piece of info would be quite helpful here.

--
Shreyansh

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Shreyansh]

Hi List and Arne,

Actually I am posting on an old post which is inlined (dated 22 May)
and thus, I am not purging the contents.
Please see the reply inline.

On 5/22/08, Arne Redlich <agr@...> wrote:

> Hi Shrey,
>
>
>  Shrey <shrey.linux+iscsitarget@...> writes:
>
>  > Hi Arne and List,
>  >
>  > Arne Redlich <agr <at> powerkom-dd.de> writes:
>
> >> iSCSI login is performed using 8k PDUs (hence the
>  >> INCOMING_BUFSIZE). While discovery sessions might use larger PDUs /
>  >> several PDUs to transfer the target lists IIRC, it just wasn't
>  >> implemented yet.
>  >
>
> > Hope this does not count as cross-question, but is there any specific reason
>  > as to why 8K size of PDU has been preferred.
>
>  Yes - as I wrote before (see above), 8k is the PDU size used during
>  login negotiation. This is mandated by the spec.
>
>  During this login negotiation initiator and target each declare the
>  maximum PDU size they're willing to receive (MaxRecvDataSegmentLength)
>  which  controls (together with other parameters) the segmentation of the
>  data to be transferred for both normal (SCSI-data transferring) as well as
>  discovery sessions. As I also wrote before, the latter is unfortunately
>  not fully implemented.
>  More details concerning the params can be found in the ietd.conf manpage
>  and of course in the iSCSI spec.
>
>  > I agree it could have been a
>  > decision keeping in mind the resulting network overload, but probably, if one
>  > is not able to add more than 90-100 devices using this on an enterprise level,
>  > it would not serve the purpose of being enterprise applicable.
>  >
>  > To clarify, assuming that I manage to collect that many target devices,
>  > Can I simply change INCOMING_BUFSIZE to something like 131072?
>
>  Ah well. It might work under some conditions, but with the above
>  explanation you'll hopefully understand that it violates the spec even
>  more than the current state of affairs for discovery sessions. In
>  particular you'll lose some sanity checks during login negotiation that
>  might lead to instabilities in conjunction with certain initiator
>  configurations. So you really shouldn't do that, except for toying around.

I went through the iSCSI RFC 3720 and found the following lines in the
Section 5.1 (last paragraph)

-----8<------
 ....
  Any iSCSI target or initiator MUST support receiving at least 8192
  bytes of key=value data in a negotiation sequence.
 ....
-----8<----

Which is actually what Arne has been pointing to in the quoted
(inlined) text above. I also found the following lines in the SPEC (in
Section 5.1):

-----8<------
  ....
  Key=value pairs may span PDU boundaries.  An initiator or target that
  sends partial key=value text within a PDU indicates that more text
  follows by setting the C bit in the Text or Login Request or Text or
  Login Response to 1.  Data segments in a series of PDUs that have the
  C bit set to 1 and end with a PDU that have the C bit set to 0, or
  include a single PDU that has the C bit set to 0, have to be
  considered as forming a single logical-text-data-segment (LTDS).
  ....
-----8<----

>From above I understand that though the feature of multiple PDU for
discovery session has been part of the SPEC, it has not been
implemented in iscsitarget (also stated by Arne in an earlier
posting).

I searched the code for iscsitarget (0.4.16) and found that the
function sequence "event_loop() -> cmnd_execute() -> cmnd_exec_text()
-> text_scan_text()->target_list_build()" is responsible for packaging
a text discovery request by adding key value pair.  Function
target_list_build is responsible for controlling INCOMING_BUFSIZE data
in the response packet.

I have currently setup an environment which contains more than 100
Target devices and hence getting stuck in exposing all of them due to
this limitation of iscsitarget to pack more than 8K data (which
actually turns out to be 89 target devices only).

I am ready to modify the iscsitarget code so as to accommodate
multiple PDU spanning of discovery targets. Before I actually start
searching/investigating how to do this, I wanted to know whether this
work has already been done or is currently being done by anyone?

I still do not have much idea about the extent of change and specially
about maintaining the state between two consecutive PDU (so to start
from the target list from where last PDU ends. Nevertheless, I will
have a look as I need to get this working for my environment.

Any help/indication is really appreciated. In case someone feels that
this may not work out, please do let me know - it might help me in
investigating the feasibility of this change.

>
>  > Besides the network load, do you think that it would harm any other component
>  > or working of IETd? I have a 10G network at disposal and a 4GBps FC card
>  > on the target machine. Both, initiator and target, are running SLES10SP1.
>  >
>  > Also, one naive question, is there some kind of test-suite which I can run to
>  > confirm that the effect of this change (INCOMING_BUFSIZE = 131072) is not
>  > adverse on any other working component of IET.
>
>  Not that I know of, sorry.
>
>  Cheers,
>
> Arne
>

Warm Regards,
Shreyansh

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Arne Redlich-2]

Hi Shreyansh,

Am Freitag, den 08.08.2008, 16:10 +0530 schrieb Shreyansh Jain:

> I am ready to modify the iscsitarget code so as to accommodate
> multiple PDU spanning of discovery targets. Before I actually start
> searching/investigating how to do this, I wanted to know whether this
> work has already been done or is currently being done by anyone?

Great! I'm not aware of anyone else working on this. Let's discuss any
ideas you have early on the list.

Thanks,
Arne


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Iscsitarget-devel mailing list
Iscsitarget-devel@...
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel

[Shreyansh]

Hi Arne and List,

Arne Redlich-2 wrote:

Hi Shreyansh,

Am Freitag, den 08.08.2008, 16:10 +0530 schrieb Shreyansh Jain:

> I am ready to modify the iscsitarget code so as to accommodate
> multiple PDU spanning of discovery targets. Before I actually start
> searching/investigating how to do this, I wanted to know whether this
> work has already been done or is currently being done by anyone?

Great! I'm not aware of anyone else working on this. Let's discuss any
ideas you have early on the list.

Thanks for your reply.

I am currently analyzing the code for iscsitarget and finding what all areas I need to change to implement multiple packet. I could actually find multiple packet handling code in open-iscsi, so probably that could be one good help in this.
Just a little more investigation and I would push everything I could find here.

--
Shreyansh

[Shreyansh]

Hi List,

Shreyansh wrote:

Hi Arne and List,

Arne Redlich-2 wrote:

Hi Shreyansh,

Am Freitag, den 08.08.2008, 16:10 +0530 schrieb Shreyansh Jain:

> I am ready to modify the iscsitarget code so as to accommodate
> multiple PDU spanning of discovery targets. Before I actually start
> searching/investigating how to do this, I wanted to know whether this
> work has already been done or is currently being done by anyone?

Great! I'm not aware of anyone else working on this. Let's discuss any
ideas you have early on the list.

Thanks for your reply.

I am currently analyzing the code for iscsitarget and finding what all areas I need to change to implement multiple packet. I could actually find multiple packet handling code in open-iscsi, so probably that could be one good help in this.
Just a little more investigation and I would push everything I could find here.

--
Shreyansh

While searching/understanding the iscsitarget code, I could infer that the Login process also does not support multiple PDU in case the key pair data expands more than a single PDU size.
I noticed in text_scan_login() function, as text_key_add() function doesn't return anything, any case of packet overflow is silently ignored. Am I write?

As for the discovery case (sharing the target list), following is a quick roundup of what I am thinking for modifications to handle multiple PDU responses:

1. Need to change the text_add_key function so that it can respond to calling function about a packet overflow.
2. Target_list_build() function needs to know the last device it sent in the last discovery request's response so that it can start with a fresh target_device_name in the new response.
3. Function called by cmnd_exec_text (... -> target_list_build -> text_key_add ) need to convey back about possible multiple PDU response case  - on which, cmnd_exec_text() would set the itt, ttt, and F bit appropriately for the response PDU.
4. Checking for invalidation by initiator of a currently undergoing multiple PDU transaction. This can be done by checking the ttt field (where? .. still have to figure that out).
5. A new State has to be created to maintain in between the multiple PDU transaction - which would be before STATE_FULL and after STATE_LOGIN_FULL

What I still need to figure out is:

1. How to tell which target_device key to start with in the next (continuation) response packet. Probably a new variable(s) in the connection data structure can maintain that (don't know how (feasible is that). *** Comments/suggestion are 'really' welcome on this ***

part of task still pending:
1. Changing the log-in process to support the return values of text_add_key function and hence be able to support multiple PDU spanning.

Although this isn't a concrete information by any standard, hopefully it can muster some comments from all list reader so that I get more pointers/flaw in the thinking process. I will further update this thread as and when I make more progress (or get stuck).

Thanks for all your help. Comments/Suggestions are all truly welcome.

Shreyansh

(Do apologize in case this isn't the right way to develop/discuss an open-source code/project, as I am really a newbie in this department)