From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rick Jones Subject: Re: setsockopt() Date: Thu, 10 Jul 2008 10:26:01 -0700 Message-ID: <48764629.6090209@hp.com> References: <48725DFE.6000504@citi.umich.edu> <20080707142408.43aa2a2e@extreme> <48728B09.1050801@citi.umich.edu> <20080707.144912.76654646.davem@davemloft.net> <20080708045443.GA7726@2ka.mipt.ru> <20080708020235.388a7bd5.billfink@mindspring.com> <20080708144817.3c364962.billfink@mindspring.com> <20080709183432.GB5383@2ka.mipt.ru> <20080709225035.a4d39cb5.billfink@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Evgeniy Polyakov , Roland Dreier , David Miller , aglo@citi.umich.edu, shemminger@vyatta.com, netdev@vger.kernel.org, rees@umich.edu, bfields@fieldses.org To: Bill Fink Return-path: Received: from g4t0016.houston.hp.com ([15.201.24.19]:49100 "EHLO g4t0016.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758588AbYGJR0G (ORCPT ); Thu, 10 Jul 2008 13:26:06 -0400 In-Reply-To: <20080709225035.a4d39cb5.billfink@mindspring.com> Sender: netdev-owner@vger.kernel.org List-ID: > In my own network benchmarking experience, I've generally gotten the > best performance results when the nuttcp application and the NIC > interrupts are on the same CPU, which I understood was because of > cache effects. Interestingly enough I have a slightly different experience: *) single-transaction, single-stream TCP_RR - best when app and NIC use same core *) bulk transfer - either TCP_STREAM or aggregate TCP_RR: a) enough CPU on one core to reach max tput, best when same core b) not enough, tput max when app and NIC on separate cores, preferably cores sharing some cache That is in the context of either maximizing throughput or minimizing latency. If the context is most efficient transfer, then in all cases my experience thusfar agrees with yours. rick jones