FWIW I played with implementing readv (ReadFrom/Write) once (see cl/30102) and got some nice numbers (which I don't have anymore) in my tests. My implementation kept the current type and all calls to Write/ReadFrom just overwrote the old data. I didn't have a real use for it back than (and still currently don't have), but from the raw numbers I got it seemed like it could be easily used to speed up some tools (probably stuff like parsers, etc.)

You'd need to do something like:

As I understand your code ReadFrom would need to reslice net.Buffers to make WriteTo work properly. But what about Write? Would it append to the net.Buffers (and potentially adding a new slice) or only write as much as fits and return an error otherwise? If it appends a new slice users would need to remember to reuse it. Although Read/Write on net.Buffers will probably rarely be used, I'd like to have this clearly defined and though about.

Yeah, that copy is what I figured people caring about allocations could do.

I don't care whether readv support goes into Go 1.8 or later, though. @nuss-justin and @ianlancetaylor also seemed lukewarm on it. @ianlancetaylor said on that CL:

In a language like Go readv seems much less interesting than writev. It seems easy enough to read into a slice and then use slice expressions to pass around different versions to different places

As far as I can see, the only meaningful reason to use readv in Go is to assemble a list of slices into existing arrays, and read into them. So examples like Buffers{make([]byte, 0, 16)} seem to me to be somewhat uninteresting. What you really do is Buffers{hdr[:16], data[:1024]}. In that mode, what the Buffers type looks like after Buffers.ReadFrom(conn) does not seem very interesting. All you really need to know is how much data you got.

I guess I don't see why anybody would want to use the same Buffers value for reading and writing. In the cases where a scatter-read is valuable, I'm not going to want to do a gather-write from the same set of buffers. If I wanted to send the data through I would just use a straight []byte and use byte slices to analyze it as needed.

@ianlancetaylor, I don't know that anyone would necessarily want to reuse the Buffers type, but it seemed worth thinking through what it might look like.

I do want to make sure that we know how Buffers will support readv, or else that we know we will never want to support readv. If readv will need something different, the "Buffers" may not be the right name. I agree that Buffers{hdr[:16], data[:1024]} is the interesting case. However, it matters what the Buffers looks like after ReadFrom(conn) because you might expect to get everything in one read but actually need two reads. The second b.ReadFrom(conn) needs to correctly pick up where the previous one left off.

It does sound like we agree that the current Buffers definition has a reasonable way to support readv, though, so I'll punt the actual addition of readv to Go 1.9.

Making the Buffer a ring buffer seems better for reusing it even only for writev.

And what about sendmmsg/recvmmsg? They are more general than writev/readv but not as portable. Unlike writev, sendmmsg can write to unconnected sockets and multiple addresses, these could be useful for udp servers like QUIC. For now, you can use Buffer to write to a listening UDPConn, but will only get a error after doing the actual writev syscall, that matches the Write() behavior of UDPConn, so I guess it is not a problem.

+1 for supporting readv in net.Conn

I am working on a network proxy project. A proxy workflow (per connection) now looks like below:

1. Get a buffer ([]byte) from a sync.Pool
2. Fill in the buffer from an inbound connection.
3. Process the content (header, encoding, etc)
4. Send out the buffer through an outbound connection.
5. Release the buffer back to the pool.
6. Repeat until connection ends.

The problem is that it is difficult to determine the size of the buffer. Using a 32K or larger buffer can increase throughput for a single connection with large payload. But it increases (unnecessary) memory usage when there are many connections with little payload.

With net.Buffers.ReadFrom, I can do the following:

1. Get 10 of [2k]byte from the pool
2. Fill them in. Keep only the buffers that has content, say [5][2k]byte, and return the rest to the pool.
3. Process in the same way as usual.

In this way, the memory usage can automatic adapt for different network scenarios.

Can someone comment on the recvmmsg usage?

I don't see how the existing net.Buffers type can be used reasonable with the sendmmsg and recvmmsg system calls. Those calls include peer information that can not be represented in net.Buffers at all. I think we need a different mechanism.

A quick follow-up on this. We have implemented our own version of readv() in V2Ray, based on syscall.RawConn interface. As of Go 1.11, the reader works on all major operation systems.

The library is coupled with the rest of the project for the moment. If others are interested, we can make it standalone package.

@VictoriaRaymond how did you deal with EAGAIN? These are practically certain to occur because the file descriptor is in non-blocking mode.

AFAIK, we have two options:

• SetNonblock(false) => connection deadlines won't work because those are implemented using the event loop (poll.FD if I'm not mistaken)
• Treat EAGAIN like a zero-read and retry immediately. Effectively, this is busy-waiting.

Both of above options are not great.
We need runtime support.

I do not understand why https://go-review.googlesource.com/c/go/+/30102/ was abandoned due to missing application.
My not too atypical use case is the server implementation of a TLV-protocol (https://en.wikipedia.org/wiki/Type-length-value): One PDU is a very short header including payload length (8 bytes) followed by payload.
I use a buffer pool of round-up-to-power-of-2-buffers, which eliminates allocations and guarantees page alignment.
With that, the implementation is CPU-bound due to the two read syscalls.

One might argue that the following optimization is possbile:

• On the very first PDU read:
  • read one header (8 bytes)
  • fall through to the following rule (as for all subsequent PDU reads)
• Read the previous header's payload + the next header in one io.ReadFull call

However, on my Linux 4.9 system, above optimization results in two subsequent read syscalls: the first one is shorted by the kernel to the payload length, because the PDU-sender typically chooses payload lengths that are power-of-2.
The syscall latency induced by the second read can be fully avoided using readv.

@ianlancetaylor is it worthwile to condense that case down to an executable microbenchmark or are there other (political / resource) constraints prohibiting implementation of readv in Go?

@problame, CL/30102 was abandoned to "missing application" by the author's own admission. It is not a statement that no such application exists.

@problame I don't think there is any opposition to readv support. This issue is about how to implement it. I think it just hasn't been done.

(I'll note that I think it could be done today using the SyscallConn method and syscall.Syscall(SYS_READV, ...), but that is certainly not convenient.)

@ianlancetaylor what are your thoughts on the EAGAIN problem pointed out above? Is the assumption that, when using raw syscalls, we need to set the FD to blocking? Or is it possible to use read inside syscall.RawConn.Read?

The SyscallConn method gives you a way to block until a descriptor is readable. See https://golang.org/pkg/syscall/#RawConn .