[ofa-general] Re: [PATCHv2] opensm/osm_mesh.c: Reorder switches for lash

Hal Rosenstock hal.rosenstock at gmail.com
Wed Aug 5 07:21:15 PDT 2009


On Wed, Aug 5, 2009 at 5:44 AM, Sasha Khapyorsky <sashak at voltaire.com>wrote:

> On 11:16 Wed 22 Jul     , Hal Rosenstock wrote:
> >
> > diff --git a/opensm/opensm/osm_mesh.c b/opensm/opensm/osm_mesh.c
> > index 23fad87..dce2ea1 100644
> > --- a/opensm/opensm/osm_mesh.c
> > +++ b/opensm/opensm/osm_mesh.c
> > @@ -185,6 +185,16 @@ typedef struct _mesh {
> >       int dim_order[MAX_DIMENSION];
> >  } mesh_t;
> >
> > +typedef struct sort_ctx {
> > +     lash_t *p_lash;
> > +     mesh_t *mesh;
> > +} sort_ctx_t;
> > +
> > +typedef struct comp {
> > +     int index;
> > +     sort_ctx_t *ctx;
> > +} comp_t;
>
> And wouldn't it be simpler to use:
>
> struct comp {
>        switch_t **s;


Are you thinking this is:
           s = &p_lash->switches[i];


>
>        sort_ctx_t ctx;
> };


> ? So you will have already sorted switches and only will need to care
> about s->id and s->links fixing (and will not need switches[] array too).


Then comp would contain an ordered list of p_lash->switches array pointers
which would need to be walked through for actually reordering that array. If
so, it's the cost of the new switches array v. the cost of reordering the
original lash switches array. I haven't thought that through yet.

Is this what you mean or am I missing your idea on how the p_lash->switches
array is to be reordered ?

-- Hal


>
>
> Sasha
>  _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20090805/852c748a/attachment.html>


More information about the general mailing list