On Mon, 28 Nov 2016 13:21:41 +0100 Jesper Dangaard Brouer
wrote:
> On Mon, 28 Nov 2016 11:52:38 +0100 Paolo Abeni wrote:
> >
> > > > [2] like [1], but using the minimum number of flows to saturate the
> > > > user space
> > > > sink, that is 1 flow for the old kernel and 3 for the patched
On Mon, 28 Nov 2016 11:52:38 +0100
Paolo Abeni wrote:
> Hi Jesper,
>
> On Fri, 2016-11-25 at 18:37 +0100, Jesper Dangaard Brouer wrote:
> > > The measured performance delta is as follow:
> > >
> > > before after
> > > (Kpps) (Kpps)
> > >
> > > udp flood[1]
Hi Jesper,
On Fri, 2016-11-25 at 18:37 +0100, Jesper Dangaard Brouer wrote:
> > The measured performance delta is as follow:
> >
> > before after
> > (Kpps) (Kpps)
> >
> > udp flood[1]570 1800(+215%)
> > max tput[2] 185035
On Fri, 2016-11-25 at 16:39 +0100, Paolo Abeni wrote:
> The goal of recvmmsg() is to amortize the syscall overhead on a possible
> long messages batch, but for most networking protocols, e.g. udp the
> syscall overhead is negligible compared to the protocol specific operations
> like dequeuing.
Pr
On Fri, 25 Nov 2016 16:39:51 +0100
Paolo Abeni wrote:
> The goal of recvmmsg() is to amortize the syscall overhead on a possible
> long messages batch, but for most networking protocols, e.g. udp the
> syscall overhead is negligible compared to the protocol specific operations
> like dequeuing.
The goal of recvmmsg() is to amortize the syscall overhead on a possible
long messages batch, but for most networking protocols, e.g. udp the
syscall overhead is negligible compared to the protocol specific operations
like dequeuing.
Moreover, the current recvmmsg() implementation has a long-stand
