Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Jeff Layton <jlayton@kernel.org>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        "trondmy@hammerspace.com" <trondmy@hammerspace.com>
Subject: Re: [PATCH v2 03/15] SUNRPC: Replace dprintk() call site in
 xs_data_ready
Thread-Topic: [PATCH v2 03/15] SUNRPC: Replace dprintk() call site in
 xs_data_ready
Thread-Index: AQHYebVsA5QfjiQznUipQF2FW+UKja1xxaoAgAAOQYA=
Date:   Wed, 6 Jul 2022 18:10:27 +0000
Message-ID: <DAE78CB7-4A01-4DB7-8E7A-788A311C52A9@oracle.com>
References: <165452664596.1496.16204212908726904739.stgit@oracle-102.nfsv4.dev>
 <165452704802.1496.15626296214203899256.stgit@oracle-102.nfsv4.dev>
 <8d04a3f22e170e117cdc605037932f29f6408d6b.camel@kernel.org>
In-Reply-To: <8d04a3f22e170e117cdc605037932f29f6408d6b.camel@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?1QOszDy+EjzJ/5UG5I5+jmNeFVnvJOzTHhaXIW1eDS2CmKi664+KQumsQi4y?=
 =?us-ascii?Q?Wfjfl6k/C9Hja6++dpamGjkqZUGCs/I3n/pK7nuWXkcpdl3O/xdOzvsx2zcr?=
 =?us-ascii?Q?pqmoPuFFOlvW4sNxctA70xZ3dsU9Si/lDhX5Bo9Z4Ue/jk9RjU4pbqM0DWCa?=
 =?us-ascii?Q?bkFR1PNSb2q/mQ1PBty6kJ8fzKfjWXQg3b8VscoYQcObri9P39ePABMIG8hA?=
 =?us-ascii?Q?gjS20gOzqC2f/5RGbPrAuBeaSXOSzGFKsqLzlk6Ve0O6NkHI53/wqpak1nXx?=
 =?us-ascii?Q?46lBFobU9kSIpFRJ/1JdbKtotjZI2ACOh/ignau1wyqirci0xlVtqYjvlHiZ?=
 =?us-ascii?Q?76Xeo/SGOYtjUm2quF6km2fOwDTcqXvwq3S9zqjyZIf0Gp5Y1YQcp/T+W08s?=
 =?us-ascii?Q?UevjA1zf/deRj5E83ILuKg53xIsEdZ370fWG9Oax1Ah5s+CbAVQbmE+OOVNP?=
 =?us-ascii?Q?yODGOHdj7jH+LrvOcgQ0gBct6W2cpQPugWA3HlIWWqrXqsoKuD54qeQq70H0?=
 =?us-ascii?Q?+fOgKf1iNfbdZ8HXxZQPLYaDHf4+AaCXwSDJ20/Nj+/x4JZ/DQ3mGgo2RfiV?=
 =?us-ascii?Q?h5+zllV8XkaPm2VwITUfOVZ+ajVOKPKZDxgfeXTag86WB5BOSCilRsDHhwFv?=
 =?us-ascii?Q?tHHjyGP7XzCgibuQdAbuNo46OAKz1Cf3GG4cbIc1FxdR8nKBC3HATQhDvGmI?=
 =?us-ascii?Q?b4qGTpQhtIRq7Uf8Wu8jAqSXdaH2LqVj5i5vbUPunk4WdCX6hHLQFMmZe/tS?=
 =?us-ascii?Q?7DHUougz0HBi4R0HJ9sGc2fBiOy+yMbs7RALD8MNEHvNDwYEKEbgIVWzJhfo?=
 =?us-ascii?Q?A96WOpUs+dVPkxcdCuXbDLJUL5VS7Ac9HFM0B/i0GoG991pLok5CKetx/sxk?=
 =?us-ascii?Q?iUgvjzTfuL/cF7R5i+oMJyJzYcfimlKe53F8XEKbk722rHeNsukiBbjXRadh?=
 =?us-ascii?Q?FUZGBGyVF6wwDMpJ3hVlmtBATyPLXuZvcynzT+aZs2KYcGzNh3WyEufXij7f?=
 =?us-ascii?Q?T0Rr3M/j5LknNgTptCCjzaM9vQFvvlsNWddLW9MeggCwAvOAZyZ84FwU9zsW?=
 =?us-ascii?Q?WpuVza0ylAwEG7jiKN602mQKsiiikEZmMvfSVzUk1q/krLz/XyIpqP8x4QyL?=
 =?us-ascii?Q?IwCey2XTSbBvVm7/CHMkMxN3/DI3Qu5ofoR2J/onIf5nNgK03oswuLk8+CPh?=
 =?us-ascii?Q?I8orlZlGz594AW8dUVsLHAok08bbE0EFtedjdobsV683oedVM8sVcyWhWh0d?=
 =?us-ascii?Q?vM076idc6E0XtJFydthnXyQme4J7Ki0YlTzHdyu8WwU9+5rU1SLhQuJd52BP?=
 =?us-ascii?Q?3msnt6Rb56SrOcY+LayoH0hfQpm1429WXXsDpF9INt/kpTBlvWuOT8LFDvyp?=
 =?us-ascii?Q?aOSVF0jl019qfkXzxkdkBbY7Idin0/DhVSu6HA+2cBuh/XvSI5R+lxDxNKQD?=
 =?us-ascii?Q?YK8p00oKi19UMnj9uUtrbLpGdNbihnIIclAb9ROx9KpvGLqG9YzeTwQE1SDW?=
 =?us-ascii?Q?MJm7jRS6V5jATwsZ8tc+3SFDdbIV3e6PON8eCEWYevixoKsqWF01/SvgsNl6?=
 =?us-ascii?Q?U4ahAjvBYk3Kf9Myt5WYSeInZj4dTZxQhXCkLI012xv4OcNbcXQcbKcqZ4lQ?=
 =?us-ascii?Q?jg=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B22FCEC951856D41AADE5A35A1A0CF35@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2520903c-6233-4dae-2d0c-08da5f7ace5e
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2022 18:10:27.9116
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QR9r4yh1g2z3rF0axnzMM7cfbnAouXpQLa1FWYu2dhRON1UHP7m2sz4/+el/zX/NewaC0qtcC9Yh+xsDpHk6wg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR10MB1408
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883
 definitions=2022-07-06_09:2022-06-28,2022-07-06 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 suspectscore=0 phishscore=0
 mlxlogscore=999 spamscore=0 adultscore=0 malwarescore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000
 definitions=main-2207060071
X-Proofpoint-ORIG-GUID: 6MZVgldkHoDevzImwiENAGreCC_Hn0Zg
X-Proofpoint-GUID: 6MZVgldkHoDevzImwiENAGreCC_Hn0Zg
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Jul 6, 2022, at 1:19 PM, Jeff Layton <jlayton@kernel.org> wrote:
>=20
> On Mon, 2022-06-06 at 10:50 -0400, Chuck Lever wrote:
>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>> ---
>> include/trace/events/sunrpc.h | 20 ++++++++++++++++++++
>> net/sunrpc/xprtsock.c | 6 ++++--
>> 2 files changed, 24 insertions(+), 2 deletions(-)
>>=20
>> diff --git a/include/trace/events/sunrpc.h b/include/trace/events/sunrpc=
.h
>> index 3995c58a1c51..a66aa1f59ed8 100644
>> --- a/include/trace/events/sunrpc.h
>> +++ b/include/trace/events/sunrpc.h
>> @@ -1266,6 +1266,26 @@ TRACE_EVENT(xprt_reserve,
>> 	)
>> );
>>=20
>> +TRACE_EVENT(xs_data_ready,
>> +	TP_PROTO(
>> +		const struct rpc_xprt *xprt
>> +	),
>> +
>> +	TP_ARGS(xprt),
>> +
>> +	TP_STRUCT__entry(
>> +		__string(addr, xprt->address_strings[RPC_DISPLAY_ADDR])
>> +		__string(port, xprt->address_strings[RPC_DISPLAY_PORT])
>> +	),
>> +
>> +	TP_fast_assign(
>> +		__assign_str(addr, xprt->address_strings[RPC_DISPLAY_ADDR]);
>> +		__assign_str(port, xprt->address_strings[RPC_DISPLAY_PORT]);
>> +	),
>>=20
>>=20
>=20
> This tracepoint is likely to fire rather often when it's enabled. Would
> it be more efficient to store the addr and port as binary data instead?

Yes, and it can use get_sockaddr() and friends for that. But those
patches were in flight when I wrote this one.


>> +
>> +	TP_printk("peer=3D[%s]:%s", __get_str(addr), __get_str(port))
>> +);
>> +
>> TRACE_EVENT(xs_stream_read_data,
>> 	TP_PROTO(struct rpc_xprt *xprt, ssize_t err, size_t total),
>>=20
>> diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
>> index 650102a9c86a..73fab802996d 100644
>> --- a/net/sunrpc/xprtsock.c
>> +++ b/net/sunrpc/xprtsock.c
>> @@ -1378,7 +1378,7 @@ static void xs_udp_data_receive_workfn(struct work=
_struct *work)
>> }
>>=20
>> /**
>> - * xs_data_ready - "data ready" callback for UDP sockets
>> + * xs_data_ready - "data ready" callback for sockets
>> * @sk: socket with data to read
>> *
>> */
>> @@ -1386,11 +1386,13 @@ static void xs_data_ready(struct sock *sk)
>> {
>> 	struct rpc_xprt *xprt;
>>=20
>> -	dprintk("RPC: xs_data_ready...\n");
>> 	xprt =3D xprt_from_sock(sk);
>> 	if (xprt !=3D NULL) {
>> 		struct sock_xprt *transport =3D container_of(xprt,
>> 				struct sock_xprt, xprt);
>> +
>> +		trace_xs_data_ready(xprt);
>> +
>> 		transport->old_data_ready(sk);
>> 		/* Any data means we had a useful conversation, so
>> 		 * then we don't need to delay the next reconnect
>>=20
>>=20
>=20
> That dprintk was pretty worthless anyway. So the change seems fine to
> me.
>=20
>=20
> --=20
> Jeff Layton <jlayton@kernel.org>

--
Chuck Lever