[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1480113022.8455.580.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Fri, 25 Nov 2016 14:30:22 -0800
From: Eric Dumazet <eric.dumazet@...il.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jesper Dangaard Brouer <brouer@...hat.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Sabrina Dubroca <sd@...asysnail.net>
Subject: Re: [PATCH net-next 4/5] net/socket: add helpers for recvmmsg
On Fri, 2016-11-25 at 16:39 +0100, Paolo Abeni wrote:
> _skb_try_recv_datagram_batch dequeues multiple skb's from the
> socket's receive queue, and runs the bulk_destructor callback under
> the receive queue lock.
...
> + last = (struct sk_buff *)queue;
> + first = (struct sk_buff *)queue->next;
> + skb_queue_walk(queue, skb) {
> + last = skb;
> + totalsize += skb->truesize;
> + if (++datagrams == batch)
> + break;
> + }
This is absolutely not good.
Walking through a list, bringing 2 cache lines per skb, is not the
proper way to deal with bulking.
And I do not see where 'batch' value coming from user space is capped ?
Is it really vlen argument coming from recvmmsg() system call ???
This code runs with BH masked, so you do not want to give user a way to
make you loop there 1000 times
Bulking is nice, only if you do not compromise with system stability and
latency requirements from other users/applications.
Powered by blists - more mailing lists