[openib-general] [PATCH] [CM] add private data comparison to match REQs with listens

[Caitlin Bestler]

Fab Tillier wrote:
>> From: Caitlin Bestler [mailto:caitlinb at broadcom.com]
>> Sent: Friday, December 02, 2005 12:13 PM
>> 
>> Sean Hefty wrote:
>>> Fab Tillier wrote:
>>>>> Just listen on the Service ID / Port and let the ULP sort them out
>>>>> by destination IP address.
>>>> 
>>>> That only works if there is a single kernel module providing the
>>>> extra checks. Multiple user-mode ULPs cannot do the checking in
>>>> user-mode - the checking must be done in the kernel to figure out
>>>> which user-mode client to hand the request to.
>>>> 
>>>> I think putting in restrictions to the comparisons possible is
>>>> fine, as the functionality of having the CM facilitate some sort of
>>>> filtering is useful.
>>> 
>>> My concern with pushing this to the ULP is that it requires the ULP
>>> to track service IDs for reference counting purposes and adds
>>> additional synchronization to the ULP that could have been handled
>>> by the CM. 
>>> 
>>> I'm looking at what the full effect of implementing this in the ULP
>>> would be.
>> 
>> I'm still missing something.
>> 
>> I don't see how filtering in the CM is of benefit in either case. The
>> work either belongs in the Hypervisor or in the Daemon, not the CM.
> 
> Your focus is strictly on TCP socket semantics, but we're
> talking about IB CM functionality - the IB CM does more than
> just provide TCP socket semantics.
> 
> Imagine a user-mode IB application (not virtualization mind
> you, but just an
> app) that wants to listen on a given SID (because the SID
> defines the application), but wants to discriminate incoming
> requests based on some content in the private data.  Multiple
> instances of that application can only work properly if the
> CM performs the private data comparison to properly dispatch
> the incoming requests to the right user-mode process.
> 
> If the CM doesn't provide the private data compare
> functionality, then the app developer needs to create a
> kernel agent to perform this functionality for the app.  The
> functionality is simple enough, and has potential value to
> multiple clients, that it makes sense to have the IB CM provide it.
> 
> - Fab

You are proposing that the API be made more complex and
you do not have any justification other that something
some user-mode application *might* want to do.

Why are these different user-mode applications sharing
a Service ID in the first place? On what basis do they
trust each other? How do they co-ordinate their filtering?
Couldn't they use CM redirection to share the Service ID?

The goal was supposed to be providing TCP-compatible
connection setup, but this is describing something that
is decidedly un-TCP-like. TCP applications differentiate
within the daemon, or redirect connections. If they split
connections based upon packet content it is only done by
very sophisticated L7 load balancers that identify cookies
or other HTTP content.