Re: kern/45352: pty(4)/tty(4) have a 1024 bytes transfer limit

[christos%zoulas.com@localhost (Christos Zoulas)]

The following reply was made to PR kern/45352; it has been noted by GNATS.

From: christos%zoulas.com@localhost (Christos Zoulas)
To: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost, 
        gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
        Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
Cc: 
Subject: Re: kern/45352: pty(4)/tty(4) have a 1024 bytes transfer limit
Date: Sun, 25 Sep 2011 11:33:02 -0400

 On Sep 25,  9:45am, mm_lists%pulsar-zone.net@localhost (Matthew Mondor) wrote:
 -- Subject: Re: kern/45352: pty(4)/tty(4) have a 1024 bytes transfer limit
 
 |  I had some trouble with the patch then noticed that there were actually
 |  -current commits; so reverted to the -current files, then rebuilt a
 |  kernel and booted it.
 |  
 |  The sysctl setting works great, and with an actual MTU of 3000 this
 |  time, performance was over 800KB/s for the same file and my pty-udp
 |  software, vs the max ~170KB/s I was getting with the 1024 bytes limit!
 
 Great.
 
 |  However, there still seems to be a problem with the ioctl(2), as that
 |  one doesn't seem to have an effect, somehow:
 |  
 |          opt = (int)buffer_size;
 |          if (ioctl(fd, TIOCSQSIZE, &opt) == -1)
 |                  err(EXIT_FAILURE, "Couldn't set tty(4) buffer size");
 |  
 |  There is no error but the reads are still reaching the sysctl-set limit
 |  despite trying to set a larger buffer (that's of course still between
 |  1024 and 65536).
 
 I made your test program do the setting on both the master and the
 slave and that seems to work.
 
 |  Also, would there be a problem with setting the tty buffer size to 4096
 |  by default, rather than 1024?  This would then match the default Linux
 |  limit, and allow tools like rp-ppoe with common MTU sizes to work
 |  properly as-is as well.
 
 I don't think that it is a big deal, since it can be set via sysctl.
 We can surely change it.
 
 |  BTW, for those who wondered how rp-pppoe could have worked, note that
 |  it was previously possible with our 1024 limit, if not exceeding it too
 |  much (write size), to read in non-blocking mode until EAGAIN to obtain
 |  all bytes, yet at the expense of more syscalls and I/O, and the
 |  occasional loss of a few ending bytes depending on packet size.  I've
 |  not checked the rp-pppoe code in a while, but it might have done just
 |  that...
 
 Yes, that is what bugged me the most; the lost of trailing bytes. I think
 that I fixed that (I committed your test program and it does not seem
 to lose anymore).
 
 |  Interestingly, when doing earlier searches about the problem I was
 |  having before posting the initial PR, OS/X would also have the 1024
 |  limit, and Solaris would have an even worse 255 limit; I'm not sure if
 |  those are defaults or hard-coded, though.
 
 Yes, they seem to be hard-coded.
 
 |  Thanks again,
 
 Thanks for the test program which made testing easy!
 
 christos