Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

net: use recvmmsg on Linux #3661

Closed
gopherbot opened this issue May 22, 2012 · 14 comments
Closed

net: use recvmmsg on Linux #3661

gopherbot opened this issue May 22, 2012 · 14 comments
Labels
FrozenDueToAge
Milestone
Unplanned

Comments

@gopherbot
Copy link
Contributor

by teixeiradavid:

Hello,

Go should implement the recvmmsg linux syscall to improve peformance.
The option to use either "recvmmsg" or "recvmsg" should be available
on higher level packages like "net" when reading from a socket.

This would be a huge plus for small packet processing.

Thanks.
David.
@gopherbot
Copy link
Contributor Author

Comment 1 by teixeiradavid:

link for the kernel commit :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a2e2725541fad72416326798c2d7fa4dafb7d337

@rsc
Copy link
Contributor

rsc commented May 22, 2012

Comment 2:

Package net - a portable API - is certainly not going to grow an option just to support
the Linux system call flavor of the week.
If we do anything, it would be to make the various calls to recvmsg use recvmmsg
transparently when that's available.  However, it is unclear to me how important this
really is.  I am pretty sure this is not yet a bottleneck in real code.

Labels changed: added priority-later, removed priority-triage.

Status changed to LongTerm.

@gopherbot
Copy link
Contributor Author

Comment 4 by teixeiradavid:

Hello, sorry for the mistake about using  an option in the net package.
This is important if you want to reduce latency on processing small packets (udp
mulicast for example), it is not a bottleneck, it's just more efficient.
Thanks.

@alexbrainman
Copy link
Member

Comment 5:

I am pretty sure, our current windows syscalls could support these too.
Alex

@anacrolix
Copy link
Contributor

Comment 6:

So is there a mac/plan9 equivalent of these? I understand Commander Rob isn't a fan of
extensions like this, can it be added say to go.net or something?

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 7:

It's fine to add these if you can't tell they're being used. API changes are not fine.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 8:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 9:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 10:

Labels changed: added repo-main.

@ianlancetaylor
Copy link
Member

Comment 11:

I don't see any way to use recvmmsg with the current net API (unless we add a buffer
which I think we do not want to do).

@anacrolix
Copy link
Contributor

Comment 12:

It would be pretty clean to add something like func (PacketConn) MultiRecv([][]byte)
([]int, err).

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@gopherbot
Copy link
Contributor Author

CL https://golang.org/cl/37039 mentions this issue.

@gopherbot
Copy link
Contributor Author

CL https://golang.org/cl/38275 mentions this issue.

@gopherbot
Copy link
Contributor Author

CL https://golang.org/cl/38276 mentions this issue.

gopherbot pushed a commit to golang/net that referenced this issue May 27, 2017
@cixtor
ipv4: add {Read,Write}Batch methods to {Packet,Raw}Conn

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode
b7a1f62 
This change provides message IO functionality that may support the
construction of modern datagram transport protocols.

The modern datagram transport protocols on a multihomed node basically
need to control each packet path for traffic engineering by using
information belongs to network- or link-layer implementation. In
addtion, it's desirable to be able to do simultaneous transmission
across multiple network- or link-layer adjacencies wihtout any
additional cost.

The ReadBatch and WriteBatch methods of PacketConn and RawConn can be
used to read and write an IO message that contains the information of
network- or link-layer implementation, and read and write a batch of
IO messages on Linux. The Marshal and Parse methods of ControlMessage
and Header can help to marshal and parse information contained in IO
messages.

Updates golang/go#3661.

Change-Id: Ia84a9d3bc51641406eaaf4258f2a3066945cc323
Reviewed-on: https://go-review.googlesource.com/38275
Run-TryBot: Mikio Hara <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
gopherbot pushed a commit to golang/net that referenced this issue May 27, 2017
@cixtor
ipv6: add {Read,Write}Batch methods to PacketConn
48359f4 
This change provides message IO functionality that may support the
construction of modern datagram transport protocols.

The modern datagram transport protocols on a multihomed node basically
need to control each packet path for traffic engineering by using
information belongs to network- or link-layer implementation. In
addtion, it's desirable to be able to do simultaneous transmission
across multiple network- or link-layer adjacencies wihtout any
additional cost.

The ReadBatch and WriteBatch methods of PacketConn can be used to read
and write an IO message that contains the information of network- or
link-layer implementation, and read and write a batch of IO messages
on Linux. The Marshal and Parse methods of ControlMessage can help to
marshal and parse information contained in IO messages.

Updates golang/go#3661.

Change-Id: I94484e2e135f4969ddf5c2548bf6be0cc16888bf
Reviewed-on: https://go-review.googlesource.com/38276
Run-TryBot: Mikio Hara <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
@golang golang locked and limited conversation to collaborators May 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@rsc @anacrolix @ianlancetaylor @gopherbot @alexbrainman