[ofa-general] Re: [PATCH 3/3 v4] ib/ipoib: blocking multicast loopback ipoib packets

[Roland Dreier]

 >  yes,  this was one  idea (earlier one that is a new QP type eg
 > IB_QPT_UD_BML) and the thing is that we  would be happy to get your
 > take on how can this be done with minimum pain regarding ABI issues
 > both up towards libibverbs consumers and down towards ib_uverbs.

Sorry, I don't have a magic solution for you.  To minimize pain about
ABI I think the only thing to do is minimize ABI changes.

 > Actually, looking on the XRC patch set, as it adds new QP type anyway,
 >  IB_QPT_UD_BML might turn to be the simplest way here, but its not
 > general enough as moving forward, people were talking on other create
 > flags they want to use from user space (low latency QP, etc)

If a QP creation flag works for XRC then I would prefer not to add more
QP types I guess.  One of the ways that the QP creation flags were
originally sold to me was that XRC needed them anyway.  So I'm a bit
confused about where things have ended up.

 >  Among other things, the XRC patch series adds the
 > "ibv_create_xrc_rcv_qp"  new verb to libibverbs, so my thought here
 > was that a new way X to create QPs is added, and we want a new way Y
 > for the block multicast loop. So maybe we can form a framework Z for
 > creating QPs other then the old one. Alternatively its possible for
 > the create_qp_with_create_flags verb (and other verbs we want to add
 > such as cq_modify_moderation_params) to just live next to the new
 > verbs added to libibverbs in the new ibv_xrc_ops structure which is
 > added for the verbs context.

I don't want to add both an XRC-specific mechanism and a more general
mechanism that XRC could have used but doesn't.  So yes the "framework
Z" approach that works for both seems like the best way forward.

 - R.