netdev - Re: qdisc running

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 20 Oct 2014 18:17:56 +0200
From:	Jesper Dangaard Brouer <brouer@...hat.com>
To:	Jamal Hadi Salim <jhs@...atatu.com>
Cc:	john Fastabend <john.r.fastabend@...el.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	eric Dumazet <edumazet@...gle.com>, brouer@...hat.com,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: qdisc running


On Sun, 19 Oct 2014 15:24:42 -0400 Jamal Hadi Salim <jhs@...atatu.com> wrote:

> Jesper,
> 
> You asked at the meeting the point to qdisc running.

Talking about __QDISC___STATE_RUNNING see slide 9/16:
 http://people.netfilter.org/hawk/presentations/LinuxPlumbers2014/performance_tx_qdisc_bulk_LPC2014.pdf

> Original intent is to allow only one cpu to enter the lower half of the
> qdisc path. IOW, if one cpu was already in the qdisc then that guy
> could be used to dequeue packets. i.e this is good for batching.
> Original idea was Herbert's with major improvement from Eric
> and a small one from me.

I guess it is good for our recent dequeue batching. But I think/hope we
can come up with a scheme that does not requires 6 lock/unlock
operations (as illustrated on slide 9).

John and I have talked about doing a lockless qdisc, but maintaining
this __QDISC___STATE_RUNNING in a lockless scenario, would cost us
extra atomic ops...

Are we still sure, that this model of only allowing a single CPU in the
dequeue path, is still the best solution?  (The TXQ lock should already
protect several CPUs in this code path).


> For history of different tried approaches look at:
> Look at slide 2: 
> http://vger.kernel.org/netconf2011_slides/jamal_netconf2011.pdf

I can see that you really needed the budget/fairness in the dequeue
loop, that we recently mangled with.

> then download the **amazing** flash animations which describe
> that history.
> http://vger.kernel.org/netconf2011_slides/netconf-2011-flash.tgz
> 
> Follow the bullets in slide2 and map to the flash animations.

What tool do I use to play these SWF files? (I tried VLC but no luck).

> If you go over them, you'll see it is still needed.

Too bad, I would like to avoid the second 
 
> I think someone oughta put those **amazing** animations on some
> website;->

I hope someone else can pick that up ;-)

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer
--
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