Let's see if I get the facts right:

  So  the  current behavior of   fused  connections is to call
  tcp_setqfull()  from   tcp_fuse_output() when  there  are  N
  outstanding writes waiting to be read. The following write()
  will then block  until data is read.  N is  (socket buffer /
  16K) which equals to 8 out of the box.

  When the read thread is the choke point, this will limit the
  size that will be given  to  each read  to be  at most "N  *
  write size".

  This was observed to help an important benchmark because, by
  blocking the writes, it gives  more time to the  application
  to  gather more  data for larger   subsequent writes (and so
  also larger reads).

  The original fuse code was suboptimal because it lead to
  small write & small read and frequent wakeups.

  The application works well over a network where Nagle helps
  in making transfers bigger and thus bigger reads (but write
  size are not impacted by Nagle).


Is this it ?

-r

_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to