Request regarding CHAN_INPUT_MAX

[Chris Rapier]

On 4/9/26 19:05, Damien Miller wrote:
> On Thu, 9 Apr 2026, Chris Rapier wrote:
> 
>> Hi all,
>>
>> Is there any way that the limit of CHAN_INPUT_MAX could be increased?
>>
>> In channels.h it's set to 16MB.
>> #define CHAN_INPUT_MAX  (16*1024*1024)
>>
>> Which is fine for most implementations of SSH but it's causing performance
>> degradation when OpenSSH is sending data to an HPN-SSH instance. I'm currently
>> dealing with this by limiting the advertised window to less than 16MB but that
>> limits throughput in this situations. While I'd love it if this was increased
>> to 128MB an increase to 32MB or more would help out a lot of my users (people
>> often install HPN-SSH on the server side as it provides a throughput boost to
>> any client sending data). If HPN-SSH advertises more than that to these
>> clients the connection might fail or enter a pathological state in terms of
>> performance.
> 
> That's the pathological state here? INPUT_MAX sets the maximum size of the
> buffer for data that has been locally read by not yet put on the wire.
> > If the server has advertised a larger channel window then I'd assume that
> this buffer should pretty much always be empty as it will be drained to
> the wire by channel_output_poll_input_open() in maxpacket increments.

I'm running this traffic generator test on localhost.
./hpnssh localhost -p22 "cat /dev/zero" > /dev/null
For the first couple of seconds I'm seeing throughput rates of about 
3.6Gbps. Then I hit a CC20 rekey and the rate drops to less than a tenth 
of that. It then ramps back up to the next rekey. However, by the 5th or 
6th rekey it doesn't ramp back up and stays stuck at around 200Mbps. 
While this test is running on localhost and there's no actual delay I 
still need to open the window for optimal throughput. It's more 
noticeable when I inject delay.

The interesting thing is that the OpenSSH client still has the CPU 
pegged at 100%. I think this is happening because once the initial 
allocation is exceeded the client is trying to grow the window to meet 
the advertised size in 32KB allocs. That would be really expensive and 
pretty slow (explaining both the speed and CPU usage (I ran into that 
with hpnssh which is why I grow that buffer in much larger chunks what 
is passes a threshold size)).

Of course, I'm not sure this is the problem because it usually stays in 
this low throughput state without recovering - which i would expect if 
it was a delay caused by memory allocation. It might also be an 
interaction between sshbuf at larger advertised windows and rekeying. 
Honestly, I haven't been able to trace deeply enough to know for sure.

By restricting the advertised window to the maximum of the OpenSSH 
client I can at least get a ~16MB receive window. If you can increase 
the limit to 32MB (or whatever) I can improve throughput when OpenSSH 
clients are sending data to HPN-SSH.

I can spend some more time nailing this down if you are potentially open 
to this change.