iscsi: Handle large Text responses.

[jhb]

Summary

Text requests and responses can span multiple PDUs. In that case,
the sender sets the Continue bit in non-final PDUs and the Final
bit in the last PDU. The receiver responds to non-final PDUs with
an empty text PDU.

To support this, add a more abstract API in libiscsi which accepts
and receives key sets rather than PDUs. These routines internally
send or receive one or more PDUs. Use these new functions to replace
the handling of TextRequest and TextResponse PDUs in discovery sessions
in both ctld and iscsid.

Note that there is not currently a use case for large Text requests
and those are still always sent as a single PDU. However, discovery
sessions can return a text response listing targets that spans
multiple PDUs, so the new API supports sending and receiving multi-PDU
responses.

Reported by: Jithesh Arakkan @ Chelsio
Sponsored by: Chelsio Communications

[mav]

I may be wrong, but I have some suspicions about the protocol.

lib/libiscsi/text.c

213 ↗

(On Diff #100239)

RFC tells in 11.11.1:

A Text Response with the
F bit set to 1 in response to a Text Request with the F bit set to 0
is a protocol error.

302 ↗

(On Diff #100239)

As I read RFC, 0xffffffff should be there only on the first request, but if there is more than one, later should reflect back value sent by the target. In 11.10.4:

The target sets the Target Transfer Tag in a Text Response to a value
other than the reserved value 0xffffffff whenever it indicates that
it has more data to send or more operations to perform that are
associated with the specified Initiator Task Tag.  It MUST do so
whenever it sets the F bit to 0 in the response.  By copying the
Target Transfer Tag from the response to the next Text Request, the
initiator tells the target to continue the operation for the specific
Initiator Task Tag.

327 ↗

(On Diff #100239)

And respectively it should not be 0xffffffff here and it should not be final, since we'll still respond.

354 ↗

(On Diff #100239)

I think here should be the same ttt as we possibly selected in text_read_request().

[jhb]

lib/libiscsi/text.c

213 ↗

(On Diff #100239)

Hmm, I may just remove support for large requests then. Linux only supports large responses (and it is all I need in my use case of using cxgbei with small PDU sizes and a lot of targets). The explicit example of a large response in 11.10.4 is this:

Long Text Responses are handled as shown in the following example:

      I->T Text SendTargets=All (F = 1, TTT = 0xffffffff)

      T->I Text <part 1> (F = 0, TTT = 0x12345678)

      I->T Text <empty> (F = 1, TTT = 0x12345678)

      T->I Text <part 2> (F = 0, TTT = 0x12345678)

      I->T Text <empty> (F = 1, TTT = 0x12345678)

      ...

      T->I Text <part n> (F = 1, TTT = 0xffffffff)

302 ↗

(On Diff #100239)

This is due to my trying to infer how to handle large requests (vs large responses). I may just remove the large request support since I don't have an easy way to test it anyway as noted above. Same applies below.

[jhb]

• Drop support for Text Requests that span PDUs.

[mav]

Looks good to me.