Hi Or!
> Roland Dreier wrote:
> > > @@ -505,6 +509,7 @@ struct ib_qp_init_attr {
> > > enum ib_sig_type sq_sig_type;
> > > enum ib_qp_type qp_type;
> > > u8 port_num; /* special QP types only */
> > > + enum qp_create_flags create_flags;
> > > };
> >
> > I'm dubious about this. It seems to me like everything (including the
> > mlx4 low-level driver changes for LSO) would be simpler to implement
> > and use if we just extend the qp_type to include IB_QPT_UD_LSO.
> Roland, All,
>
> How about making the qp_type field a bit mask, such that in the ipoib
> LSO use case it would be (UD | LSO) and in the ipoib ehca case (UD |
> LL), etc. The bit mask change would also be propagated up to libibverbs
> and be defined in a way such that it preserves backward compatibility re
> the qp_type field for users of libibverbs that did not changed their
code.
I personally prefer this because we want to providde LL to user space.
Using qp_type's bit fields does not require me to change e.g.
ib_uverbs_create_qp to reflect create_flags from user space, which will
break previous libxyz - currently it's hardcoded to zero in uverbs_cmd.c,
see also
http://lists.openfabrics.org/pipermail/general/2008-March/047960.html
Nam
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
