changes to node.session.queue_depth doesn't take effect?

484 views
Skip to first unread message

Neutron Sharc

unread,
Jun 27, 2018, 3:34:56 PM6/27/18
to open-iscsi
Hi all,

I will describe the problem I saw step by step. Please take patience.

I'm using tgt as iscsi target server (fujita/tgt from github) on Ubuntu 16.04.  iscsi initiator runs the stock open-iscsi coming with Ubuntu 16.04.

The default "/etc/iscsi/iscsid.conf" defines "node.session.queue_depth = 32".  I changed it to 128, and run "sudo iscsid restart".  Then I log in to an iscsi target.

However, " iscsiadm -m node -p xxx  -T yyy" shows my iscsi session still uses "queue_depth" as 32, not 128.

Then I run  "iscsiadm -m node -p xxx -T yyy --op update -n node.session.queue_depth  -v 128" to forcefully change the value. 

This time "iscsiadm -m node" shows the correct "128" value I set.

Now I run fio benchmark with a large queue size (1024),  and keeps monitoring iscsi target.  I had a patch in tgt to report the current live commands received on a connection.
To my surprise, this max "queued_cmd" is always 32, not 128,  no matter how hard I push fio queue size.

I was expecting that,  since I set initiator  session.queue_depth to 128,  the target should receive a max 128 cmds in its queue. 

I want the initiator to push as many requests as possible to target to get more bandwidth.  However the target only receives up to 32 outstanding cmds from initiator.  Why doesn't initiator push more?

Is my understanding about "node.session.queue_depth" correct?



-Shawn



The Lee-Man

unread,
Jul 25, 2018, 3:01:17 PM7/25/18
to open-iscsi
I _believe_ that queue_depth, in this context, ralates to the cmdsn (command sequence number) window that the iscsi transport will allow, i.e. how many iSCSI commands can be active at one time? But that's from a really quick glance at the code.

Also, as far as setting it in iscsid.conf, that doesn't effect any current node records. You can change the node "queue_depth" value using "iscsiadm -m node ... --name node.session.queue_depth --value SOME_NUMBER"

Reply all
Reply to author
Forward
0 new messages