netdev - Re: Best way to set kernel thread affinity for handling a socket?

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]

Message-ID: <CAG4TOxOdTiahqVo6+cD=mCN5Ov_hLa_m5gBTuj5sUYsM+GgnYw@mail.gmail.com>
Date:	Thu, 23 Aug 2012 10:04:51 -0700
From:	Roland Dreier <roland@...nel.org>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Best way to set kernel thread affinity for handling a socket?

On Wed, Aug 22, 2012 at 9:21 AM, Ben Hutchings
<bhutchings@...arflare.com> wrote:
> With RFS we try to do the reverse: move the packets to match the socket
> user.   But it's not (yet) turned on by default.  See
> Documentation/networking/scaling.txt

Fair enough.  However I think at least in this case it sounds like extra
overhead: it should be easy for us to do everything on the CPU where
the packets are being received.

>> I'm thinking about this in the context of the kernel's iSCSI target
>> code (drivers/target/iscsi), which creates threads to handle each
>> iSCSI connection and sets their CPU affinity pretty much randomly
>> (well, based on some "thread id", cf iscsit_thread_get_cpumask()).
>
> Why set the affinity at all?

It's quite possible that, like a lot of other drivers/target code, this
doesn't actually make any sense and the right answer is to rip it
out completely.

Is the affinity due to waking up from a network receive event
enough to keep the threads local to the right CPU?

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