<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 8/30/2025 3:57 AM, Stephen Hemminger
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20250829125734.7fd3aae2@hermes.local">
      <pre wrap="" class="moz-quote-pre">On Fri, 29 Aug 2025 22:49:52 +0800
Yang Ming <a class="moz-txt-link-rfc2396E" href="mailto:mosesyyoung@gmail.com"><mosesyyoung@gmail.com></a> wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="" class="moz-quote-pre">The current implementation hardcodes the socket file path to
/var/tmp, which has two issues:

1. Hardcoding absolute paths is not good practice.
2. /var/tmp may not be writable in containerized or restricted
   environments (e.g. when the filesystem is mounted read-only).

This patch replaces the hardcoded path with a socket file name
(MLX5_SOCKET_FNAME) located in the DPDK runtime directory
returned by rte_eal_get_runtime_dir(). This ensures the socket
file can be created in both normal and containerized
environments, while maintaining uniqueness by appending the
process ID.

Acked-by: Dariusz Sosnowski <a class="moz-txt-link-rfc2396E" href="mailto:dsosnowski@nvidia.com"><dsosnowski@nvidia.com></a>

Signed-off-by: Yang Ming <a class="moz-txt-link-rfc2396E" href="mailto:mosesyyoung@gmail.com"><mosesyyoung@gmail.com></a>
---
</pre>
      </blockquote>
      <pre wrap="" class="moz-quote-pre">
Rather driver specific logging, why is there not a way in EAL log
library to ope a diagnostic dump. </pre>
    </blockquote>
    <p><span style="white-space: pre-wrap">Hi,</span></p>
    Thanks for your comment. This patch is mainly an adaptation for<br>
    our product, which runs in container environments with read-only<br>
    filesystems. The goal is simply to remove the hard-coded /var/tmp<br>
    path while keeping backward compatibility with existing test cases.<br>
    <br>
    I agree that having a generic EAL facility for diagnostic dumps<br>
    would make sense in the longer term. However, I believe such<br>
    further development should be handled by the mlx5 driver<br>
    maintainers (Mellanox/NVIDIA), while this patch focuses only on<br>
    the immediate portability fix.<br>
    <br>
    Brs,<br>
    Yang Ming
  </body>
</html>