[ofa-general] [PATCH] infiniband: add userspace support for invalidate stag

[mhagen at iol.unh.edu]

Well, I resubmitted the kernel level changes with the comment and
signed-off-by fields.  I will wait on resubmitting the userspace changes.

The only real contribution to the discussion on what we should do, would
be to suggest that maybe we just keep them in a user-patches dir for a
while (until a couple of kernel revs with invalidate supported) then move
them into the main code base.


> On Fri, 2007-05-04 at 19:32 -0500, Steve Wise wrote:
>> On Fri, 2007-05-04 at 14:50 -0700, Roland Dreier wrote:
>> > A few general things:
>> >  - please always submit patches with a changelog entry and
>> >    Signed-off-by: line
>> >  - please send patches in logical chunks.  Usually I'm complaining
>> >    about people combining unrelated things into one patch, but in this
>> >    case I think you divided the patch up too much -- rather than 5
>> >    patches, this should probably be one kernel patch and one userspace
>> >    patch.
>> >  - please make libibverbs patches apply to the libibverbs git tree
>> >    with -p1.  You seem to have generated patches against an OFED
>> package.
>> >
>> > OK, with that out of the way, I think there are still some issues to
>> > sort out with how to handle send with invalidate from userspace.
>> > These patches don't address the case of new userspace with
>> > send-with-invalidate support talking to an unpatched kernel -- it
>> > seems that send-with-invalidate would be silently turned into a plain
>> > send request, which is not a very good failure mode.
>> >
>> > I don't know what the right solution is yet -- a kernel ABI bump for
>> > this one case (send with invalidate support for userspace drivers that
>> > don't do kernel bypass == amso1100) is ugly.  Maybe we also need a
>> > device capabilities bit that says whether send-with-invalidate is
>> > supported?
>> >
>>
>> There already exists a SEND-INV capabilities flag.
>>
>> <snip>
>>         IB_DEVICE_SEND_W_INV            = (1<<16),
>>
>> I think with the capabilities flag, we shouldn't worry about changing
>> the ABI.  But the drivers will need to set this flag.  Amso currently
>> does...
>
> Actually, since Amso has set this flag since day one, it doesn't really
> solve the ABI issue Roland describes.
>
>
> Steve.
>
>


-- 
Mikkel Hagen
Project Assistant - Fibre Channel/SAS/SATA Consortiums
Research and Development Engineer - iWARP Consortium
FC/SAS/SATA:1-603-862-0701  iWARP:1-603-862-5083  Fax:1-603-862-4181
UNH-IOL
121 Technology Drive, Suite 2
Durham, NH 03824