[ofa-general] Re: [PATCH 2/3] mcast loopback block

[Or Gerlitz]

Or Gerlitz wrote:
> Roland Dreier wrote:
>> Yes, it's adequate for the current use but I'm wondering why we want to
>> choose a more complex implementation that hides hardware capabilities?
> I tend to think the suggested way is somehow simpler (vs. the per 
> attach) see my reply on "patch 1/3"
In the sockets world the sender sets the IP_MULTICAST_LOOP socket option 
which ip(7) says that it "Sets or reads a boolean integer argument 
whether sent multicast packets should be looped back to the local 
sockets." so one more point here is that the suggested implementation of 
setting this at the qp creation is one that brings the API closer to the 
socket one, which can be easier for users to understand.

>> It's just as easy to add a flag to the multicast attach verb -- maybe 
>> easier, in fact, since there are 16 reserved bits in struct 
>> ib_uverbs_attach_mcast.
> I am concerned about both libibverbs --- uverbs ABI and the app -- 
> libibverbs ABI
> I understand that with this suggestion of yours, the libibverbs 
> API/ABI of MCG attach to apps would change, isn't it something we want 
> to avoid, eg through introducing a new verbs create_qp_ext that gets 
> also creation flag?
>
Roland, can you please comment on your preferences, that is on the cap 
bit vs hint and where you want the app to direct the HW how to behave, 
in the qp creation time as we suggest or on the time of attach. If you 
want to go the changing the qp attach verb way, can please provide us 
with some implementation directions regarding backward compatibility 
with apps that are built against versions of libibverbs which have 
different API for this verb, thanks.

Or.