On Mon, 2016-12-05 at 16:37 +0100, Jesper Dangaard Brouer wrote:
> Do you think the splice technique would, have the same performance
> benefit as having a MPMC queue with separate enqueue and dequeue locking?
> (like we have with skb_array/ptr_ring that avoids cache bouncing)?
I believe ring buf
On Mon, 05 Dec 2016 06:28:53 -0800 Eric Dumazet wrote:
> On Mon, 2016-12-05 at 14:22 +0100, Paolo Abeni wrote:
> >
> > On Sun, 2016-12-04 at 18:43 -0800, Eric Dumazet wrote:
[...]
> > > But I also want to work on the idea I gave few days back, having a
> > > separate queue and use splice to
On Mon, 2016-12-05 at 14:22 +0100, Paolo Abeni wrote:
> Hi Eric,
>
> On Sun, 2016-12-04 at 18:43 -0800, Eric Dumazet wrote:
> > We currently access 3 cache lines from an skb in receive queue while
> > holding receive queue lock :
> >
> > First cache line (contains ->next / prev pointers )
> > 2nd
Hi Eric,
On Sun, 2016-12-04 at 18:43 -0800, Eric Dumazet wrote:
> We currently access 3 cache lines from an skb in receive queue while
> holding receive queue lock :
>
> First cache line (contains ->next / prev pointers )
> 2nd cache line (skb->peeked)
> 3rd cache line (skb->truesize)
>
> I beli
We currently access 3 cache lines from an skb in receive queue while
holding receive queue lock :
First cache line (contains ->next / prev pointers )
2nd cache line (skb->peeked)
3rd cache line (skb->truesize)
I believe we could get rid of skb->peeked completely.
I will cook a patch, but basical
