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

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

[Yang Ming]

1. /var/tmp is hard code which is not a good style
2. /var/tmp may be not allowed to be written via container's
read only mode.

Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
---
 drivers/net/mlx5/linux/mlx5_socket.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/mlx5/linux/mlx5_socket.c b/drivers/net/mlx5/linux/mlx5_socket.c
index 6ce0e59643..7fa6e5345c 100644
--- a/drivers/net/mlx5/linux/mlx5_socket.c
+++ b/drivers/net/mlx5/linux/mlx5_socket.c
@@ -20,7 +20,7 @@
 
 /* PMD socket service for tools. */
 
-#define MLX5_SOCKET_PATH "/var/tmp/dpdk_net_mlx5_%d"
+#define MLX5_SOCKET_FNAME "dpdk_net_mlx5"
 #define MLX5_ALL_PORT_IDS 0xffff
 
 int server_socket = -1; /* Unix socket for primary process. */
@@ -177,8 +177,8 @@ mlx5_pmd_socket_init(void)
 	ret = fcntl(server_socket, F_SETFL, flags | O_NONBLOCK);
 	if (ret < 0)
 		goto close;
-	snprintf(sun.sun_path, sizeof(sun.sun_path), MLX5_SOCKET_PATH,
-		 getpid());
+	snprintf(sun.sun_path, sizeof(sun.sun_path), "%s/%s_%d",
+		 rte_eal_get_runtime_dir(), MLX5_SOCKET_FNAME, getpid());
 	remove(sun.sun_path);
 	ret = bind(server_socket, (const struct sockaddr *)&sun, sizeof(sun));
 	if (ret < 0) {
@@ -223,6 +223,7 @@ mlx5_pmd_socket_uninit(void)
 					  mlx5_pmd_socket_handle, NULL);
 	claim_zero(close(server_socket));
 	server_socket = -1;
-	MKSTR(path, MLX5_SOCKET_PATH, getpid());
+	MKSTR(path, "%s/%s_%d", rte_eal_get_runtime_dir(), MLX5_SOCKET_FNAME,
+	      getpid());
 	claim_zero(remove(path));
 }
-- 
2.34.1

[PATCH 2/2] net/mlx5: improve log file path

[Yang Ming]

1. /var/log is hard code which is not a good coding style.
2. /var/log may be not allowed to be written via container's
read-only mode.

Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
---
 drivers/net/mlx5/mlx5_rxtx.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index eadadcdffb..a0da73c9c3 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -12,6 +12,7 @@
 #include <rte_prefetch.h>
 #include <rte_common.h>
 #include <rte_branch_prediction.h>
+#include <rte_eal.h>
 #include <rte_ether.h>
 #include <rte_cycles.h>
 #include <rte_flow.h>
@@ -311,7 +312,7 @@ mlx5_set_swp_types_table(void)
 	}
 }
 
-#define MLX5_SYSTEM_LOG_DIR "/var/log"
+#define MLX5_SYSTEM_LOG_DIR rte_eal_get_runtime_dir()
 /**
  * Dump debug information to log file.
  *
-- 
2.34.1

RE: [PATCH 2/2] net/mlx5: improve log file path

[Bing Zhao]

Hi Ming,

> -----Original Message-----
> From: Yang Ming <ming.1.yang@nokia-sbell.com>
> Sent: Friday, December 13, 2024 5:25 PM
> To: Dariusz Sosnowski <dsosnowski@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Bing Zhao <bingz@nvidia.com>; Ori Kam
> <orika@nvidia.com>; Suanming Mou <suanmingm@nvidia.com>; Matan Azrad
> <matan@nvidia.com>
> Cc: dev@dpdk.org; Yang Ming <ming.1.yang@nokia-sbell.com>
> Subject: [PATCH 2/2] net/mlx5: improve log file path
> 
> External email: Use caution opening links or attachments
> 
> 
> 1. /var/log is hard code which is not a good coding style.
> 2. /var/log may be not allowed to be written via container's read-only
> mode.
> 
> Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
> ---
>  drivers/net/mlx5/mlx5_rxtx.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
> index eadadcdffb..a0da73c9c3 100644
> --- a/drivers/net/mlx5/mlx5_rxtx.c
> +++ b/drivers/net/mlx5/mlx5_rxtx.c
> @@ -12,6 +12,7 @@
>  #include <rte_prefetch.h>
>  #include <rte_common.h>
>  #include <rte_branch_prediction.h>
> +#include <rte_eal.h>
>  #include <rte_ether.h>
>  #include <rte_cycles.h>
>  #include <rte_flow.h>
> @@ -311,7 +312,7 @@ mlx5_set_swp_types_table(void)
>         }
>  }
> 
> -#define MLX5_SYSTEM_LOG_DIR "/var/log"
> +#define MLX5_SYSTEM_LOG_DIR rte_eal_get_runtime_dir()

I agree that using the fixed PATH is not a good practice. Can you ensure that the runtime DIR is with RW+ permissions?

>  /**
>   * Dump debug information to log file.
>   *
> --
> 2.34.1

Re: [PATCH 2/2] net/mlx5: improve log file path

[Yang Ming]

On 2025/3/4 14:23, Bing Zhao wrote:
> Caution: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb for additional information.
>
> Hi Ming,
>
>> -----Original Message-----
>> From: Yang Ming <ming.1.yang@nokia-sbell.com>
>> Sent: Friday, December 13, 2024 5:25 PM
>> To: Dariusz Sosnowski <dsosnowski@nvidia.com>; Slava Ovsiienko
>> <viacheslavo@nvidia.com>; Bing Zhao <bingz@nvidia.com>; Ori Kam
>> <orika@nvidia.com>; Suanming Mou <suanmingm@nvidia.com>; Matan Azrad
>> <matan@nvidia.com>
>> Cc: dev@dpdk.org; Yang Ming <ming.1.yang@nokia-sbell.com>
>> Subject: [PATCH 2/2] net/mlx5: improve log file path
>>
>> External email: Use caution opening links or attachments
>>
>>
>> 1. /var/log is hard code which is not a good coding style.
>> 2. /var/log may be not allowed to be written via container's read-only
>> mode.
>>
>> Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
>> ---
>>   drivers/net/mlx5/mlx5_rxtx.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
>> index eadadcdffb..a0da73c9c3 100644
>> --- a/drivers/net/mlx5/mlx5_rxtx.c
>> +++ b/drivers/net/mlx5/mlx5_rxtx.c
>> @@ -12,6 +12,7 @@
>>   #include <rte_prefetch.h>
>>   #include <rte_common.h>
>>   #include <rte_branch_prediction.h>
>> +#include <rte_eal.h>
>>   #include <rte_ether.h>
>>   #include <rte_cycles.h>
>>   #include <rte_flow.h>
>> @@ -311,7 +312,7 @@ mlx5_set_swp_types_table(void)
>>          }
>>   }
>>
>> -#define MLX5_SYSTEM_LOG_DIR "/var/log"
>> +#define MLX5_SYSTEM_LOG_DIR rte_eal_get_runtime_dir()
> I agree that using the fixed PATH is not a good practice. Can you ensure that the runtime DIR is with RW+ permissions?
>
>>   /**
>>    * Dump debug information to log file.
>>    *
>> --
>> 2.34.1

Hi Bing,

Thanks for your comments.

Yes. Read-write (RW) permissions must be applied to this
directory because DPDK needs to write runtime information
to this directory such as config file, socket file etc.
Additionally, within the function stack, the
`eal_create_runtime_dir()` function includes the command
`mkdir(run_dir, 0700)`, indicating that the owner should
have read, write, and execute permissions.

Brs,
Yang Ming

Re: [PATCH 2/2] net/mlx5: improve log file path

[Stephen Hemminger]

On Tue, 4 Mar 2025 06:23:06 +0000
Bing Zhao <bingz@nvidia.com> wrote:

> Hi Ming,
> 
> > -----Original Message-----
> > From: Yang Ming <ming.1.yang@nokia-sbell.com>
> > Sent: Friday, December 13, 2024 5:25 PM
> > To: Dariusz Sosnowski <dsosnowski@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Bing Zhao <bingz@nvidia.com>; Ori Kam
> > <orika@nvidia.com>; Suanming Mou <suanmingm@nvidia.com>; Matan Azrad
> > <matan@nvidia.com>
> > Cc: dev@dpdk.org; Yang Ming <ming.1.yang@nokia-sbell.com>
> > Subject: [PATCH 2/2] net/mlx5: improve log file path
> > 
> > External email: Use caution opening links or attachments
> > 
> > 
> > 1. /var/log is hard code which is not a good coding style.
> > 2. /var/log may be not allowed to be written via container's read-only
> > mode.
> > 
> > Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
> > ---
> >  drivers/net/mlx5/mlx5_rxtx.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
> > index eadadcdffb..a0da73c9c3 100644
> > --- a/drivers/net/mlx5/mlx5_rxtx.c
> > +++ b/drivers/net/mlx5/mlx5_rxtx.c
> > @@ -12,6 +12,7 @@
> >  #include <rte_prefetch.h>
> >  #include <rte_common.h>
> >  #include <rte_branch_prediction.h>
> > +#include <rte_eal.h>
> >  #include <rte_ether.h>
> >  #include <rte_cycles.h>
> >  #include <rte_flow.h>
> > @@ -311,7 +312,7 @@ mlx5_set_swp_types_table(void)
> >         }
> >  }
> > 
> > -#define MLX5_SYSTEM_LOG_DIR "/var/log"
> > +#define MLX5_SYSTEM_LOG_DIR rte_eal_get_runtime_dir()  
> 
> I agree that using the fixed PATH is not a good practice. Can you ensure that the runtime DIR is with RW+ permissions?

Drivers doing any kind of custom logging is bad practice.
This should be handled by EAL logging, not private fprintf's

Re: [External] Re: [PATCH 2/2] net/mlx5: improve log file path

[Yang Ming]

On 2025/3/10 22:59, Stephen Hemminger wrote:
> Caution: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb for additional information.
>
> On Tue, 4 Mar 2025 06:23:06 +0000
> Bing Zhao <bingz@nvidia.com> wrote:
>
>> Hi Ming,
>>
>>> -----Original Message-----
>>> From: Yang Ming <ming.1.yang@nokia-sbell.com>
>>> Sent: Friday, December 13, 2024 5:25 PM
>>> To: Dariusz Sosnowski <dsosnowski@nvidia.com>; Slava Ovsiienko
>>> <viacheslavo@nvidia.com>; Bing Zhao <bingz@nvidia.com>; Ori Kam
>>> <orika@nvidia.com>; Suanming Mou <suanmingm@nvidia.com>; Matan Azrad
>>> <matan@nvidia.com>
>>> Cc: dev@dpdk.org; Yang Ming <ming.1.yang@nokia-sbell.com>
>>> Subject: [PATCH 2/2] net/mlx5: improve log file path
>>>
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> 1. /var/log is hard code which is not a good coding style.
>>> 2. /var/log may be not allowed to be written via container's read-only
>>> mode.
>>>
>>> Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
>>> ---
>>>   drivers/net/mlx5/mlx5_rxtx.c | 3 ++-
>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
>>> index eadadcdffb..a0da73c9c3 100644
>>> --- a/drivers/net/mlx5/mlx5_rxtx.c
>>> +++ b/drivers/net/mlx5/mlx5_rxtx.c
>>> @@ -12,6 +12,7 @@
>>>   #include <rte_prefetch.h>
>>>   #include <rte_common.h>
>>>   #include <rte_branch_prediction.h>
>>> +#include <rte_eal.h>
>>>   #include <rte_ether.h>
>>>   #include <rte_cycles.h>
>>>   #include <rte_flow.h>
>>> @@ -311,7 +312,7 @@ mlx5_set_swp_types_table(void)
>>>          }
>>>   }
>>>
>>> -#define MLX5_SYSTEM_LOG_DIR "/var/log"
>>> +#define MLX5_SYSTEM_LOG_DIR rte_eal_get_runtime_dir()
>> I agree that using the fixed PATH is not a good practice. Can you ensure that the runtime DIR is with RW+ permissions?
> Drivers doing any kind of custom logging is bad practice.
> This should be handled by EAL logging, not private fprintf's
>
>
>
Hi Stephen,

Yes, I completely agree with you. The DPDK driver should utilize EAL 
logging instead of fprintf. We have recently addressed an issue where 
DPDK was applied in a container with a read-only file system mode. In 
this mode, the /var/log directory is read-only. However, when DPDK is 
running, the directory specified by rte_eal_get_runtime_dir() must be 
configured with read-write permissions. Therefore, we have made this 
minor improvement.

Please note that we are not the developers of the Mellanox CX4/CX5 NIC, 
nor are we affiliated with the manufacturer of these NICs. As such, we 
are unable to make the improvements you described.

Brs,
Yang Ming

RE: [External] Re: [PATCH 2/2] net/mlx5: improve log file path

[Bing Zhao]

Hi Ming & Stephen,

> -----Original Message-----
> From: Yang Ming <ming.1.yang@nokia-sbell.com>
> Sent: Wednesday, March 12, 2025 10:33 AM
> To: Stephen Hemminger <stephen@networkplumber.org>; Bing Zhao
> <bingz@nvidia.com>
> Cc: Dariusz Sosnowski <dsosnowski@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; Suanming Mou
> <suanmingm@nvidia.com>; Matan Azrad <matan@nvidia.com>; dev@dpdk.org
> Subject: Re: [External] Re: [PATCH 2/2] net/mlx5: improve log file path
> 
> External email: Use caution opening links or attachments
> 
> 
> On 2025/3/10 22:59, Stephen Hemminger wrote:
> > Caution: This is an external email. Please be very careful when clicking
> links or opening attachments. See http://nok.it/nsb for additional
> information.
> >
> > On Tue, 4 Mar 2025 06:23:06 +0000
> > Bing Zhao <bingz@nvidia.com> wrote:
> >
> >> Hi Ming,
> >>
> >>> -----Original Message-----
> >>> From: Yang Ming <ming.1.yang@nokia-sbell.com>
> >>> Sent: Friday, December 13, 2024 5:25 PM
> >>> To: Dariusz Sosnowski <dsosnowski@nvidia.com>; Slava Ovsiienko
> >>> <viacheslavo@nvidia.com>; Bing Zhao <bingz@nvidia.com>; Ori Kam
> >>> <orika@nvidia.com>; Suanming Mou <suanmingm@nvidia.com>; Matan Azrad
> >>> <matan@nvidia.com>
> >>> Cc: dev@dpdk.org; Yang Ming <ming.1.yang@nokia-sbell.com>
> >>> Subject: [PATCH 2/2] net/mlx5: improve log file path
> >>>
> >>> External email: Use caution opening links or attachments
> >>>
> >>>
> >>> 1. /var/log is hard code which is not a good coding style.
> >>> 2. /var/log may be not allowed to be written via container's
> >>> read-only mode.
> >>>
> >>> Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
> >>> ---
> >>>   drivers/net/mlx5/mlx5_rxtx.c | 3 ++-
> >>>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/net/mlx5/mlx5_rxtx.c
> >>> b/drivers/net/mlx5/mlx5_rxtx.c index eadadcdffb..a0da73c9c3 100644
> >>> --- a/drivers/net/mlx5/mlx5_rxtx.c
> >>> +++ b/drivers/net/mlx5/mlx5_rxtx.c
> >>> @@ -12,6 +12,7 @@
> >>>   #include <rte_prefetch.h>
> >>>   #include <rte_common.h>
> >>>   #include <rte_branch_prediction.h>
> >>> +#include <rte_eal.h>
> >>>   #include <rte_ether.h>
> >>>   #include <rte_cycles.h>
> >>>   #include <rte_flow.h>
> >>> @@ -311,7 +312,7 @@ mlx5_set_swp_types_table(void)
> >>>          }
> >>>   }
> >>>
> >>> -#define MLX5_SYSTEM_LOG_DIR "/var/log"
> >>> +#define MLX5_SYSTEM_LOG_DIR rte_eal_get_runtime_dir()
> >> I agree that using the fixed PATH is not a good practice. Can you
> ensure that the runtime DIR is with RW+ permissions?
> > Drivers doing any kind of custom logging is bad practice.
> > This should be handled by EAL logging, not private fprintf's
> >
> >
> >
> Hi Stephen,
> 
> Yes, I completely agree with you. The DPDK driver should utilize EAL
> logging instead of fprintf. We have recently addressed an issue where DPDK
> was applied in a container with a read-only file system mode. In this
> mode, the /var/log directory is read-only. However, when DPDK is running,
> the directory specified by rte_eal_get_runtime_dir() must be configured
> with read-write permissions. Therefore, we have made this minor
> improvement.
> 
> Please note that we are not the developers of the Mellanox CX4/CX5 NIC,
> nor are we affiliated with the manufacturer of these NICs. As such, we are
> unable to make the improvements you described.
> 

I tend to disagree with such comments. Such dump will be generated when some error happens. We want to save the information into some file for offline analysis. I checked the code, current RTE_LOG routines do not have a variant that supports specified output stream but not only stdout/stderr/syslog. Only global PATH can be used. (correct me if I missed something) If there is an API can specify the output stream instead of the global set one, that should satisfy the needs.

Saving it into some file is a must. For example, if the customer is using a monitor with VGA display interface connected to the server directly or a BMC simulated console terminal, sometimes the previous prints will be flushed out of buffer of the screen if there are a lot of logs to be printed. There is even no scroll up/down can be used like via SSH vterm.

After some internal discussion with our experts, we thought it would be better not only to change the PATH blindly.
But we can firstly check/try to write to the default fixed PATH as today. If failed due to no permission/no space, then trying the fallback way to use the runtime_dir() instead. And then notify the user with a LOG that the file is saved into [PATH xxxx]. WDYT?

> Brs,
> Yang Ming

Re: [External] Re: [PATCH 2/2] net/mlx5: improve log file path

[Ming 1. Yang (NSB)]

On 2025/3/18 00:05, Bing Zhao wrote:
> Caution: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/nsb for additional information.
>
> Hi Ming & Stephen,
>
>> -----Original Message-----
>> From: Yang Ming <ming.1.yang@nokia-sbell.com>
>> Sent: Wednesday, March 12, 2025 10:33 AM
>> To: Stephen Hemminger <stephen@networkplumber.org>; Bing Zhao
>> <bingz@nvidia.com>
>> Cc: Dariusz Sosnowski <dsosnowski@nvidia.com>; Slava Ovsiienko
>> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; Suanming Mou
>> <suanmingm@nvidia.com>; Matan Azrad <matan@nvidia.com>; dev@dpdk.org
>> Subject: Re: [External] Re: [PATCH 2/2] net/mlx5: improve log file path
>>
>> External email: Use caution opening links or attachments
>>
>>
>> On 2025/3/10 22:59, Stephen Hemminger wrote:
>>> Caution: This is an external email. Please be very careful when clicking
>> links or opening attachments. See http://nok.it/nsb for additional
>> information.
>>> On Tue, 4 Mar 2025 06:23:06 +0000
>>> Bing Zhao <bingz@nvidia.com> wrote:
>>>
>>>> Hi Ming,
>>>>
>>>>> -----Original Message-----
>>>>> From: Yang Ming <ming.1.yang@nokia-sbell.com>
>>>>> Sent: Friday, December 13, 2024 5:25 PM
>>>>> To: Dariusz Sosnowski <dsosnowski@nvidia.com>; Slava Ovsiienko
>>>>> <viacheslavo@nvidia.com>; Bing Zhao <bingz@nvidia.com>; Ori Kam
>>>>> <orika@nvidia.com>; Suanming Mou <suanmingm@nvidia.com>; Matan Azrad
>>>>> <matan@nvidia.com>
>>>>> Cc: dev@dpdk.org; Yang Ming <ming.1.yang@nokia-sbell.com>
>>>>> Subject: [PATCH 2/2] net/mlx5: improve log file path
>>>>>
>>>>> External email: Use caution opening links or attachments
>>>>>
>>>>>
>>>>> 1. /var/log is hard code which is not a good coding style.
>>>>> 2. /var/log may be not allowed to be written via container's
>>>>> read-only mode.
>>>>>
>>>>> Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
>>>>> ---
>>>>>    drivers/net/mlx5/mlx5_rxtx.c | 3 ++-
>>>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/net/mlx5/mlx5_rxtx.c
>>>>> b/drivers/net/mlx5/mlx5_rxtx.c index eadadcdffb..a0da73c9c3 100644
>>>>> --- a/drivers/net/mlx5/mlx5_rxtx.c
>>>>> +++ b/drivers/net/mlx5/mlx5_rxtx.c
>>>>> @@ -12,6 +12,7 @@
>>>>>    #include <rte_prefetch.h>
>>>>>    #include <rte_common.h>
>>>>>    #include <rte_branch_prediction.h>
>>>>> +#include <rte_eal.h>
>>>>>    #include <rte_ether.h>
>>>>>    #include <rte_cycles.h>
>>>>>    #include <rte_flow.h>
>>>>> @@ -311,7 +312,7 @@ mlx5_set_swp_types_table(void)
>>>>>           }
>>>>>    }
>>>>>
>>>>> -#define MLX5_SYSTEM_LOG_DIR "/var/log"
>>>>> +#define MLX5_SYSTEM_LOG_DIR rte_eal_get_runtime_dir()
>>>> I agree that using the fixed PATH is not a good practice. Can you
>> ensure that the runtime DIR is with RW+ permissions?
>>> Drivers doing any kind of custom logging is bad practice.
>>> This should be handled by EAL logging, not private fprintf's
>>>
>>>
>>>
>> Hi Stephen,
>>
>> Yes, I completely agree with you. The DPDK driver should utilize EAL
>> logging instead of fprintf. We have recently addressed an issue where DPDK
>> was applied in a container with a read-only file system mode. In this
>> mode, the /var/log directory is read-only. However, when DPDK is running,
>> the directory specified by rte_eal_get_runtime_dir() must be configured
>> with read-write permissions. Therefore, we have made this minor
>> improvement.
>>
>> Please note that we are not the developers of the Mellanox CX4/CX5 NIC,
>> nor are we affiliated with the manufacturer of these NICs. As such, we are
>> unable to make the improvements you described.
>>
> I tend to disagree with such comments. Such dump will be generated when some error happens. We want to save the information into some file for offline analysis. I checked the code, current RTE_LOG routines do not have a variant that supports specified output stream but not only stdout/stderr/syslog. Only global PATH can be used. (correct me if I missed something) If there is an API can specify the output stream instead of the global set one, that should satisfy the needs.
>
> Saving it into some file is a must. For example, if the customer is using a monitor with VGA display interface connected to the server directly or a BMC simulated console terminal, sometimes the previous prints will be flushed out of buffer of the screen if there are a lot of logs to be printed. There is even no scroll up/down can be used like via SSH vterm.
>
> After some internal discussion with our experts, we thought it would be better not only to change the PATH blindly.
> But we can firstly check/try to write to the default fixed PATH as today. If failed due to no permission/no space, then trying the fallback way to use the runtime_dir() instead. And then notify the user with a LOG that the file is saved into [PATH xxxx]. WDYT?
>
>> Brs,
>> Yang Ming

Hi Dariusz & Bing,

Yes, I agree that the fallback mechanism is highly suitable for this 
scenario. It not only addresses the issue but also maintains 
compatibility with the original user cases, making it a better solution. 
I will enhance this patch shortly. Your assistance in reviewing it would 
be greatly appreciated.

Brs,
Yang Ming

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

[Stephen Hemminger]

On Fri, 13 Dec 2024 17:24:42 +0800
Yang Ming <ming.1.yang@nokia-sbell.com> wrote:

> 1. /var/tmp is hard code which is not a good style
> 2. /var/tmp may be not allowed to be written via container's
> read only mode.
> 
> Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>

Since this is a unix domain socket, why not use abstract socket
that doesn't have to be associated with filesystem?

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

[Bruce Richardson]

On Fri, Dec 13, 2024 at 09:12:39AM -0800, Stephen Hemminger wrote:
> On Fri, 13 Dec 2024 17:24:42 +0800
> Yang Ming <ming.1.yang@nokia-sbell.com> wrote:
> 
> > 1. /var/tmp is hard code which is not a good style
> > 2. /var/tmp may be not allowed to be written via container's
> > read only mode.
> > 
> > Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
> 
> Since this is a unix domain socket, why not use abstract socket
> that doesn't have to be associated with filesystem?

In general, I think we should avoid abstract sockets in DPDK. Primary
reason is that they are linux-specific. Last time I checked other unixes,
like BSD, don't support them. A secondary concern is that having a
filesystem path allows permission checks, so for e.g. telemetry sockets,
only users with appropriate permissions can connect. With an abstract socket
we'd have to open up the area of user authentication.

/Bruce

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

[Yang Ming]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]


On 2024/12/14 01:16, Bruce Richardson wrote:
> On Fri, Dec 13, 2024 at 09:12:39AM -0800, Stephen Hemminger wrote:
>> On Fri, 13 Dec 2024 17:24:42 +0800
>> Yang Ming<ming.1.yang@nokia-sbell.com>  wrote:
>>
>>> 1. /var/tmp is hard code which is not a good style
>>> 2. /var/tmp may be not allowed to be written via container's
>>> read only mode.
>>>
>>> Signed-off-by: Yang Ming<ming.1.yang@nokia-sbell.com>
>> Since this is a unix domain socket, why not use abstract socket
>> that doesn't have to be associated with filesystem?
> In general, I think we should avoid abstract sockets in DPDK. Primary
> reason is that they are linux-specific. Last time I checked other unixes,
> like BSD, don't support them. A secondary concern is that having a
> filesystem path allows permission checks, so for e.g. telemetry sockets,
> only users with appropriate permissions can connect. With an abstract socket
> we'd have to open up the area of user authentication.
>
> /Bruce
>
Hi Stephen & Bruce,

I'm not sure whether abstract socket is a good idea. Maybe it can be improved further or step by step. But we don't need to discuss it for this commit.
We do this improvement because "/var/tmp" and "/var/log" can't be write in Readonly mode of container except that we add /var/ specfic for DPDK application in container's setting. But nearly all DPDK modules have already used common runtime path returned from `rte_eal_get_runtime_dir()`. Why not we apply this common path for Mellanox NIC?



[-- Attachment #2: Type: text/html, Size: 2470 bytes --]

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

[Yang Ming]

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]


On 2025/1/3 10:51, Ming 1. Yang (NSB) wrote:
>
>
> On 2024/12/14 01:16, Bruce Richardson wrote:
>> On Fri, Dec 13, 2024 at 09:12:39AM -0800, Stephen Hemminger wrote:
>>> On Fri, 13 Dec 2024 17:24:42 +0800
>>> Yang Ming<ming.1.yang@nokia-sbell.com>  wrote:
>>>
>>>> 1. /var/tmp is hard code which is not a good style
>>>> 2. /var/tmp may be not allowed to be written via container's
>>>> read only mode.
>>>>
>>>> Signed-off-by: Yang Ming<ming.1.yang@nokia-sbell.com>
>>> Since this is a unix domain socket, why not use abstract socket
>>> that doesn't have to be associated with filesystem?
>> In general, I think we should avoid abstract sockets in DPDK. Primary
>> reason is that they are linux-specific. Last time I checked other unixes,
>> like BSD, don't support them. A secondary concern is that having a
>> filesystem path allows permission checks, so for e.g. telemetry sockets,
>> only users with appropriate permissions can connect. With an abstract socket
>> we'd have to open up the area of user authentication.
>>
>> /Bruce
>>
> Hi Stephen & Bruce,
>
> I'm not sure whether abstract socket is a good idea. Maybe it can be improved further or step by step. But we don't need to discuss it for this commit.
> We do this improvement because "/var/tmp" and "/var/log" can't be write in Readonly mode of container except that we add /var/ specfic for DPDK application in container's setting. But nearly all DPDK modules have already used common runtime path returned from `rte_eal_get_runtime_dir()`. Why not we apply this common path for Mellanox NIC?
>
>
>
Hi Stephen,

I'm not entirely sure whether using an abstract socket is the best 
approach. It might be possible to improve it further or incrementally. 
However, we don't need to discuss this for the current commit.
We made this improvement because the directories "/var/tmp" and 
"/var/log" cannot be written to in a container with read-only mode, 
unless we specifically configure the /var/ directory for the DPDK 
application in the container's settings. Nearly all DPDK modules already 
use the common runtime path returned by rte_eal_get_runtime_dir(). 
Therefore, it makes sense to apply this common path for the Mellanox NIC 
as well.
Actually, the objective of this patch series is to prevent the DPDK 
Mellanox driver from crashing when attempting to access the read-only 
directories "/var/" in a container.

Brs,
Yang Ming

[-- Attachment #2: Type: text/html, Size: 3739 bytes --]

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

[Dariusz Sosnowski]

Hi,

> From: Yang Ming <ming.1.yang@nokia-sbell.com> 
> Sent: Wednesday, March 12, 2025 3:56 AM
> To: Bruce Richardson <bruce.richardson@intel.com>; Stephen Hemminger <stephen@networkplumber.org>
> Cc: Dariusz Sosnowski <dsosnowski@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>; Bing Zhao <bingz@nvidia.com>; Ori Kam <orika@nvidia.com>; > Suanming Mou <suanmingm@nvidia.com>; Matan Azrad <matan@nvidia.com>; dev@dpdk.org
> Subject: Re: [PATCH 1/2] net/mlx5: improve socket file path
> 
> External email: Use caution opening links or attachments 
> 
> 
> On 2025/1/3 10:51, Ming 1. Yang (NSB) wrote:
> 
> On 2024/12/14 01:16, Bruce Richardson wrote: 
> On Fri, Dec 13, 2024 at 09:12:39AM -0800, Stephen Hemminger wrote:
> On Fri, 13 Dec 2024 17:24:42 +0800
> Yang Ming mailto:ming.1.yang@nokia-sbell.com wrote:
> 
> 1. /var/tmp is hard code which is not a good style
> 2. /var/tmp may be not allowed to be written via container's
> read only mode.
> 
> Signed-off-by: Yang Ming mailto:ming.1.yang@nokia-sbell.com
> Since this is a unix domain socket, why not use abstract socket
> that doesn't have to be associated with filesystem?
> In general, I think we should avoid abstract sockets in DPDK. Primary
> reason is that they are linux-specific. Last time I checked other unixes,
> like BSD, don't support them. A secondary concern is that having a
> filesystem path allows permission checks, so for e.g. telemetry sockets,
> only users with appropriate permissions can connect. With an abstract socket
> we'd have to open up the area of user authentication.
> 
> /Bruce
> 
> Hi Stephen & Bruce,
> I'm not sure whether abstract socket is a good idea. Maybe it can be improved further or step by step. But we don't need to discuss it for this commit. 
> We do this improvement because "/var/tmp" and "/var/log" can't be write in Readonly mode of container except that we add /var/ specfic for DPDK > application in container's setting. But nearly all DPDK modules have already used common runtime path returned from `rte_eal_get_runtime_dir()`. Why > not we apply this common path for Mellanox NIC?
> 
> 
> 
> Hi Stephen,
> 
> I'm not entirely sure whether using an abstract socket is the best approach. It might be possible to improve it further or incrementally. However, we > don't need to discuss this for the current commit.
> We made this improvement because the directories "/var/tmp" and "/var/log" cannot be written to in a container with read-only mode, unless we > specifically configure the /var/ directory for the DPDK application in the container's settings. Nearly all DPDK modules already use the common runtime > path returned by rte_eal_get_runtime_dir(). Therefore, it makes sense to apply this common path for the Mellanox NIC as well.
> Actually, the objective of this patch series is to prevent the DPDK Mellanox driver from crashing when attempting to access the read-only directories "/> var/" in a container.
> 
> Brs,
> Yang Ming

Let me provide the context for the functionality in question here.

mlx5 PMD has an ability to dump HW flow rules using mlx_steering_dump tool
(documented in https://doc.dpdk.org/guides/nics/mlx5.html#how-to-dump-flows and in https://github.com/Mellanox/mlx_steering_dump/tree/master/hws).
Dumping itself is supported only on Linux.
There are 2 ways to use that tool:

1. Application calls rte_flow_dev_dump(), providing FILE* handle.
  This saves the flow rules metadata (e.g., IDs of HW objects) in the file.
  mlx_steering_dump tool is then used to parse it and dump HW rules.
2. mlx_steering_dump communicates through the Unix socket with mlx5 PMD, sharing destination file descriptor of output metadata file with DPDK process through SCM_RIGHTS mechanism.
  mlx5 PMD internally calls rte_flow_dev_dump(), passing the provided file.
  After dumping is done, the tool parses the metadata file and extracts rules from the HW.

In practice, 2nd option is the more frequently used one, because of its convenience since it does not require modification of application code.
It has also the benefit that the tool itself owns the output dump file e.g., tool could be called from outside of the container and debug dump will be generated in host's context, not container context (assuming socket path is mounted on the host).
This is the case for example when containers use VFs of mlx5 NICs.

Changing the filesystem path of the Unix socket would require the update of all the tooling - there would be a need to copy the logic of runtime directory discovery (like it is done in dpdk-telemetry.py).
Until it is done, this change would introduce a breakage for existing users.

What do you think about fallback mechanism here? If "/var/tmp" is read-only or creation of the socket on this path fails, then socket will be created in EAL runtime directory.

Best regards,
Dariusz Sosnowski

[PATCH v2 1/2] net/mlx5: enhance socket file path

[Yang Ming]

The directory /var/tmp may not be writable in a container's
read-only mode. To address this issue, use the DPDK runtime
directory as an alternative when /var/tmp is not writable.

Cc: bingz@nvidia.com
Cc: dsosnowski@nvidia.com
Cc: stephen@networkplumber.org
Cc: julien.meunier@nokia.com

Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
---
 drivers/net/mlx5/linux/mlx5_socket.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mlx5/linux/mlx5_socket.c b/drivers/net/mlx5/linux/mlx5_socket.c
index 6ce0e59643..270a105f1d 100644
--- a/drivers/net/mlx5/linux/mlx5_socket.c
+++ b/drivers/net/mlx5/linux/mlx5_socket.c
@@ -20,7 +20,8 @@
 
 /* PMD socket service for tools. */
 
-#define MLX5_SOCKET_PATH "/var/tmp/dpdk_net_mlx5_%d"
+#define MLX5_SOCKET_DPATH "/var/tmp"
+#define MLX5_SOCKET_FNAME "dpdk_net_mlx5"
 #define MLX5_ALL_PORT_IDS 0xffff
 
 int server_socket = -1; /* Unix socket for primary process. */
@@ -177,8 +178,13 @@ mlx5_pmd_socket_init(void)
 	ret = fcntl(server_socket, F_SETFL, flags | O_NONBLOCK);
 	if (ret < 0)
 		goto close;
-	snprintf(sun.sun_path, sizeof(sun.sun_path), MLX5_SOCKET_PATH,
-		 getpid());
+
+	if (access(MLX5_SOCKET_DPATH, W_OK) == 0)
+		snprintf(sun.sun_path, sizeof(sun.sun_path), "%s/%s_%d",
+			 MLX5_SOCKET_DPATH, MLX5_SOCKET_FNAME, getpid());
+	else
+		snprintf(sun.sun_path, sizeof(sun.sun_path), "%s/%s_%d",
+			 rte_eal_get_runtime_dir(), MLX5_SOCKET_FNAME, getpid());
 	remove(sun.sun_path);
 	ret = bind(server_socket, (const struct sockaddr *)&sun, sizeof(sun));
 	if (ret < 0) {
@@ -223,6 +229,13 @@ mlx5_pmd_socket_uninit(void)
 					  mlx5_pmd_socket_handle, NULL);
 	claim_zero(close(server_socket));
 	server_socket = -1;
-	MKSTR(path, MLX5_SOCKET_PATH, getpid());
-	claim_zero(remove(path));
+	if (access(MLX5_SOCKET_DPATH, W_OK) == 0) {
+		MKSTR(path, "%s/%s_%d", MLX5_SOCKET_DPATH, MLX5_SOCKET_FNAME,
+		      getpid());
+		claim_zero(remove(path));
+	} else {
+		MKSTR(path2, "%s/%s_%d", rte_eal_get_runtime_dir(), MLX5_SOCKET_FNAME,
+		      getpid());
+		claim_zero(remove(path2));
+	}
 }
-- 
2.34.1

[PATCH v2 2/2] net/mlx5: enhance log file path

[Yang Ming]

The directory /var/log may not be writable in a container's
read-only mode. To address this issue, use the DPDK runtime
directory as an alternative when /var/log is not writable.

Cc: bingz@nvidia.com
Cc: dsosnowski@nvidia.com
Cc: stephen@networkplumber.org
Cc: julien.meunier@nokia.com

Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
---
 drivers/net/mlx5/mlx5_rxtx.c | 33 ++++++++++++++++++++++++---------
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 9c075f6a56..9e63d38524 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -6,12 +6,14 @@
 #include <stdint.h>
 #include <string.h>
 #include <stdlib.h>
+#include <unistd.h>
 
 #include <rte_mbuf.h>
 #include <rte_mempool.h>
 #include <rte_prefetch.h>
 #include <rte_common.h>
 #include <rte_branch_prediction.h>
+#include <rte_eal.h>
 #include <rte_ether.h>
 #include <rte_cycles.h>
 #include <rte_flow.h>
@@ -411,20 +413,33 @@ mlx5_dump_debug_information(const char *fname, const char *hex_title,
 {
 	FILE *fd;
 
-	MKSTR(path, "%s/%s", MLX5_SYSTEM_LOG_DIR, fname);
-	fd = fopen(path, "a+");
-	if (!fd) {
-		DRV_LOG(WARNING, "cannot open %s for debug dump", path);
-		MKSTR(path2, "./%s", fname);
+	if (access(MLX5_SYSTEM_LOG_DIR, W_OK) == 0) {
+		MKSTR(path, "%s/%s", MLX5_SYSTEM_LOG_DIR, fname);
+		fd = fopen(path, "a+");
+		if (!fd)
+			DRV_LOG(WARNING, "cannot open %s for debug dump", path);
+		else
+			DRV_LOG(INFO, "New debug dump in file %s", path);
+	} else {
+		MKSTR(path2, "%s/%s", rte_eal_get_runtime_dir(), fname);
 		fd = fopen(path2, "a+");
+		if (!fd)
+			DRV_LOG(WARNING, "cannot open %s for debug dump", path2);
+		else
+			DRV_LOG(INFO, "New debug dump in file %s", path2);
+	}
+
+	if (!fd) {
+		MKSTR(path3, "./%s", fname);
+		fd = fopen(path3, "a+");
 		if (!fd) {
-			DRV_LOG(ERR, "cannot open %s for debug dump", path2);
+			DRV_LOG(ERR, "cannot open %s for debug dump", path3);
 			return;
+		} else {
+			DRV_LOG(INFO, "New debug dump in file %s", path3);
 		}
-		DRV_LOG(INFO, "New debug dump in file %s", path2);
-	} else {
-		DRV_LOG(INFO, "New debug dump in file %s", path);
 	}
+
 	if (hex_title)
 		rte_hexdump(fd, hex_title, buf, hex_len);
 	else
-- 
2.34.1

Re: [PATCH v2 2/2] net/mlx5: enhance log file path

[Yang Ming]

On 2025/3/21 21:27, Yang Ming wrote:
> The directory /var/log may not be writable in a container's
> read-only mode. To address this issue, use the DPDK runtime
> directory as an alternative when /var/log is not writable.
>
> Cc: bingz@nvidia.com
> Cc: dsosnowski@nvidia.com
> Cc: stephen@networkplumber.org
> Cc: julien.meunier@nokia.com
>
> Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
> ---
>   drivers/net/mlx5/mlx5_rxtx.c | 33 ++++++++++++++++++++++++---------
>   1 file changed, 24 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
> index 9c075f6a56..9e63d38524 100644
> --- a/drivers/net/mlx5/mlx5_rxtx.c
> +++ b/drivers/net/mlx5/mlx5_rxtx.c
> @@ -6,12 +6,14 @@
>   #include <stdint.h>
>   #include <string.h>
>   #include <stdlib.h>
> +#include <unistd.h>
>   
>   #include <rte_mbuf.h>
>   #include <rte_mempool.h>
>   #include <rte_prefetch.h>
>   #include <rte_common.h>
>   #include <rte_branch_prediction.h>
> +#include <rte_eal.h>
>   #include <rte_ether.h>
>   #include <rte_cycles.h>
>   #include <rte_flow.h>
> @@ -411,20 +413,33 @@ mlx5_dump_debug_information(const char *fname, const char *hex_title,
>   {
>   	FILE *fd;
>   
> -	MKSTR(path, "%s/%s", MLX5_SYSTEM_LOG_DIR, fname);
> -	fd = fopen(path, "a+");
> -	if (!fd) {
> -		DRV_LOG(WARNING, "cannot open %s for debug dump", path);
> -		MKSTR(path2, "./%s", fname);
> +	if (access(MLX5_SYSTEM_LOG_DIR, W_OK) == 0) {
> +		MKSTR(path, "%s/%s", MLX5_SYSTEM_LOG_DIR, fname);
> +		fd = fopen(path, "a+");
> +		if (!fd)
> +			DRV_LOG(WARNING, "cannot open %s for debug dump", path);
> +		else
> +			DRV_LOG(INFO, "New debug dump in file %s", path);
> +	} else {
> +		MKSTR(path2, "%s/%s", rte_eal_get_runtime_dir(), fname);
>   		fd = fopen(path2, "a+");
> +		if (!fd)
> +			DRV_LOG(WARNING, "cannot open %s for debug dump", path2);
> +		else
> +			DRV_LOG(INFO, "New debug dump in file %s", path2);
> +	}
> +
> +	if (!fd) {
> +		MKSTR(path3, "./%s", fname);
> +		fd = fopen(path3, "a+");
>   		if (!fd) {
> -			DRV_LOG(ERR, "cannot open %s for debug dump", path2);
> +			DRV_LOG(ERR, "cannot open %s for debug dump", path3);
>   			return;
> +		} else {
> +			DRV_LOG(INFO, "New debug dump in file %s", path3);
>   		}
> -		DRV_LOG(INFO, "New debug dump in file %s", path2);
> -	} else {
> -		DRV_LOG(INFO, "New debug dump in file %s", path);
>   	}
> +
>   	if (hex_title)
>   		rte_hexdump(fd, hex_title, buf, hex_len);
>   	else
Hi Experts,

is there any chance to review and accept this patch?

Brs,

Yang Ming

Re: [PATCH v2 2/2] net/mlx5: enhance log file path

[Moses Young]

> Hi Experts,
>
> is there any chance to review and accept this patch?
>
> Brs,
>
> Yang Ming
>

RE: [PATCH v2 2/2] net/mlx5: enhance log file path

[Maayan Kashani]

Hi, Yang,
Thanks for contributing,
There are some failing CI tests.
Can you fix it?
 https://patches.dpdk.org/project/dpdk/patch/20250321132750.4237-2-ming.1.yang@nokia-sbell.com/

Regards,
Maayan Kashani

> -----Original Message-----
> From: Moses Young <mosesyyoung@gmail.com>
> Sent: Monday, 12 May 2025 13:13
> To: Yang Ming <ming.1.yang@nokia-sbell.com>; dev@dpdk.org
> Cc: Bing Zhao <bingz@nvidia.com>; Dariusz Sosnowski
> <dsosnowski@nvidia.com>; stephen@networkplumber.org;
> julien.meunier@nokia.com
> Subject: Re: [PATCH v2 2/2] net/mlx5: enhance log file path
> 
> External email: Use caution opening links or attachments
> 
> 
> > Hi Experts,
> >
> > is there any chance to review and accept this patch?
> >
> > Brs,
> >
> > Yang Ming
> >

Re: [PATCH v2 2/2] net/mlx5: enhance log file path

[Dariusz Sosnowski]

Hi Yang,

This patch breaks compilation on Windows:
https://lab.dpdk.org/results/dashboard/testruns/logs/1600918/

The problem is that mlx5_rxtx.c is used on both Linux and Windows.

Would you be able to fix the patch?
I suggest to do the following:

- Declare a function mlx5_os_debug_dump_file_open() in mlx5.h.
- Define it in drivers/net/mlx5/linux/mlx5_os.c.
  Here the existing logic from the patch can be used to open the file.
- Define it in drivers/net/mlx5/windows/mlx5_os.c.
  Here we can rely on rte_eal_get_runtime_dir() only,
  since MLX5_SYSTEM_LOG_DIR is not defined correctly to work
  on Windows as well.
  (see https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/access-waccess?view=msvc-170)
- Replace the opening of the file in mlx5_dump_debug_information()
  with mlx5_os_debug_dump_file_open().

Best regards,
Dariusz Sosnowski

On Wed, Jun 04, 2025 at 06:54:05AM +0000, Maayan Kashani wrote:
> Hi, Yang,
> Thanks for contributing,
> There are some failing CI tests.
> Can you fix it?
>  https://patches.dpdk.org/project/dpdk/patch/20250321132750.4237-2-ming.1.yang@nokia-sbell.com/
> 
> Regards,
> Maayan Kashani
> 
> > -----Original Message-----
> > From: Moses Young <mosesyyoung@gmail.com>
> > Sent: Monday, 12 May 2025 13:13
> > To: Yang Ming <ming.1.yang@nokia-sbell.com>; dev@dpdk.org
> > Cc: Bing Zhao <bingz@nvidia.com>; Dariusz Sosnowski
> > <dsosnowski@nvidia.com>; stephen@networkplumber.org;
> > julien.meunier@nokia.com
> > Subject: Re: [PATCH v2 2/2] net/mlx5: enhance log file path
> > 
> > External email: Use caution opening links or attachments
> > 
> > 
> > > Hi Experts,
> > >
> > > is there any chance to review and accept this patch?
> > >
> > > Brs,
> > >
> > > Yang Ming
> > >

Re: [PATCH v2 2/2] net/mlx5: enhance log file path

[Moses Young]

Hi Dariusz,

Thanks for your comment. I will try to fix this issue in next version.

Brs,

Yang Ming

Re: [PATCH v2 1/2] net/mlx5: enhance socket file path

[Dariusz Sosnowski]

On Fri, Mar 21, 2025 at 09:27:49PM +0800, Yang Ming wrote:
> The directory /var/tmp may not be writable in a container's
> read-only mode. To address this issue, use the DPDK runtime
> directory as an alternative when /var/tmp is not writable.
> 
> Cc: bingz@nvidia.com
> Cc: dsosnowski@nvidia.com
> Cc: stephen@networkplumber.org
> Cc: julien.meunier@nokia.com
> 
> Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>

Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>

Best regards,
Dariusz Sosnowski

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

[Yang Ming]

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@nvidia.com>

Signed-off-by: Yang Ming <mosesyyoung@gmail.com>
---
 drivers/net/mlx5/linux/mlx5_socket.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/net/mlx5/linux/mlx5_socket.c b/drivers/net/mlx5/linux/mlx5_socket.c
index 6ce0e59643..270a105f1d 100644
--- a/drivers/net/mlx5/linux/mlx5_socket.c
+++ b/drivers/net/mlx5/linux/mlx5_socket.c
@@ -20,7 +20,8 @@
 
 /* PMD socket service for tools. */
 
-#define MLX5_SOCKET_PATH "/var/tmp/dpdk_net_mlx5_%d"
+#define MLX5_SOCKET_DPATH "/var/tmp"
+#define MLX5_SOCKET_FNAME "dpdk_net_mlx5"
 #define MLX5_ALL_PORT_IDS 0xffff
 
 int server_socket = -1; /* Unix socket for primary process. */
@@ -177,8 +178,13 @@ mlx5_pmd_socket_init(void)
 	ret = fcntl(server_socket, F_SETFL, flags | O_NONBLOCK);
 	if (ret < 0)
 		goto close;
-	snprintf(sun.sun_path, sizeof(sun.sun_path), MLX5_SOCKET_PATH,
-		 getpid());
+
+	if (access(MLX5_SOCKET_DPATH, W_OK) == 0)
+		snprintf(sun.sun_path, sizeof(sun.sun_path), "%s/%s_%d",
+			 MLX5_SOCKET_DPATH, MLX5_SOCKET_FNAME, getpid());
+	else
+		snprintf(sun.sun_path, sizeof(sun.sun_path), "%s/%s_%d",
+			 rte_eal_get_runtime_dir(), MLX5_SOCKET_FNAME, getpid());
 	remove(sun.sun_path);
 	ret = bind(server_socket, (const struct sockaddr *)&sun, sizeof(sun));
 	if (ret < 0) {
@@ -223,6 +229,13 @@ mlx5_pmd_socket_uninit(void)
 					  mlx5_pmd_socket_handle, NULL);
 	claim_zero(close(server_socket));
 	server_socket = -1;
-	MKSTR(path, MLX5_SOCKET_PATH, getpid());
-	claim_zero(remove(path));
+	if (access(MLX5_SOCKET_DPATH, W_OK) == 0) {
+		MKSTR(path, "%s/%s_%d", MLX5_SOCKET_DPATH, MLX5_SOCKET_FNAME,
+		      getpid());
+		claim_zero(remove(path));
+	} else {
+		MKSTR(path2, "%s/%s_%d", rte_eal_get_runtime_dir(), MLX5_SOCKET_FNAME,
+		      getpid());
+		claim_zero(remove(path2));
+	}
 }
-- 
2.49.0.windows.1

[PATCH v3 2/2] net/mlx5: improve debug dump file path handling

[Yang Ming]

The current implementation always tries to open debug dump files
under /var/log, which may not be writable in containerized or
restricted environments (e.g. when the filesystem is mounted as
read-only).

This patch introduces an OS-specific helper function
mlx5_os_debug_dump_file_open() to unify the logic:

* On Linux:
  1. Try /var/log if it is writable (kept for backward
     compatibility).
  2. Fallback to the DPDK runtime directory.
  3. Finally, use the current working directory.

* On Windows:
  1. Use the DPDK runtime directory.
  2. Fallback to the current working directory.

This preserves the previous directory preference while ensuring
debug dumps can still be written in restricted environments such
as containers. The structure of the open logic is kept unchanged
so that test cases and expected logs remain valid.

Signed-off-by: Yang Ming <mosesyyoung@gmail.com>
---
 drivers/net/mlx5/linux/mlx5_os.c   | 44 ++++++++++++++++++++++++++++++
 drivers/net/mlx5/mlx5.h            |  1 +
 drivers/net/mlx5/mlx5_rxtx.c       | 16 ++---------
 drivers/net/mlx5/windows/mlx5_os.c | 30 ++++++++++++++++++++
 4 files changed, 78 insertions(+), 13 deletions(-)

diff --git a/drivers/net/mlx5/linux/mlx5_os.c b/drivers/net/mlx5/linux/mlx5_os.c
index 696a3e12c7..fdb2102cd5 100644
--- a/drivers/net/mlx5/linux/mlx5_os.c
+++ b/drivers/net/mlx5/linux/mlx5_os.c
@@ -3020,6 +3020,50 @@ mlx5_os_net_cleanup(void)
 	mlx5_pmd_socket_uninit();
 }
 
+/* Default system log directory on Linux. */
+#define MLX5_SYSTEM_LOG_DIR "/var/log"
+
+/*
+ * Open a debug dump file on Linux.
+ *
+ * The function attempts to create/open the file in the following order:
+ * 1. /var/log (if writable),
+ * 2. EAL runtime directory,
+ * 3. current working directory ("./").
+ */
+FILE *
+mlx5_os_debug_dump_file_open(const char *fname)
+{
+	FILE *fd = NULL;
+
+	if (access(MLX5_SYSTEM_LOG_DIR, W_OK) == 0) {
+		MKSTR(path, "%s/%s", MLX5_SYSTEM_LOG_DIR, fname);
+		fd = fopen(path, "a+");
+		if (fd) {
+			DRV_LOG(INFO, "New debug dump in file %s", path);
+			return fd;
+		}
+		DRV_LOG(WARNING, "cannot open %s for debug dump", path);
+	}
+
+	MKSTR(path2, "%s/%s", rte_eal_get_runtime_dir(), fname);
+	fd = fopen(path2, "a+");
+	if (fd) {
+		DRV_LOG(INFO, "New debug dump in file %s", path2);
+		return fd;
+	}
+	DRV_LOG(WARNING, "cannot open %s for debug dump", path2);
+
+	MKSTR(path3, "./%s", fname);
+	fd = fopen(path3, "a+");
+	if (fd)
+		DRV_LOG(INFO, "New debug dump in file %s", path3);
+	else
+		DRV_LOG(ERR, "cannot open %s for debug dump", path3);
+
+	return fd;
+}
+
 /**
  * Install shared asynchronous device events handler.
  * This function is implemented to support event sharing
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index c08894cd03..fc7ac08039 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -2597,6 +2597,7 @@ int mlx5_os_capabilities_prepare(struct mlx5_dev_ctx_shared *sh);
 void mlx5_os_free_shared_dr(struct mlx5_priv *priv);
 int mlx5_os_net_probe(struct mlx5_common_device *cdev,
 		      struct mlx5_kvargs_ctrl *mkvlist);
+FILE *mlx5_os_debug_dump_file_open(const char *name);
 void mlx5_os_dev_shared_handler_install(struct mlx5_dev_ctx_shared *sh);
 void mlx5_os_dev_shared_handler_uninstall(struct mlx5_dev_ctx_shared *sh);
 void mlx5_os_mac_addr_remove(struct rte_eth_dev *dev, uint32_t index);
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 82c5481ad7..b35365ffd3 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -391,7 +391,6 @@ mlx5_set_swp_types_table(void)
 	}
 }
 
-#define MLX5_SYSTEM_LOG_DIR "/var/log"
 /**
  * Dump debug information to log file.
  *
@@ -411,20 +410,11 @@ mlx5_dump_debug_information(const char *fname, const char *hex_title,
 {
 	FILE *fd;
 
-	MKSTR(path, "%s/%s", MLX5_SYSTEM_LOG_DIR, fname);
-	fd = fopen(path, "a+");
+	fd = mlx5_os_debug_dump_file_open(fname);
 	if (!fd) {
-		DRV_LOG(WARNING, "cannot open %s for debug dump", path);
-		MKSTR(path2, "./%s", fname);
-		fd = fopen(path2, "a+");
-		if (!fd) {
-			DRV_LOG(ERR, "cannot open %s for debug dump", path2);
-			return;
-		}
-		DRV_LOG(INFO, "New debug dump in file %s", path2);
-	} else {
-		DRV_LOG(INFO, "New debug dump in file %s", path);
+		return;
 	}
+
 	if (hex_title)
 		rte_hexdump(fd, hex_title, buf, hex_len);
 	else
diff --git a/drivers/net/mlx5/windows/mlx5_os.c b/drivers/net/mlx5/windows/mlx5_os.c
index d583730066..734b71e3f7 100644
--- a/drivers/net/mlx5/windows/mlx5_os.c
+++ b/drivers/net/mlx5/windows/mlx5_os.c
@@ -629,6 +629,36 @@ mlx5_dev_spawn(struct rte_device *dpdk_dev,
 	return NULL;
 }
 
+/*
+ * Open a debug dump file on Windows.
+ *
+ * The function attempts to create/open the file in the following order:
+ * 1. EAL runtime directory,
+ * 2. current working directory ("./").
+ */
+FILE *
+mlx5_os_debug_dump_file_open(const char *fname)
+{
+	FILE *fd = NULL;
+
+	MKSTR(path, "%s/%s", rte_eal_get_runtime_dir(), fname);
+	fd = fopen(path, "a+");
+	if (fd) {
+		DRV_LOG(INFO, "New debug dump in file %s", path);
+		return fd;
+	}
+	DRV_LOG(WARNING, "cannot open %s for debug dump", path);
+
+	MKSTR(path2, "./%s", fname);
+	fd = fopen(path2, "a+");
+	if (fd)
+		DRV_LOG(INFO, "New debug dump in file %s", path2);
+	else
+		DRV_LOG(ERR, "cannot open %s for debug dump", path2);
+
+	return fd;
+}
+
 /**
  * This function should share events between multiple ports of single IB
  * device.  Currently it has no support under Windows.
-- 
2.49.0.windows.1

RE: [PATCH v3 2/2] net/mlx5: improve debug dump file path handling

[Dariusz Sosnowski]

Hi,

> -----Original Message-----
> From: Yang Ming <mosesyyoung@gmail.com>
> Sent: Friday, August 29, 2025 4:50 PM
> To: dev@dpdk.org
> Subject: [PATCH v3 2/2] net/mlx5: improve debug dump file path handling
> 
> The current implementation always tries to open debug dump files under
> /var/log, which may not be writable in containerized or restricted
> environments (e.g. when the filesystem is mounted as read-only).
> 
> This patch introduces an OS-specific helper function
> mlx5_os_debug_dump_file_open() to unify the logic:
> 
> * On Linux:
>   1. Try /var/log if it is writable (kept for backward
>      compatibility).
>   2. Fallback to the DPDK runtime directory.
>   3. Finally, use the current working directory.
> 
> * On Windows:
>   1. Use the DPDK runtime directory.
>   2. Fallback to the current working directory.
> 
> This preserves the previous directory preference while ensuring debug dumps
> can still be written in restricted environments such as containers. The structure
> of the open logic is kept unchanged so that test cases and expected logs
> remain valid.
> 
> Signed-off-by: Yang Ming <mosesyyoung@gmail.com>

Acked-by: Dariusz Sosnowski <dsosnowski@nvidia.com>

Best regards,
Dariusz Sosnowski

Re: [PATCH v3 2/2] net/mlx5: improve debug dump file path handling

[Stephen Hemminger]

On Fri, 29 Aug 2025 22:49:53 +0800
Yang Ming <mosesyyoung@gmail.com> wrote:

> The current implementation always tries to open debug dump files
> under /var/log, which may not be writable in containerized or
> restricted environments (e.g. when the filesystem is mounted as
> read-only).
> 
> This patch introduces an OS-specific helper function
> mlx5_os_debug_dump_file_open() to unify the logic:
> 
> * On Linux:
>   1. Try /var/log if it is writable (kept for backward
>      compatibility).
>   2. Fallback to the DPDK runtime directory.
>   3. Finally, use the current working directory.
> 
> * On Windows:
>   1. Use the DPDK runtime directory.
>   2. Fallback to the current working directory.
> 
> This preserves the previous directory preference while ensuring
> debug dumps can still be written in restricted environments such
> as containers. The structure of the open logic is kept unchanged
> so that test cases and expected logs remain valid.
> 
> Signed-off-by: Yang Ming <mosesyyoung@gmail.com>

Mlx5 should follow current file system hierarchy standards.
Look at systemd documentation for information.
For example: /tmp should not be used for unix domain sockets
in a system service.

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

[Stephen Hemminger]

On Fri, 29 Aug 2025 22:49:52 +0800
Yang Ming <mosesyyoung@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@nvidia.com>
> 
> Signed-off-by: Yang Ming <mosesyyoung@gmail.com>
> ---

Rather driver specific logging, why is there not a way in EAL log
library to ope a diagnostic dump. 

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

[Moses Young]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]


On 8/30/2025 3:57 AM, Stephen Hemminger wrote:
> On Fri, 29 Aug 2025 22:49:52 +0800
> Yang Ming<mosesyyoung@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@nvidia.com>
>>
>> Signed-off-by: Yang Ming<mosesyyoung@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

[-- Attachment #2: Type: text/html, Size: 2381 bytes --]

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

[Stephen Hemminger]

On Sun, 31 Aug 2025 08:55:59 +0800
Moses Young <mosesyyoung@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@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@nvidia.com>
> >>
> >> Signed-off-by: Yang Ming<mosesyyoung@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.

Re: [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@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@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@nvidia.com>
>>>>
>>>> Signed-off-by: Yang Ming<mosesyyoung@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

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

[Raslan Darawsheh]

Hi,


On 29/08/2025 5:49 PM, Yang Ming 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@nvidia.com>
> 
> Signed-off-by: Yang Ming <mosesyyoung@gmail.com>

  Series applied to next-net-mlx,

Kindest regards
Raslan Darawsheh

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

[Stephen Hemminger]

On Fri, 29 Aug 2025 22:49:52 +0800
Yang Ming <mosesyyoung@gmail.com> wrote:

> -#define MLX5_SOCKET_PATH "/var/tmp/dpdk_net_mlx5_%d"
> +#define MLX5_SOCKET_DPATH "/var/tmp"
> +#define MLX5_SOCKET_FNAME "dpdk_net_mlx5"
>  #define MLX5_ALL_PORT_IDS 0xffff
>  
NAK - should follow current Linux defined policy for services.


    http://0pointer.net/blog/projects/tmp.html
    https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
    https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html*

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

[Dariusz Sosnowski]

On Mon, Nov 17, 2025 at 09:58:42AM -0800, Stephen Hemminger wrote:
> On Fri, 29 Aug 2025 22:49:52 +0800
> Yang Ming <mosesyyoung@gmail.com> wrote:
> 
> > -#define MLX5_SOCKET_PATH "/var/tmp/dpdk_net_mlx5_%d"
> > +#define MLX5_SOCKET_DPATH "/var/tmp"
> > +#define MLX5_SOCKET_FNAME "dpdk_net_mlx5"
> >  #define MLX5_ALL_PORT_IDS 0xffff
> >  
> NAK - should follow current Linux defined policy for services.
> 
> 
>     http://0pointer.net/blog/projects/tmp.html
>     https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
>     https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html*

We have discussed the series internally and we agree that the proper
solution would require dropping unix socket in /var/tmp and replacing it
with either DPDK runtime directory or another path in /var/run.
Since such a change would break external tooling,
we are unable to do that in time for 25.11.
Regarding the issue reported i.e., not being able to create unix socket in
/var/tmp when this directory is not writeable.
It is not critical, because it does not prevent probing.
Unix socket creation failure is logged and PMD moves on.
The series will be dropped from next-net-mlx tree and
we'll work on fixing that in next release cycle.

@Yang: We are sorry for the inconvenience caused by dropping
of this patch. Since the changes required are also depending
on tooling external to DPDK, we would like to propose that our DPDK team
will handle this fix in the next release cycle.
Of course, such a fix would include your attribution.
Thank you for raising this issue and sorry again for the inconvience.

Best regards,
Dariusz Sosnowski

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

[Moses Young]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

Hi Dariusz, Stephen, and the team,

Thank you for the detailed update and for taking the time to discuss the 
series internally.

I fully understand the concerns regarding backward compatibility and the 
impact on external tooling. If moving the UNIX socket path from /var/tmp 
to a proper runtime directory requires a broader change across dependent 
tools, postponing it to the next release cycle makes sense.

I'm glad to hear that the issue has been acknowledged and that the team 
plans to address it in a more complete way in the upcoming cycle. I 
appreciate the consideration regarding attribution as well.

Please let me know if there is anything I can help with during the 
redesign or review phase.
Thanks again for the clarification and for handling this thoughtfully.

Best regards,
Yang Ming

[-- Attachment #2: Type: text/html, Size: 1187 bytes --]

Re: [PATCH v2 1/2] net/mlx5: enhance socket file path

[Stephen Hemminger]

On Fri, 21 Mar 2025 21:27:49 +0800
Yang Ming <ming.1.yang@nokia-sbell.com> wrote:

> The directory /var/tmp may not be writable in a container's
> read-only mode. To address this issue, use the DPDK runtime
> directory as an alternative when /var/tmp is not writable.
> 
> Cc: bingz@nvidia.com
> Cc: dsosnowski@nvidia.com
> Cc: stephen@networkplumber.org
> Cc: julien.meunier@nokia.com
> 
> Signed-off-by: Yang Ming <ming.1.yang@nokia-sbell.com>
> ---
>  drivers/net/mlx5/linux/mlx5_socket.c | 23 ++++++++++++++++++-----
>  1 file changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/mlx5/linux/mlx5_socket.c b/drivers/net/mlx5/linux/mlx5_socket.c
> index 6ce0e59643..270a105f1d 100644
> --- a/drivers/net/mlx5/linux/mlx5_socket.c
> +++ b/drivers/net/mlx5/linux/mlx5_socket.c
> @@ -20,7 +20,8 @@
>  
>  /* PMD socket service for tools. */
>  
> -#define MLX5_SOCKET_PATH "/var/tmp/dpdk_net_mlx5_%d"
> +#define MLX5_SOCKET_DPATH "/var/tmp"
> +#define MLX5_SOCKET_FNAME "dpdk_net_mlx5"
>  #define MLX5_ALL_PORT_IDS 0xffff

Using /tmp or /var/tmp is non-standard on modern Linux distros.
Systemd based systems use /run for this.
Would be better to use abstract sockets, but that might break some containers.

Example:
$ ss -x | awk '{ print $5}' | grep -v '^@' | grep -v '*' | sort -u
/home/shemminger/.cache/ibus/dbus-d8xKr3Ya
Local
/run/dbus/system_bus_socket
/run/gdm3/dbus/dbus-6Kd7KbFO
/run/gdm3/dbus/dbus-RNBHo0m9
/run/systemd/io.systemd.ManagedOOM
/run/systemd/journal/dev-log
/run/systemd/journal/socket
/run/systemd/journal/stdout
/run/systemd/notify
/run/systemd/oom/io.systemd.ManagedOOM
/run/user/1000/at-spi/bus
/run/user/1000/bus
/run/user/1000/.dbus-proxy/a11y-bus-proxy-HBPCF3
/run/user/1000/.dbus-proxy/session-bus-proxy-1HPCF3
/run/user/1000/.dbus-proxy/system-bus-proxy-HIPCF3
/run/user/1000/emacs/server
/run/user/1000/.flatpak-helper/pkcs11-flatpak-16622
/run/user/1000/gvfsd/socket-r1TYSmLV
/run/user/1000/gvfsd/socket-Rk6Pe47X
/run/user/1000/pipewire-0
/run/user/1000/pipewire-0-manager
/run/user/1000/pulse/native
/run/user/1000/speech-dispatcher/speechd.sock
/run/user/1000/wayland-0
/run/user/1000/wayland-proxy-4315