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]
Date:	Tue, 06 Nov 2007 11:53:07 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	"Matthew Faulkner" <matthew.faulkner@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: localhost network processing on smp machines

"Matthew Faulkner" <matthew.faulkner@...il.com> writes:

> I'm probably being stupid and very confused here. Appologies if it is
> a stupid question.
>
> For a particular test I assign a client to core 1 and a server to core
> 0. My first assumption was all the sending side kernel TCP/IP
> processing will be done on core 1 and all the receiving side
> processing on core 0. However, having looked at the linux TCP/IP code,
> more specifically the loopback device code, when the loopbacks
> dev_queue_xmit function gets called it simply passes the skb to the
> netif_rx function. Therefore my question is thus, when i assign the
> sending / receiving side to different cores is the actual TCP/IP
> processing done the assigned sending / receiving cores ? or is TCP/IP
> processing done on the sending side only until a certain point? 
> it simply a single core that does all the TCP/IP processing. If it's
> the first two and you have any idea, could you point me where in the
> kernel the cores the processing swap over.

You need to define what you mean with TCP/IP processing. It has lots
of little sub-actions.  For the loopback case some will always run on
the sender side (IP, socket demultiplex, some will sometimes run on
either depending on workload (using TCP prequeue and depending on the
tcp_latency setting and how quickly the receiver schedules), and some
always on the receiver side (recvmsg user processing)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ