title: Socket recv buffer size
body: <p>My question is about sockets programming in Python on Linux, but since Python's <code>socket</code> module is just a wrapper over system calls (<code>recv</code>, <code>recvfrom</code> etc.), it's not strongly about Python.</p>
  
  <p>So, according to <a href="https://docs.python.org/2/library/socket.html#socket.socket.recv" rel="nofollow noreferrer">docs</a>, when we call a <code>recv</code> method, </p>
  
  <blockquote>
    <p>For best match with hardware and network realities, the value of bufsize should be a relatively small power of 2, for example, 4096</p>
  </blockquote>
  
  <p>What does it mean?</p>
  
  <blockquote>
    <p>best match with hardware and network realities</p>
  </blockquote>
  
  <p>Mostly I care about the performance.</p>
  
  <p>Will it be a bottleneck in my network software, if I pass my custom buffer (that I use as a data container later in my code, it's just a <em>memoryview</em> if it matters) with some <em>not-power-of-two</em> custom size to <a href="https://docs.python.org/2/library/socket.html#socket.socket.recv_into" rel="nofollow noreferrer">socket.recv_into</a> method? </p>
  
  <p>It'll be just one line of code, clear and short.</p>
  
  <p>But my buffer's size can be 17 or 51 or whatever, so I'm wondering, should I implement some internal ring-like buffer with a "good" size (like 4096) and use it to read the data from a socket in chunks with such a "good" size and write it there, and then copy to my buffer?</p>
  
  <p>Does it have any sense in terms of performance?</p>
  
  <p>Or my current scheme (when I read the data from a socket in chunks with a "bad" size, that doesn't match "power of 2" rule) is fine?</p>
  
  <p>In other words: will it affect the performance, if we read from sockets in chunks with 1023 size, rather than 1024? </p>