[openib-general] [PATCH] ib_mad: Receive path fixes

Hal Rosenstock halr at voltaire.com
Mon Sep 27 09:34:23 PDT 2004


On Mon, 2004-09-27 at 12:05, Sean Hefty wrote:
> On Mon, 27 Sep 2004 09:00:27 -0400
> Hal Rosenstock <halr at voltaire.com> wrote:
> 
> > +union ib_mad_recv_wrid {
> > +       u64 wrid;
> > +       struct {
> > +               u32 index;
> > +               u32 qpn;
> > +       } wrid_field;
> > +};
> > +
> 
> If you accept the patch that separates QP 0/1 traffic from each other, 
> we don't need this, and it would allow for additional optimizations.  

I am getting to your patch but want to finish up what I am doing before
I introduce additional variables into the debug. That patch will also
take some work to integrate.

> Is there any benefit to having a single queue of data buffers for receives 
> that are posted to separate queue pairs?  

There are separate receive queues (per QP). There is one queue on the
send side. This is per HCA port.

> As the code is currently structured, an error on QP 1 will reset QP 0, 
> and vice versa.

That could be fixed but I need to look at your changes in more detail
before I would go down that path.

> >  struct ib_mad_private_header {
> >         struct ib_mad_recv_wc recv_wc; /* must be first member (for now
> > !!!) */
> 
> I don't believe that recv_wc needs to be the first member anymore, 
> but that may depend on which patches were accepted.

All patches with the exception of one have been accepted so far. The
change which undoes the requirement for struct ib_mad_recv_wc not
to be the first member (for now) is part of that pending change.

> > +       u32 recv_wr_index[IB_MAD_QPS_SUPPORTED];
> 
> The access layer won't be posting receives on redirected QPs, 
> so I think we can eliminate the "_SUPPORTED" constant, 
> and just use "_CORE" instead.

Right. I'll fix this.

> For redirected QPs, the access layer should only need to perform segmentation
> for the user, or reassembly received data.

Right. Recall that amongst some other things redirection support is not
part of what is currently implemented.

-- Hal  




More information about the general mailing list