From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ozlabs.org (Postfix) with ESMTP id DA212DDE04 for ; Tue, 17 Jul 2007 13:48:42 +1000 (EST) To: Hoang-Nam Nguyen Subject: Re: [PATCH 01/10] IB/ehca: Support for multiple event queues References: From: Roland Dreier Date: Mon, 16 Jul 2007 20:48:40 -0700 In-Reply-To: (Hoang-Nam Nguyen's message of "Mon, 16 Jul 2007 22:37:44 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Joachim Fenkes , LKML , LinuxPPC-Dev , Christoph Raisch , OF-General , Stefan Roscher List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > No, I've no figures to provide here. The background of this dist_eqs > option is actually to allow us testing across all event queues > without to change the testcases resp consumers to use certain > event queue number. Thus, I should comment it as EXPERIMENTAL? Seems like it's just development/testing code that shouldn't escape into the wild? > > I think I would rather hold off on multiple EQs for this merge window > > and plan on having something really solid and thought-out for 2.6.24. > Fair enough. However why don't let us gather experience with this > feature now? Should we remove dist_eqs option for more consistency? As I said I definitely think the dist_eqs switch doesn't sound like something we want to expose to people. With that said I still am not sure about putting the multiple EQs feature in this release. All the infrastructure is there to make experimenting with it fairly painless (just the low-level driver needs to change), and I still haven't seen much code using the feature or even any anecdotal information about the performance impact.