Skip to content

Allow to configure socket option SO_BUSY_POLL#8268

Merged
normanmaurer merged 1 commit intonetty:4.1from
merlimat:so_busy_poll
Sep 7, 2018
Merged

Allow to configure socket option SO_BUSY_POLL#8268
normanmaurer merged 1 commit intonetty:4.1from
merlimat:so_busy_poll

Conversation

@merlimat
Copy link
Copy Markdown
Contributor

@merlimat merlimat commented Sep 6, 2018

Motivation:

When using Epoll based transport, allow applications to configure SO_BUSY_POLL socket option:


       SO_BUSY_POLL (since Linux 3.11)
              Sets the approximate time in microseconds to busy poll on a
              blocking receive when there is no data.  Increasing this value
              requires CAP_NET_ADMIN.  The default for this option is con‐
              trolled by the /proc/sys/net/core/busy_read file.

              The value in the /proc/sys/net/core/busy_poll file determines
              how long select(2) and poll(2) will busy poll when they oper‐
              ate on sockets with SO_BUSY_POLL set and no events to report
              are found.

              In both cases, busy polling will only be done when the socket
              last received data from a network device that supports this
              option.

              While busy polling may improve latency of some applications,
              care must be taken when using it since this will increase both
              CPU utilization and power usage.

Modification:

  • Added SO_BUSY_POLL socket option

Result:

  • Able to configure SO_BUSY_POLL from Netty

@normanmaurer
Copy link
Copy Markdown
Member

normanmaurer commented Sep 7, 2018

@merlimat this looks good... After reading https://blog.cloudflare.com/how-to-achieve-low-latency/ I wonder why SO_BUSY_POLL would be preferred from just busy poll via user-space. Any pointers ?

@merlimat
Copy link
Copy Markdown
Contributor Author

merlimat commented Sep 7, 2018

I think the difference is that SO_BUSY_POLL uses support from the NIC itself. It should be supported in most interfaces For example:

ethtool -k eth0 | grep poll
busy-poll: on [fixed]

while on loopback, for example it's not supported:

ethtool -k lo | grep poll
busy-poll: off [fixed]

My understanding is that it should move the packets from NIC to TCP stack with less delay.

According to https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/performance_tuning_guide/sect-red_hat_enterprise_linux-performance_tuning_guide-networking-configuration_tools :

Busy polling helps reduce latency in the network receive path by allowing socket layer code to poll the receive queue of a network device, and disabling network interrupts. This removes delays caused by the interrupt and the resultant context switch. However, it also increases CPU utilization. Busy polling also prevents the CPU from sleeping, which can incur additional power consumption.

@normanmaurer normanmaurer added this to the 4.1.30.Final milestone Sep 7, 2018
@normanmaurer normanmaurer self-assigned this Sep 7, 2018
@normanmaurer normanmaurer merged commit 2a1596a into netty:4.1 Sep 7, 2018
@normanmaurer
Copy link
Copy Markdown
Member

normanmaurer commented Sep 7, 2018

@merlimat thanks... merged it.

@merlimat merlimat mentioned this pull request Sep 7, 2018
Merged
@merlimat merlimat mentioned this pull request Nov 9, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@normanmaurer normanmaurer normanmaurer approved these changes

Assignees

@normanmaurer normanmaurer

Labels

feature improvement

Projects

None yet

Milestone

4.1.30.Final

Development

Successfully merging this pull request may close these issues.

2 participants

@merlimat @normanmaurer