netdev - Re: [PATCH net-next-2.6] sched: use xps information for qdisc NUMA affinity

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:	Tue, 30 Nov 2010 19:39:37 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Tom Herbert <therbert@...gle.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Ben Hutchings <bhutchings@...arflare.com>
Subject: Re: [PATCH net-next-2.6] sched: use xps information for qdisc NUMA
 affinity

Le mardi 30 novembre 2010 à 10:31 -0800, Tom Herbert a écrit :
> On Mon, Nov 29, 2010 at 10:14 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > I was thinking of using XPS tx_queue->cpu mapping to eventually allocate
> > memory with correct NUMA affinities, for qdisc/class stuff for example.
> >
> 
> An interesting idea, but the real question is can this be used for all
> queue related allocations.  This includes those that drivers allocate
> which are probably done in initialization.
> 

This would need a callback to device, to eventually re-allocate its ring
buffer (or whatever data structures it allocated). Probably worth it,
considering size of txbd on some NICS (up to one cache line per entry)

Right now, they tend to allocate their memory on a single NUMA node, so
it is a problem.



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