<snip>
> > > +static void cm_event_handler(struct iw_cm_id *cm_id,
> > > + struct iw_cm_event *iw_event)
> > > +{
> > > + struct iwcm_work *work;
> > > + struct iwcm_id_private *cm_id_priv;
> > > + unsigned long flags;
> > > +
> > > + work = kmalloc(sizeof(*work), GFP_ATOMIC);
> > > + if (!work)
> > > + return;
> >
> > This allocation _will_ fail sometimes. The driver must recover from it.
> > Will it do so?
>
> Er...no. It will lose this event. Depending on the event...the carnage
> varies. We'll take a look at this.
>
This behavior is consistent with the Infiniband CM (see
drivers/infiniband/core/cm.c function cm_recv_handler()). But I think
we should at least log an error because a lost event will usually stall
the rdma connection.
> >
> > > +EXPORT_SYMBOL(iw_cm_init_qp_attr);
> >
> > This file exports a ton of symbols. It's usual to provide some justifying
> > commentary in the changelog when this happens.
>
> This module is a logical instance of the xx_cm where xx is the transport
> type. I think there is some discussion warranted on whether or not these
> should all be built into and exported by rdma_cm. One rationale would be
> that the rdma_cm is the only client for many of these functions (this
> being a particularly good example) and doing so would reduce the export
> count. Others would be reasonably needed for any application (connect,
> etc...)
>
Transport-dependent ULPs, in theory, are able to use the
transport-specific CM directly if they don't wish to use the RDMA CM. I
think that's the rationale for have the xx_cm modules seperate from the
rdma_cm module and exporting the various functions.
> All that said, we'll be sure to document the exported symbols in a
> follow-up patch.
>
I'll add commentary explaining this.
Steve.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
