[ofa-general] [PATCH] infiniband/core: Enable loopback of DR SMP responses from userspace

[Steve Welch]

> -----Original Message-----
> From: Hal Rosenstock [mailto:hal.rosenstock at gmail.com]
> Sent: Wednesday, September 05, 2007 4:55 PM
> To: Steve Welch
> Cc: general at lists.openfabrics.org; sean.hefty at intel.com
> Subject: Re: [ofa-general] [PATCH] infiniband/core: Enable loopback of DR
> SMP responses from userspace
> 
> On 9/5/07, Steve Welch <swelch at systemfabricworks.com> wrote:
> > > >        /* Check to post send on QP or process locally */
> > > > -       if (smi_check_local_smp(smp, device) == IB_SMI_DISCARD)
> > > > +       if (smi_check_local_smp(smp, device) == IB_SMI_DISCARD &&
> > > > +           smi_check_local_resp_smp(smp, device) == IB_SMI_DISCARD)
> > > >                goto out;
> > > >
> > > >        local = kmalloc(sizeof *local, GFP_ATOMIC);
> > > > @@ -754,6 +755,7 @@ static int handle_outgoing_dr_smp(struct
> > > ib_mad_agent_private *mad_agent_priv,
> > > >                if (port_priv) {
> > > >                        mad_priv->mad.mad.mad_hdr.tid =
> > > >                                ((struct ib_mad *)smp)->mad_hdr.tid;
> > > > +                       memcpy(&mad_priv->mad.mad, smp,
> sizeof(struct
> > > ib_mad));
> > >
> > > Is this copy only needed in the (new) returning direction case ?
> >
> > No, it is needed whether the SMP is a request or response.
> >
> > >
> > > >                        recv_mad_agent = find_mad_agent(port_priv,
> > > >                                                        &mad_priv-
> > > >mad.mad);
> > > >                }
> > > > diff --git a/drivers/infiniband/core/smi.h
> > > b/drivers/infiniband/core/smi.h
> > > > index 1cfc298..d96fc8e 100644
> > > > --- a/drivers/infiniband/core/smi.h
> > > > +++ b/drivers/infiniband/core/smi.h
> > > > @@ -71,4 +71,18 @@ static inline enum smi_action
> > > smi_check_local_smp(struct ib_smp *smp,
> > > >                (smp->hop_ptr == smp->hop_cnt + 1)) ?
> > > >                IB_SMI_HANDLE : IB_SMI_DISCARD);
> > > >  }
> > > > +
> > > > +/*
> > > > + * Return 1 if the SMP response should be handled by the local
> > > management stack
> > > > + */
> > > > +static inline enum smi_action smi_check_local_resp_smp(struct
> ib_smp
> > > *smp,
> > > > +                                                      struct
> ib_device
> > > *device)
> > > > +{
> > > > +       /* C14-13:3 -- We're at the end of the DR segment of path */
> > > > +       /* C14-13:4 -- Hop Pointer == 0 -> give to SM */
> > > > +       return ((device->process_mad &&
> > > > +               ib_get_smp_direction(smp) &&
> > > > +               !smp->hop_ptr) ? IB_SMI_HANDLE : IB_SMI_DISCARD);
> > > > +}
> > > > +
> > >
> > > I think this routine and the existing one could be better named:
> > > smi_check_local_outgoing/returning_smp.
> > >
> >
> > Possibly, but the SMP does originate in both cases from a local mad send
> > operation.  In one case sending the request and in the other sending the
> > response; in both cases they are locally handled.
> 
> Aren't they more appropriately termed outgoing and returning rather
> than request/response ? Guess it ends up being the same since in
> practice Traps and TrapRepresses are only LID routed but there is
> nothing in the spec that precludes them from being direct routed.
> 
Yes, from the perspective of mapping the processing back to the IB spec.
I'm certainly fine with whatever name is chosen.

Steve

> -- Hal
> 
> >
> > Steve
> >
> > > -- Hal
> > > > _______________________________________________
> > > > general mailing list
> > > > general at lists.openfabrics.org
> > > > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> > > >
> > > > To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-
> > > general
> > > >
> >
> >