Re: [PATCH v1 2/2] NFSv4.0: Remove transport protocol name from non-UCS client ID

[Chuck Lever <chuck.lever@oracle.com>]

> On Jun 6, 2018, at 11:55 AM, Trond Myklebust <trondmy@hammerspace.com> =
wrote:
>=20
> On Wed, 2018-06-06 at 11:48 -0400, Chuck Lever wrote:
>>> On Jun 6, 2018, at 11:44 AM, Trond Myklebust <trondmy@hammerspace.c
>>> om> wrote:
>>>=20
>>> On Mon, 2018-06-04 at 10:53 -0400, Chuck Lever wrote:
>>>> Commit 69dd716c5ffd ("NFSv4: Add socket proto argument to
>>>> setclientid") (2007) added the transport protocol name to the
>>>> client
>>>> ID string, but the patch description doesn't explain why this was
>>>> necessary.
>>>>=20
>>>> At that time, the only transport protocol name that would have
>>>> been
>>>> used is "tcp" (for both IPv4 and IPv6), resulting in no
>>>> additional
>>>> distinctiveness of the client ID string.
>>>>=20
>>>> Since there is one client instance, the server should recognize
>>>> it's
>>>> state whether the client is connecting via TCP or RDMA. Same
>>>> client,
>>>> same lease.
>>>=20
>>> The reason why this is the case now is because the trunking code
>>> overrides the guardrails in nfs_get_client(). The latter does match
>>> on
>>> the protocol.
>>=20
>> OK. Would that also true in the UCS case?
>>=20
>=20
> Yes, I believe that code is independent of the migration flag.

But the UCS does not include the transport type. Maybe something is
broken here (that something could be my understanding). Seems to me
that could impact transparent state migration between a server that
is mounted with RDMA, and one that has only TCP.

I'm willing to drop 2/2.


--
Chuck Lever