From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rick Jones Subject: Re: [PATCH v4] rfs: Receive Flow Steering Date: Fri, 16 Apr 2010 11:32:36 -0700 Message-ID: <4BC8AD44.9050707@hp.com> References: <20100412171205.561a1aec@nehalam> <4BC89F6D.2080604@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Tom Herbert , Stephen Hemminger , davem@davemloft.net, netdev@vger.kernel.org, eric.dumazet@gmail.com, Ingo Molnar To: Paul Turner Return-path: Received: from g6t0186.atlanta.hp.com ([15.193.32.63]:37255 "EHLO g6t0186.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757978Ab0DPScl (ORCPT ); Fri, 16 Apr 2010 14:32:41 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: > Even under a hybrid model I think phrasing it as networking leading > the scheduler here is a little strong. The scheduler is in both cases > the most 'informed' place to make these decisions, but I think it > could benefit from more knowledge. In the 'virgin' single flow case > without any steering the network stack is currently able to implicitly > hint to the scheduler where flows could be most efficiently served due > to wake-affine balancing behaviors. This is a natural side-effect of > wake-ups being sourced by the networking cpus. Hinting to the scheduler is fine - so long as the final say is the scheduler. Presumably it is the thing that knows about the other forces tugging at where to run the thread - where its memory is allocated, what other flows are coming to it etc. rick jones