svn commit: r265498 - stable/10/sys/dev/iscsi

[Edward Tomasz Napierała]

Wiadomość napisana przez Robert Watson w dniu 7 maj 2014, o godz. 13:49:
> On Wed, 7 May 2014, Edward Tomasz Napierala wrote:
> 
>> Author: trasz
>> Date: Wed May  7 06:38:19 2014
>> New Revision: 265498
>> URL: http://svnweb.freebsd.org/changeset/base/265498
>> 
>> Log:
>> MFC r264025:
>> 
>> Get rid of the "autoscaling", instead just set socket buffer sizes
>> in the usual way.  The only thing the old code did was making things
>> less predictable.
> 
> Does this mean that the autoscaling algorithm needs refining?  The problem with disabling autoscaling is that the code may, in the future, fail to benefit from further global refinements, as old code that hard-coded sizes now fails to do -- and that if we don't refine the autoscaling model, other applications may fail to benefit.

The commit message here was misleading - what got replaced was
setting the socket buffer size "by hand" to a value  computed from
negotiated maximum PDU size.  Now it's set to constant size.

The reason we do not use autoscaling here is not performance.
It's because iSCSI code can't transmit a part of PDU; it always waits
until there is room for the whole thing (PDUs can be up to about 128kB
in size). If the socket buffer size somehow got autoscaled below
that amount, the transmit would stop indefinitely.  There is a somewhat
similar situation on the receive side.

So, the right solution would be to either use autoscaling, but with
a guarantee that the socket buffer won't shrink below some specified
value, or have a way to determine that the socket buffer won't get any
bigger anytime soon and so the iSCSI should transmit or receive a part
of PDU.  Current setting "by hand" is just a workaround, albeit pretty
well working one.