[tor-bugs] #12890 [Tor]: Design and implement optimizations for socket write limits

[Tor Bug Tracker & Wiki]

#12890: Design and implement optimizations for socket write limits
-----------------------------+--------------------------------
     Reporter:  robgjansen   |      Owner:  robgjansen
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-relay
Actual Points:               |  Parent ID:  #12541
       Points:               |
-----------------------------+--------------------------------

Comment (by dgoulet):

 Replying to [comment:5 robgjansen]:
 > '''Then we want setsockopt to set the buffer sizes based on the current
 length and the tcp window:'''
 >
 > {{{
 > setsockopt(fd, SOL_SOCKET, SO_SNDBUF, (void *)&snd_size, snd_size_len);
 > setsockopt(fd, SOL_SOCKET, SO_RCVBUF, (void *)&rcv_size, rcv_size_len);
 > }}}
 >
 > '''NOTE:''' When setting `SO_SNDBUF` and `SO_RCVBUF` with `setsockopt`,
 the value applied is double the valued passed (it is automatically doubled
 by the kernel).

 Here is some extra info on that, hope this can be useful:

 The kernel makes sure also that you do not go above
 {{{/proc/sys/net/core/wmem_max}}} for {{{SO_SNDBUF}}} and
 {{{/proc/sys/net/core/rmem_max}}} for {{{SO_RCVBUF}}}. Note that those are
 system wide thus should probably not be mangled by tor (unless the box is
 dedicated for tor traffic :). Furthermore, that value is multiplied by 2
 and must at least be a certain minimum. (Below is a snippet from the
 3.18.0 kernel).

 {{{
 #define TCP_SKB_MIN_TRUESIZE    (2048 + SKB_DATA_ALIGN(sizeof(struct
 sk_buff)))

 #define SOCK_MIN_SNDBUF     (TCP_SKB_MIN_TRUESIZE * 2)
 #define SOCK_MIN_RCVBUF      TCP_SKB_MIN_TRUESIZE

 sk->sk_sndbuf = max_t(u32, val * 2, SOCK_MIN_SNDBUF);
 sk->sk_rcvbuf = max_t(u32, val * 2, SOCK_MIN_RCVBUF);
 }}}

 The size of struct sk_buff is 232 bytes. Note that this is not considered
 a stable ABI for user space thus the size of sk_buff can vary over time.
 Also, the {{{SKB_DATA_ALIGN}}} is an alignement on the L1 cache but it's
 often only 32 bytes thus here sk_buff is actually aligned to 256 bytes.

 Having congestion control in user space is '''difficult''' vis-a-vis
 performance. For once, you have to do extra syscalls for every I/O
 operation but it's also a "play the guessing max size game" which is
 tightly controlled by the kernel.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12890#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online