netdev - Re: [PATCH net-next 4/4] net_sched: generalize bulk dequeue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160622170323.27a24aee@redhat.com>
Date:	Wed, 22 Jun 2016 17:03:23 +0200
From:	Jesper Dangaard Brouer <brouer@...hat.com>
To:	Eric Dumazet <edumazet@...gle.com>
Cc:	"David S . Miller" <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	John Fastabend <john.r.fastabend@...el.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Florian Westphal <fw@...len.de>,
	Daniel Borkmann <daniel@...earbox.net>, brouer@...hat.com
Subject: Re: [PATCH net-next 4/4] net_sched: generalize bulk dequeue

On Tue, 21 Jun 2016 23:16:52 -0700
Eric Dumazet <edumazet@...gle.com> wrote:

> When qdisc bulk dequeue was added in linux-3.18 (commit
> 5772e9a3463b "qdisc: bulk dequeue support for qdiscs
> with TCQ_F_ONETXQUEUE"), it was constrained to some
> specific qdiscs.

Thanks for extending this!

> With some extra care, we can extend this to all qdiscs,
> so that typical traffic shaping solutions can benefit from
> small batches (8 packets in this patch).

I'm fine with limiting this to 8 packets (xmit_more), as that seem to
be the minimum needed TX batch size (according to Luigi's original
netmap article[1] figure 7) for doing 10G wirespeed.

[1] http://info.iet.unipi.it/~luigi/papers/20120503-netmap-atc12.pdf
 

> For example, HTB is often used on some multi queue device.
> And bonding/team are multi queue devices...
> 
> Idea is to bulk-dequeue packets mapping to the same transmit queue.
> 
> This brings between 35 and 80 % performance increase in HTB setup
> under pressure on a bonding setup :
> 
> 1) NUMA node contention :   610,000 pps -> 1,110,000 pps
> 2) No node contention   : 1,380,000 pps -> 1,930,000 pps
> 
> Now we should work to add batches on the enqueue() side ;)

Yes, please! :-))) That will be the next big step!


> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> Cc: John Fastabend <john.r.fastabend@...el.com>
> Cc: Jesper Dangaard Brouer <brouer@...hat.com>
> Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>
> Cc: Florian Westphal <fw@...len.de>
> Cc: Daniel Borkmann <daniel@...earbox.net>

Acked-by: Jesper Dangaard Brouer <brouer@...hat.com>

This is great stuff!

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer