Please do not top post on netdev
On Mon, 2017-03-27 at 18:08 -0700, Chris Kuiper wrote:
> Sorry, I have been transferring jobs and had no time to look at this.
>
> Josh Hunt's change seems to solve a different problem. I was looking
> for something that works the same way as SO_RXQ_OVERFL, provid
Sorry, I have been transferring jobs and had no time to look at this.
Josh Hunt's change seems to solve a different problem. I was looking
for something that works the same way as SO_RXQ_OVERFL, providing
information as ancillary data to the recvmsg() call. The problem with
SO_RXQ_OVERFL alone is
On 03/17/2017 05:01 PM, Eric Dumazet wrote:
On Fri, 2017-03-17 at 14:13 -0700, Chris Kuiper wrote:
This adds a new socket option "SO_RXQ_ALLOC" that enables providing
the RX queue buffer allocation as ancillary data from the recvmsg()
system call. The value reported is a byte number and together
On Fri, 2017-03-17 at 14:13 -0700, Chris Kuiper wrote:
> This adds a new socket option "SO_RXQ_ALLOC" that enables providing
> the RX queue buffer allocation as ancillary data from the recvmsg()
> system call. The value reported is a byte number and together with
> the RX queue size (obtained via g
This adds a new socket option "SO_RXQ_ALLOC" that enables providing
the RX queue buffer allocation as ancillary data from the recvmsg()
system call. The value reported is a byte number and together with
the RX queue size (obtained via getsockopt(SO_RCVBUF) can be used to
calculate a percentage valu
