netdev - Re: [PATCH net-next] xps: fix xps for stacked devices

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] [day] [month] [year] [list]

Message-ID: <1426204973.11398.177.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Thu, 12 Mar 2015 17:02:53 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Cong Wang <cwang@...pensource.com>
Cc:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Willem de Bruijn <willemb@...gle.com>,
	Nandita Dukkipati <nanditad@...gle.com>,
	Yuchung Cheng <ycheng@...gle.com>
Subject: Re: [PATCH net-next] xps: fix xps for stacked devices

On Thu, 2015-03-12 at 16:48 -0700, Cong Wang wrote:

> I am trying to understand this, and wondering how possible CPUC or the CPU
> whichever faster can dequeue P2 instead of P1? Since we always dequeue
> from root qdisc and take the root qdisc lock before dequeue, the order should
> be guaranteed?
> 
> Also, since CPUA enqueues P1 and P2, the root qdisc is supposed to schedule
> on CPUA too, in which case it is CPUB or CPUC which can run dequeue()?
> Looks like htb schedules the root qdisc by itself, but it schedules the work
> on the same cpu with dequeue(), the hrtimer is pinned as well, so I don't
> see the possibility.

The trick is that bond0 (qdisc_run()) can dequeue a bunch of packets,
that were queued by CPUX, CPUZ, CPUT, from CPUB.

So the next enqueues (to slaves) will appear to happen from CPUB.

We want XPS to respect the original cpu, not the victim servicing bond0
qdisc.






--
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