Re: [Ips] Storage Maintenance (storm) BOF reminder & requests

Ok, so this is a Linux problem, not an iWARP problem.
Does this mean iSCSI/iSER currently runs with the transition on Windows?
What are some other Operating Systems that also do it the "right" way?

In any case, it might be useful to have a "Standard"
way of bringing up initial connections in RDMA mode
without the necessity to go through the negotiation.
This may be faster, and in many situations it is
already known that RDMA mode will be used, so the
transition is just an extra, unnecessary step.

If nothing else, having such a Standard would bring
InfiniBand, and perhaps other technologies, into
compliance -- as far as I know, InfiniBand cannot
do the transition on any operating system.
Please let me know if that is incorrect.

Thanks,
Bob Russell


On Tue, 24 Mar 2009, Caitlin Bestler wrote:

>
>
>
>
>
>
>> On Tue Mar 24  8:26 , Bernard Metzler <[email protected]> wrote:
>> Hi Robert,
>>
>> an RNIC would be happy to transition an established
>> socket into RDMA mode if the user wants to. No problem -
>> as far as i know - to transition from TOE mode to RDMA mode at least.
>> It is a question of envrionmental support to allow that. To allow that,
>> the environment (aka OFED) wold have to integrate
>> late socket translation, which allows RNIC drivers to officially
>> do TOE to RDMA mode transition or to take over a socket
>>
>> (where the OS would have to expose a well-defined
>> TCP context reallocation scheme).
>> Maybe it is not a good idea to change an end-to-end
>> protocol because a host environment has functional limitations
>> which may stem from historical transport (IB) limitations
>> or OS considerations.
>>
>
> I agree with Bernard.
>
> Conventional RNICs are indeed transitioning streaming mode TCP connections
> to MPA for iWARP in full compliance with the existing RFCs.
>
> What Linux has not implemented is transitioning a host-created streaming mode
> TCP connection to an offload device held streaming mode TCP connection.
> That is a very complex issue, which fortunately for this forum, is out of scope.
>
>
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rddp
>