<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include/trace/events/rpcrdma.h, branch linux-rolling-lts</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-lts</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-rolling-lts'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2024-09-20T23:31:03Z</updated>
<entry>
<title>svcrdma: Handle device removal outside of the CM event handler</title>
<updated>2024-09-20T23:31:03Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2024-07-29T20:52:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c4de97f7c45434985e5dbf2d6ccc9eca676e37fe'/>
<id>urn:sha1:c4de97f7c45434985e5dbf2d6ccc9eca676e37fe</id>
<content type='text'>
Synchronously wait for all disconnects to complete to ensure the
transports have divested all hardware resources before the
underlying RDMA device can safely be removed.

Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>rpcrdma: Trace connection registration and unregistration</title>
<updated>2024-08-19T15:50:41Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2024-08-12T15:47:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=dc0112e6d8b42b39f9d283bab489a757e9d284f0'/>
<id>urn:sha1:dc0112e6d8b42b39f9d283bab489a757e9d284f0</id>
<content type='text'>
These new trace points record xarray indices and the time of
endpoint registration and unregistration, to co-ordinate with
device removal events.

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
</content>
</entry>
<entry>
<title>xprtrdma: Handle device removal outside of the CM event handler</title>
<updated>2024-07-08T17:47:24Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2024-06-04T19:45:25Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3f4eb9ff923413cdb4c7e171c06d3564f6286712'/>
<id>urn:sha1:3f4eb9ff923413cdb4c7e171c06d3564f6286712</id>
<content type='text'>
Wait for all disconnects to complete to ensure the transport has
divested all of its hardware resources before the underlying RDMA
device can be removed.

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
</content>
</entry>
<entry>
<title>rpcrdma: Implement generic device removal</title>
<updated>2024-07-08T17:47:24Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2024-06-04T19:45:24Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7e86845a0346efc95fddaa97ce5cd6a8bda8c71c'/>
<id>urn:sha1:7e86845a0346efc95fddaa97ce5cd6a8bda8c71c</id>
<content type='text'>
Commit e87a911fed07 ("nvme-rdma: use ib_client API to detect device
removal") explains the benefits of handling device removal outside
of the CM event handler.

Sketch in an IB device removal notification mechanism that can be
used by both the client and server side RPC-over-RDMA transport
implementations.

Suggested-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Anna Schumaker &lt;Anna.Schumaker@Netapp.com&gt;
</content>
</entry>
<entry>
<title>tracing/treewide: Remove second parameter of __assign_str()</title>
<updated>2024-05-23T00:14:47Z</updated>
<author>
<name>Steven Rostedt (Google)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2024-05-16T17:34:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2c92ca849fcc6ee7d0c358e9959abc9f58661aea'/>
<id>urn:sha1:2c92ca849fcc6ee7d0c358e9959abc9f58661aea</id>
<content type='text'>
With the rework of how the __string() handles dynamic strings where it
saves off the source string in field in the helper structure[1], the
assignment of that value to the trace event field is stored in the helper
value and does not need to be passed in again.

This means that with:

  __string(field, mystring)

Which use to be assigned with __assign_str(field, mystring), no longer
needs the second parameter and it is unused. With this, __assign_str()
will now only get a single parameter.

There's over 700 users of __assign_str() and because coccinelle does not
handle the TRACE_EVENT() macro I ended up using the following sed script:

  git grep -l __assign_str | while read a ; do
      sed -e 's/\(__assign_str([^,]*[^ ,]\) *,[^;]*/\1)/' $a &gt; /tmp/test-file;
      mv /tmp/test-file $a;
  done

I then searched for __assign_str() that did not end with ';' as those
were multi line assignments that the sed script above would fail to catch.

Note, the same updates will need to be done for:

  __assign_str_len()
  __assign_rel_str()
  __assign_rel_str_len()

I tested this with both an allmodconfig and an allyesconfig (build only for both).

[1] https://lore.kernel.org/linux-trace-kernel/20240222211442.634192653@goodmis.org/

Link: https://lore.kernel.org/linux-trace-kernel/20240516133454.681ba6a0@rorschach.local.home

Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Julia Lawall &lt;Julia.Lawall@inria.fr&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
Acked-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Acked-by: Christian König &lt;christian.koenig@amd.com&gt; for the amdgpu parts.
Acked-by: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt; #for
Acked-by: Rafael J. Wysocki &lt;rafael@kernel.org&gt; # for thermal
Acked-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Acked-by: Darrick J. Wong &lt;djwong@kernel.org&gt;	# xfs
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
</content>
</entry>
<entry>
<title>svcrdma: Move write_info for Reply chunks into struct svc_rdma_send_ctxt</title>
<updated>2024-03-01T14:12:28Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2024-02-04T23:17:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a1f5788a0c250c87d3007d59d11a00ab98e66f01'/>
<id>urn:sha1:a1f5788a0c250c87d3007d59d11a00ab98e66f01</id>
<content type='text'>
Since the RPC transaction's svc_rdma_send_ctxt will stay around for
the duration of the RDMA Write operation, the write_info structure
for the Reply chunk can reside in the request's svc_rdma_send_ctxt
instead of being allocated separately.

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>svcrdma: Copy construction of svc_rqst::rq_arg to rdma_read_complete()</title>
<updated>2024-01-07T22:54:33Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2023-12-18T22:32:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ecba85e951c178e3fe7cea04eebf1035e8168f93'/>
<id>urn:sha1:ecba85e951c178e3fe7cea04eebf1035e8168f93</id>
<content type='text'>
Once a set of RDMA Reads are complete, the Read completion handler
will poke the transport to trigger a second call to
svc_rdma_recvfrom(). recvfrom() will then merge the RDMA Read
payloads with the previously received RPC header to form a completed
RPC Call message.

The new code is copied from the svc_rdma_process_read_list() path.
A subsequent patch will make use of this code and remove the code
that this was copied from (svc_rdma_rw.c).

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>svcrdma: Update some svcrdma DMA-related tracepoints</title>
<updated>2024-01-07T22:54:28Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2023-11-27T16:33:50Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2dd6e29a3ea86ce51404589fd99597cd4dd0cd41'/>
<id>urn:sha1:2dd6e29a3ea86ce51404589fd99597cd4dd0cd41</id>
<content type='text'>
A send/recv_ctxt already records transport-related information
in the cq.id, thus there is no need to record the IP addresses of
the transport endpoints.

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>svcrdma: DMA error tracepoints should report completion IDs</title>
<updated>2024-01-07T22:54:28Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2023-11-27T16:33:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=848760a9e701cfab93a71374c1727491b0bc321e'/>
<id>urn:sha1:848760a9e701cfab93a71374c1727491b0bc321e</id>
<content type='text'>
Update the DMA error flow tracepoints to report the completion ID of
the failing context. This ties the wait/failure to a particular
operation or request, which is more useful than knowing only the
failing transport.

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
<entry>
<title>svcrdma: SQ error tracepoints should report completion IDs</title>
<updated>2024-01-07T22:54:27Z</updated>
<author>
<name>Chuck Lever</name>
<email>chuck.lever@oracle.com</email>
</author>
<published>2023-11-27T16:33:37Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ad3656bd84e0a91d4505095a0df7fbb6a8e0796a'/>
<id>urn:sha1:ad3656bd84e0a91d4505095a0df7fbb6a8e0796a</id>
<content type='text'>
Update the Send Queue's error flow tracepoints to report the
completion ID of the waiting or failing context. This ties the
wait/failure to a particular operation or request, which is a little
more useful than knowing only the transport that is about to close.

Signed-off-by: Chuck Lever &lt;chuck.lever@oracle.com&gt;
</content>
</entry>
</feed>
