[PATCH v3 1/2] net/mlx5: improve socket file path handling

[Moses Young]

On 8/31/2025 11:21 AM, Stephen Hemminger wrote:

> On Sun, 31 Aug 2025 08:55:59 +0800
> Moses Young <mosesyyoung at gmail.com> wrote:
>
>> On 8/30/2025 3:57 AM, Stephen Hemminger wrote:
>>> On Fri, 29 Aug 2025 22:49:52 +0800
>>> Yang Ming<mosesyyoung at gmail.com> wrote:
>>>   
>>>> 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<dsosnowski at nvidia.com>
>>>>
>>>> Signed-off-by: Yang Ming<mosesyyoung at gmail.com>
>>>> ---
>>> Rather driver specific logging, why is there not a way in EAL log
>>> library to ope a diagnostic dump.
>> Hi,
>>
>> Thanks for your comment. This patch is mainly an adaptation for
>> our product, which runs in container environments with read-only
>> filesystems. The goal is simply to remove the hard-coded /var/tmp
>> path while keeping backward compatibility with existing test cases.
>>
>> I agree that having a generic EAL facility for diagnostic dumps
>> would make sense in the longer term. However, I believe such
>> further development should be handled by the mlx5 driver
>> maintainers (Mellanox/NVIDIA), while this patch focuses only on
>> the immediate portability fix.
>>
>> Brs,
>> Yang Ming
> The point is other drivers have the same container problem.
> And would be good to follow conventions that containers impose.
Hi Stephen,

Thanks a lot for the feedback and for pointing this out. At the
moment, our products is using Intel and Mellanox NICs.  We only
observed this container filesystem issue on Mellanox NICs while
the Intel driver works fine, so this patch is limited for now.

I fully agree that a more generic EAL-level solution would be
better for the broader ecosystem and future-proof for other
drivers as well. That seems to need wider discussion and input
from maintainers, but I'm glad to support or test if such work
is started.

Best regards,
Yang Ming