TCP issue with large packet under RTEMS

[Eric Norum]

On Feb 9, 2011, at 9:10 AM, João Rasta wrote:

> Hi Joel, Eric,
> 
> I followed Eric's suggestion and it worked. I thought that read() should be automatically blocking untill all numelements passed to the read() function were read. I wonder why read() exits without this condition to fulfill..

Because those are the semantics of read() from sockets ever since BSD Unix introduced them (and for reads from pipes ever since the dawn of UNIX).
For example, here's a snippet from the read(2) manual entry for Linux:

RETURN VALUE
	On success, the number of bytes read is returned (zero indicates end of
       file), and the file position is advanced by this number.  It is not  an
       error  if  this  number  is smaller than the number of bytes requested;
       this may happen for example because fewer bytes are actually  available
       right  now  (maybe  because we were close to end-of-file, or because we
       are reading from a pipe, or from a terminal), 


and for Mac OS X:
     Upon successful completion, read(), readv(), and pread() return the num-
     ber of bytes actually read and placed in the buffer.  The system guaran-
     tees to read the number of bytes requested if the descriptor references a
     normal file that has that many bytes left before the end-of-file, but in
     no other case.


> 
> Joel, how can i increase the TCP/IP stack size in order to get more performance out of the read routine? I mean, using only one system call to get the whole data would be perfect. Previously the application did not lock, it simply returned the read with less bytes than the buffer size and continued executing.

The reads are already happening in pretty big chunks.  I doubt that you'll see a significant performance improvement by hacking the  kernel.

-- 
Eric Norum
wenorum at lbl.gov