On Sun, 3 Aug 2025 12:51:59 +0200
Morten Brørup <m...@smartsharesystems.com> wrote:

> > From: Ivan Malov [mailto:ivan.ma...@arknetworks.am]
> > Sent: Saturday, 2 August 2025 23.34
> > 
> > Hi,
> > 
> > On Sat, 2 Aug 2025, Stephen Hemminger wrote:
> >   
> > > On Thu, 31 Jul 2025 09:07:31 +0000
> > > Morten Brørup <m...@smartsharesystems.com> wrote:
> > >  
> > >> +                RTE_ETHDEV_LOG_LINE(DEBUG,
> > >> +                        "Ethdev port_id=%d tx_queue_id=%d, Tx offload 
> > >> %s  
> > potential conflict with per-port Tx offload %s, "  
> > >> +                        "runtime support depends on the driver",  
> > >
> > > Shorten the message, and get it on one line.
> > > When a message is so long it won't fit on one line, it is too verbose.  
> > 
> > I am not an expert in naming, but on the premise that 'ethdev' is
> > already
> > printed by 'RTE_ETHDEV_LOG_LINE', perhaps consider this variant:
> > 
> > "id=%d txq=%d offload clash %s vs dev %s: PMD to decide"
> > 
> > Thank you.  
> 
> Ivan's suggestion is good, but this file has plenty of long (and even 
> multi-line) log messages, e.g. [1]:
> 
>       if ((local_conf.offloads & dev_info.tx_queue_offload_capa) !=
>            local_conf.offloads) {
>               RTE_ETHDEV_LOG_LINE(ERR,
>                       "Ethdev port_id=%d tx_queue_id=%d, new added offloads 
> 0x%"PRIx64" must be "
>                       "within per-queue offload capabilities 0x%"PRIx64" in 
> %s()",
>                       port_id, tx_queue_id, local_conf.offloads,
>                       dev_info.tx_queue_offload_capa,
>                       __func__);
>               return -EINVAL;
>       }
> 
> [1]: 
> https://elixir.bootlin.com/dpdk/v25.07/source/lib/ethdev/rte_ethdev.c#L2703
> 
> Which do you prefer:
> a) Follow the local coding style for log messages, or
> b) Follow our general coding style, and log as Ivan suggested?
> 
> 

I have distaste from long error messages after seeing what VMS and Windows NT 
did.
The purpose of error message is to say "something is wrong" not to describe to 
the
user in detail how to fix it.

Keep longer description for documentation or comments.
The real problem is missing description in documentation and longer messages
don't help.

Reply via email to