[openib-general] Re: [PATCH] CMA and iWARP

[Caitlin Bestler]

Grant Grundler wrote:
> On Mon, Jan 23, 2006 at 03:53:19PM -0800, Roland Dreier wrote:
>>  > Yes, but we need to start somewhere. Until someone submits  > a
>> driver that does all the things you mention, it makes  > sense to
>> move forward with what has been proposed to date.
>> 
>> I agree with this, and overall I am very much in favor of getting
>> iWARP support all the way upstream.
> 
> *nod*
> 
> BTW, this is a message that needs to be repeated regularly
> until iWARP support *is* upstream. The opposite perception is
> still lingering in some places because of discussions from 1 and 2
> years ago. 
> 
>> The reason I want to take time to make sure that we have the right
>> code before we merge it is that I get the feeling that there may be
>> elements of a) using the IB tree to get changes upstream that would
>> be vetoed on netdev
> 
> Yeah, that has happened before.  And I expect netdev folks
> might strongly object (if they haven't already) to some
> "sideband" method of managing TCP/IP config when TCP/IP is
> exclusively running on an RNIC (TOE with RDMA front-end).
> IMHO, that's seems like the "hardest to fix" issue so
> everyone is happy. Most of the other details can be negotiated.
> 

It is important to separate two issues here: L2-L3 coordination
and L4 coordination.

The patches that Tom recently posted address the L2-L3 coordination.
They ensure that the TCP/IP stack used by the RNIC is consistent
in its L2-L3 configuration with the host stack. For example, it
will route packets to the same destination IP address the same
way as the host stack, use the same MAC addresses for first hops,
etc.

This logic should really apply to *any* transport service that
claims to use IP Addresses.

The step beyond that, which should also apply to anything that
claims to support SOCK_STREAM or SOCK_DGRAM with IP Addresses,
is achieving similar consistency or even collaboration at L4.
This step will take time, because the opinion within netdev
is against sharing L4 state information with a parallel TCP
stack. There are also challenges like enabling common iSCSI
login phase code that is independent of the ultimate transport,
and ensuring that sockets cannot be made to behave in ways
that are contrary to system policy as stated via netfilter.

Those will be compicated give and takes. There is no reason
to hold up the L2-L3 work because of it. If it were, then
SDP/IB should have been deferred until complete consistency
was achieved. Updating one step at a time makes more sense.