netdev - Re: RFC [PATCH net-2.6 1/6] net: Scheduling softirqs between CPUSs

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:	Thu, 13 Mar 2008 11:47:19 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	David Miller <davem@...emloft.net>
Cc:	therbert@...gle.com, jesse.brandeburg@...el.com, maxk@...lcomm.com,
	netdev@...r.kernel.org, rostedt@...dmis.org, mingo@...e.hu
Subject: Re: RFC [PATCH net-2.6 1/6] net: Scheduling softirqs between CPUSs

David Miller wrote:
> From: Ben Hutchings <bhutchings@...arflare.com>
> Date: Wed, 12 Mar 2008 15:10:52 +0000
> 
> > It's not supported, but it's on David Miller's to-do list[1].
> ...
> > 1. http://vger.kernel.org/~davem/net_todo.html
> 
> That copy of the TODO list is out of date, and we fully
> support multiqueue RX devices, it's a device driver level
> issue at this point.

The specific part I was referring to was:

   "This scheme can be further improved upon, if the host tells the driver what
    CPU it wished to run a particular session on. With this information, the
    driver can steer a session to the same CPU that the scheduler runs the
    socket reads on, and achieve the best cache locality for both kernel and
    user level rx processing."

So far as I'm aware, this hasn't been done.  If it has, I would love to know
how to work with it.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
--
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