From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759660AbYDBRBy (ORCPT ); Wed, 2 Apr 2008 13:01:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757282AbYDBRBn (ORCPT ); Wed, 2 Apr 2008 13:01:43 -0400 Received: from rgminet01.oracle.com ([148.87.113.118]:16379 "EHLO rgminet01.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757092AbYDBRBm (ORCPT ); Wed, 2 Apr 2008 13:01:42 -0400 Message-ID: <47F3C9BB.5040009@oracle.com> Date: Wed, 02 Apr 2008 13:00:27 -0500 From: Richard Frank User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: "Scott Weitzenkamp (sweitzen)" CC: "Roland Dreier (rdreier)" , rds-devel@oss.oracle.com, linux-kernel@vger.kernel.org, general@lists.openfabrics.org Subject: Re: [ofa-general] InfiniBand/iWARP/RDMA merge plans for 2.6.26 (what'sin infiniband.git) References: <1207120932.4593.47.camel@localhost.localdomain> <47F3BE33.4000204@oracle.com> <47F3C137.3070209@oracle.com> <47F3C469.1020803@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org OK - and the conversation was about using NetPerf to compare performance of RDS to UDP relative to suitability for Oracle use ... so I think those statements still illustrate my points... 1) NetPerf does not do what Oracle does - and hence is not useful from Oracle's perspective in comparing ULPs. 2) For some metrics - it's not valid to compare a non-reliable IPC to a reliable IPC - it's not an apples to apples comparison. Especially when the app is considered and what the app must do to use UDP vs RDS. I did not say that NetPerf should not be extended to support RDS - just that using it to do a comparison of ULPs to determine how well Oracle would run - is not what we (Oracle) would want - at least that was my intention.. Scott Weitzenkamp (sweitzen) wrote: > Rich, > > On Nov 1, 2007, you wrote this to rds-devel: > > "Netperf is too simplistic in that all it seems to do is stream data > in a > simple loop. This is not how Oracle uses the IPC and again does not > reflect what it would take to make UDP reliable. > > For this reason we are not interested in having Netperf support RDS > and > or seeing Netperf data." > > I would like to see RDS supported by existing common tools like netperf, > iperf, etc. so we can easily compare how RDS performs to UDP for IPC > models other than Oracle. > > Scott Weitzenkamp > SQA and Release Manager > Data Center Access Engineering > Cisco Systems > > > > > >> -----Original Message----- >> From: Richard Frank [mailto:richard.frank@oracle.com] >> Sent: Wednesday, April 02, 2008 10:38 AM >> To: Scott Weitzenkamp (sweitzen) >> Cc: Roland Dreier (rdreier); rds-devel@oss.oracle.com; >> linux-kernel@vger.kernel.org; general@lists.openfabrics.org >> Subject: Re: [ofa-general] InfiniBand/iWARP/RDMA merge plans >> for 2.6.26 (what'sin infiniband.git) >> >> I believe there is a patch for NetPerf which supports RDS - >> although it >> may need to be updated - and submitted. >> >> The only prior discussion I can think of - was whether or not NetPerf >> exercises RDS as Oracle would. >> >> I'm not proposing that we should enhance NetPerf to do that >> (but that's >> OK with me). >> >> We created a tool rds-stress which does that. >> >> Scott Weitzenkamp (sweitzen) wrote: >> >>>> WRT to merging RDS into the kernel - our current plans are >>>> >> to wait to >> >>>> see RDS adopted by more than Oracle - before approaching >>>> >> the kernel >> >>>> community about inclusion of RDS. >>>> >>>> >>> I've seen statements before from someone from Oracle that >>> >> RDS was only >> >>> for Oracle's use, for example, that person did not want >>> >> netperf changed >> >>> to support RDS. >>> >>> Scott Weitzenkamp >>> SQA and Release Manager >>> Data Center Access Engineering >>> Cisco Systems >>> >>>