On 31/03/11 09:46, Mike Christie wrote:
It looks like we are overqueueing after we relogin (we relogin to handle
the cable pull). It looks like the overqueue could be due to how we
reset the values after we relogin. We reset some of the values when we
should not and that causes us to think
A check for a bound session omitted the subscript for the first byte of
the array, forcing the check to always be true. This means that in the
case of a session not bound to an interface, the ss structure will not
be filled-in if the logging level is set to 0. This will prevent the
DCB priority
A check for a bound session omitted the subscript for the first byte of
the array, forcing the check to always be true. This means that in the
case of a session not bound to an interface, the ss structure will not
be filled-in if the logging level is set to 0. This will prevent the
DCB priority
Folks,
Sorry for the multiple mails. I had to change my postfix config to get mail to
work again and forgot to check that the earlier attempts were still in the
queue. Just know that they truly are duplicate - there are not multiple
versions of this patch.
--
Mark Rustad, LAN Access
Yes, i accept successful logging in to 246 targets.
2011/3/31 Or Gerlitz ogerl...@mellanox.com:
Again, as this goes linearly, I would expect you to be able to establish
twice the number of sessions you could before, that is 246 (2*123)
Yep, will try to help you on that front as well, see you
Степан Фёдоров wrote:
Next, i will try to create as many sessions as possible at this
configuration, and report results.
Again, as this goes linearly, I would expect you to be able to establish
twice the number of sessions you could before, that is 246 (2*123)
And now, after resolving this
On 3/29/2011 11:42 PM, Mike Christie wrote:
I would like to see if anyone would have objections to moving the
mailing list to http://vger.kernel.org/. It is where the linux-kernel,
netdev, scsi (almost all kernel lists) are handled.
Yes, lets do that please, the sooner, the better. I would
Mike,
Thank you again for your response!
I didn't see any problem on iscsi layer but there is what I saw.
When I run with default queue size settings:
node.session.cmds_max = 128
node.session.queue_depth = 32
And trying to push to sg device more than or near 32 outstanding
commands I noticed
On 03/31/2011 03:56 AM, Matthew Richardson wrote:
On 31/03/11 09:46, Mike Christie wrote:
It looks like we are overqueueing after we relogin (we relogin to handle
the cable pull). It looks like the overqueue could be due to how we
reset the values after we relogin. We reset some of the values
On 03/31/2011 01:52 PM, Mark Rustad wrote:
A check for a bound session omitted the subscript for the first byte of
the array, forcing the check to always be true. This means that in the
case of a session not bound to an interface, the ss structure will not
be filled-in if the logging level is
On 03/31/2011 05:11 AM, Evgeny_Schmeilin wrote:
Mike,
Thank you again for your response!
I didn't see any problem on iscsi layer but there is what I saw.
When I run with default queue size settings:
node.session.cmds_max = 128
node.session.queue_depth = 32
And trying to push to sg device more
11 matches
Mail list logo
