From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ozlabs.org (ozlabs.org [203.10.76.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx.ozlabs.org", Issuer "CA Cert Signing Authority" (verified OK)) by bilbo.ozlabs.org (Postfix) with ESMTPS id 188E7B7B76 for ; Thu, 27 Aug 2009 23:31:44 +1000 (EST) Received: from mail-fx0-f222.google.com (mail-fx0-f222.google.com [209.85.220.222]) by ozlabs.org (Postfix) with ESMTP id DB007DDD01 for ; Thu, 27 Aug 2009 23:31:42 +1000 (EST) Received: by fxm22 with SMTP id 22so59343fxm.9 for ; Thu, 27 Aug 2009 06:31:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <200908261337.56128.fenkes@de.ibm.com> Date: Thu, 27 Aug 2009 09:31:40 -0400 Message-ID: Subject: Re: [ewg] [PATCH] IB/ehca: Construct MAD redirect replies from request MAD From: Hal Rosenstock To: Joachim Fenkes Content-Type: multipart/alternative; boundary=000e0ce0eea86c2b2204721f962d Cc: Hal Rosenstock , OF-EWG , LKML , Jason Gunthorpe , 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: , --000e0ce0eea86c2b2204721f962d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 8/27/09, Joachim Fenkes wrote: > > Hal Rosenstock wrote on 26.08.2009 17:15:03: > > > Thanks for doing this. It looks sane to me. The only issue I recall that > > > appears to be remaining is a better setting of > ClassPortInfo:RespTimeValue > > rather than hardcoding. Perhaps using the value from PortInfo is the way > to go > > (ideally it would be that value from the port to which the the requester > is > > being redirected to but that might not be so easy to get from this port. > > I don't think that effort will be necessary or even legal. The requestor > will react to the redirection with another Get(ClassPortInfo) to the > redirection target, which will reply with its own RespTimeValue, so our > driver should speak for itself. I overreached with my comment on how this works. Since we don't know when our MAD > processing and sending of the response is going to be scheduled (we're not > running on real-time constraints here), we play it safe and return 18, > which amounts to roughly a second. > > Make sense? I don't think it should be hard coded. IMO it would be better to default to 18 and somehow able to be adjusted (via a (dynamic) module parameter ?). -- Hal > Regards > Joachim > --000e0ce0eea86c2b2204721f962d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On 8/27/09, = Joachim Fenkes <FENKES@de.ibm.c= om> wrote:=20
Hal Rosenstock <hal.rosenstock@gmail.com> wrote on 26= .08.2009 17:15:03:

> Thanks for doing this. It looks sane to me. The only issue I recal= l that

> appears to be remaining is a better setting of
ClassP= ortInfo:RespTimeValue
> rather than hardcoding. Perhaps using the val= ue from PortInfo is the way
to go
> (ideally it would be that value from the port to which the th= e requester
is
> being redirected to but that might not be so easy= to get from this port.

I don't think that effort will be necess= ary or even legal. The requestor
will react to the redirection with another Get(ClassPortInfo) to the
red= irection target, which will reply with its own RespTimeValue, so our
dri= ver should speak for itself.
=C2=A0
I overreached with my comment on how this works.

Since we don't know when ou= r MAD
processing and sending of the response is going to be scheduled (w= e're not
running on real-time constraints here), we play it safe and return 18,
w= hich amounts to roughly a second.

Make sense?
=C2=A0
I don't think it should be hard coded. IMO it would be better to d= efault to 18 and somehow able to be adjusted (via a (dynamic) module parame= ter ?).
=C2=A0
-- Hal
=C2=A0
Regards
Joachim

--000e0ce0eea86c2b2204721f962d--