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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 20 Jul 2008 16:59:11 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	hadi@...erus.ca
Cc:	kaber@...sh.net, netdev@...r.kernel.org, johannes@...solutions.net,
	linux-wireless@...r.kernel.org
Subject: Re: [PATCH 20/31]: pkt_sched: Perform bulk of qdisc destruction in
 RCU.

From: jamal <hadi@...erus.ca>
Date: Sun, 20 Jul 2008 18:32:50 -0400

> pfifo_fast would be a bad choice in that case, but even a pfifo cannot
> guarantee proper RR because it would present packets in a FIFO order
> (and example the first 10 could go to hardware queue1 and the next to
> hardware queue2).

Jamal, I have to wonder why are you so hung up on matching our
software qdiscs with whatever fairness algorithm the hardware happens
to implement internally for the TX queues?

Every time this topic comes up, you insist on them having to match.
And I have no idea why.

It's largely irrelevant and the TX queue can be viewed purely as a
buffer between us and the device, nearly a black hole we stick packets
into.

> > These things are built for parallelization, not prioritization.
> 
> Total parallelization happens in the ideal case. If X cpus classify
> packets going to X different hardware queueus each CPU grabs only locks
> for that hardware queue.

The problem is that the bottleneck is the qdisc itself since all those
cpus synchonize on it's lock.  We can't have a shared qdisc for the
device and get full parallelization.

That's why we're having one qdisc per TX queue, so that they all don't
bunch up on the qdisc lock.

Otherwise, there is zero point in all of these TX multiqueue features
in the hardware if we can't parallelize things fully.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists