Message-ID: <c6e21cd4-b756-e566-c267-37f997f53239@linux.alibaba.com>
Date:   Thu, 23 Jun 2022 20:50:15 +0800
From:   "D. Wythe" <alibuda@...ux.alibaba.com>
To:     Alexandra Winter <wintera@...ux.ibm.com>,
        Karsten Graul <kgraul@...ux.ibm.com>,
        Tony Lu <tonylu@...ux.alibaba.com>
Cc:     kuba@...nel.org, davem@...emloft.net, netdev@...r.kernel.org,
        linux-s390@...r.kernel.org, linux-rdma@...r.kernel.org
Subject: Re: [RFC net-next] net/smc:introduce 1RTT to SMC



On 2022/6/23 下午7:59, Alexandra Winter wrote:
> 
> 
> On 16.06.22 15:49, D. Wythe wrote:
>>
>>
>> On 2022/6/1 下午2:33, D. Wythe wrote:
>>>
>>> 在 2022/5/25 下午9:42, Alexandra Winter 写道:
>>>
>>>> We need to carefully evaluate them and make sure everything is compatible
>>>> with the existing implementations of SMC-D and SMC-R v1 and v2. In the
>>>> typical s390 environment ROCE LAG is propably not good enough, as the card
>>>> is still a single point of failure. So your ideas need to be compatible
>>>> with link redundancy. We also need to consider that the extension of the
>>>> protocol does not block other desirable extensions.
>>>>
>>>> Your prototype is very helpful for the understanding. Before submitting any
>>>> code patches to net-next, we should agree on the details of the protocol
>>>> extension. Maybe you could formulate your proposal in plain text, so we can
>>>> discuss it here?
>>>>
>>>> We also need to inform you that several public holidays are upcoming in the
>>>> next weeks and several of our team will be out for summer vacation, so please
>>>> allow for longer response times.
>>>>
>>>> Kind regards
>>>> Alexandra Winter
>>>>
>>>
>>> Hi alls,
>>>
>>> In order to achieve signle-link compatibility, we must
>>> complete at least once negotiation. We wish to provide
>>> higher scalability while meeting this feature. There are
>>> few ways to reach this.
>>>
>>> 1. Use the available reserved bits. According to
>>> the SMC v2 protocol, there are at least 28 reserved octets
>>> in PROPOSAL MESSAGE and at least 10 reserved octets in
>>> ACCEPT MESSAGE are available. We can define an area in which
>>> as a feature area, works like bitmap. Considering the subsequent scalability, we MAY use at least 2 reserved ctets, which can support negotiation of at least 16 features.
>>>
>>> 2. Unify all the areas named extension in current
>>> SMC v2 protocol spec without reinterpreting any existing field
>>> and field offset changes, including 'PROPOSAL V1 IP Subnet Extension',
>>> 'PROPOSAL V2 Extension', 'PROPOSAL SMC-DV2 EXTENSION' .etc. And provides
>>> the ability to grow dynamically as needs expand. This scheme will use
>>> at least 10 reserved octets in the PROPOSAL MESSAGE and at least 4 reserved octets in ACCEPT MESSAGE and CONFIRM MESSAGE. Fortunately, we only need to use reserved fields, and the current reserved fields are sufficient. And then we can easily add a new extension named SIGNLE LINK. Limited by space, the details will be elaborated after the scheme is finalized.
>>>
> [...]
>>>
>>>
>>> Look forward to your advice and comments.
>>>
>>> Thanks.
>>
>> Hi all,
>>
>> On the basis of previous，If we can put the application data over the PROPOSAL message,
>> we can achieve SMC 0-RTT. Its process should be similar to the following:
>>
> [...]
> 
> Thank you D. Wythe for the detailed proposal, I have forwarded it to the protocol owner
> and we are currently reviewing it.
> We may contact you and Tony Lu directly to discuss the details, if that is ok for you.
> 
> Kind regards
> Alexandra Winter
> 
> 
> 
> 

Thanks a lot for your support, it seems good to us. We are totally okay with that.

Best Wishes.
D. Wythe

Powered by blists - more mailing lists