DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>, <dev@dpdk.org>,
	Igor Romanov <Igor.Romanov@oktetlabs.ru>
Subject: Re: [dpdk-dev] [PATCH 5/5] sfc: don't use RTE_LOGTYPE_PMD
Date: Wed, 27 Feb 2019 10:30:43 -0800	[thread overview]
Message-ID: <20190227103043.3b62103b@shemminger-XPS-13-9360> (raw)
In-Reply-To: <ac7e9962-9d71-2b27-baa2-0a97f0d7df3f@solarflare.com>

On Wed, 27 Feb 2019 14:24:21 +0300
Andrew Rybchenko <arybchenko@solarflare.com> wrote:

> On 2/27/19 2:21 PM, Ferruh Yigit wrote:
> > On 2/26/2019 9:34 PM, Stephen Hemminger wrote:  
> >> The sfc driver was still using RTE_LOGTYPE_PMD which was superseded
> >> by local logging.
> >>
> >> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> >> ---
> >>   drivers/net/sfc/sfc.c | 4 ++--
> >>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/sfc/sfc.c b/drivers/net/sfc/sfc.c
> >> index 898603884fa0..2cd7126015fd 100644
> >> --- a/drivers/net/sfc/sfc.c
> >> +++ b/drivers/net/sfc/sfc.c
> >> @@ -1115,12 +1115,12 @@ sfc_register_logtype(const struct rte_pci_addr *pci_addr,
> >>   		++lt_prefix_str_size; /* Reserve space for prefix separator */
> >>   		lt_str_size_max = lt_prefix_str_size + PCI_PRI_STR_SIZE + 1;
> >>   	} else {
> >> -		return RTE_LOGTYPE_PMD;
> >> +		return sfc_logtype_driver;
> >>   	}
> >>   
> >>   	lt_str = rte_zmalloc("logtype_str", lt_str_size_max, 0);
> >>   	if (lt_str == NULL)
> >> -		return RTE_LOGTYPE_PMD;
> >> +		return sfc_logtype_driver;
> >>   
> >>   	strncpy(lt_str, lt_prefix_str, lt_prefix_str_size);
> >>   	lt_str[lt_prefix_str_size - 1] = '.';
> >>  
> > Overall I think it is good idea to remove RTE_LOGTYPE_PMD, but sfc has a few
> > more usage of it around same manner, as a fallback value if allocating dynamic
> > one fails.
> >
> >
> > Andrew,
> >
> > Can be possible to update this sfc patch to completely eliminate RTE_LOGTYPE_PMD
> > usage? What do you think?
> >
> > Thanks,
> > ferruh  
> 
> I'm OK to use  sfc_logtype_driverif dynamic log type register fails, but
> what should I do if sfc_logtype_driverregister fails?
> 
> Andrew.

I don't like drivers that try to do something different than every other driver in DPDK.
The solarflare driver is doing lots of extra effort to have multiple fine grain log types.
Not sure if there is any value to this. In a real world situation for diagnosis you would
want to turn on logs across everything in the driver, then filter as needed later.

  parent reply	other threads:[~2019-02-27 18:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26 21:34 [dpdk-dev] [PATCH 0/5] no longer " Stephen Hemminger
2019-02-26 21:34 ` [dpdk-dev] [PATCH 1/5] eal: drop unused RTE_PROC_PRIMARY_OR macros Stephen Hemminger
2019-02-28  6:05   ` Rami Rosen
2019-02-26 21:34 ` [dpdk-dev] [PATCH 2/5] crypto/virtio: use local log type Stephen Hemminger
2019-02-26 21:34 ` [dpdk-dev] [PATCH 3/5] eventdev: use same log macro for all unsupported calls Stephen Hemminger
2019-02-26 21:34 ` [dpdk-dev] [PATCH 4/5] eal: remove RTE_PMD_DEBUG_TRACE Stephen Hemminger
2019-02-26 21:34 ` [dpdk-dev] [PATCH 5/5] sfc: don't use RTE_LOGTYPE_PMD Stephen Hemminger
2019-02-27 11:21   ` Ferruh Yigit
2019-02-27 11:24     ` Andrew Rybchenko
2019-02-27 11:50       ` Ferruh Yigit
2019-02-27 12:19         ` Ferruh Yigit
2019-02-27 13:05           ` Andrew Rybchenko
2019-02-27 18:30       ` Stephen Hemminger [this message]
2019-02-28  6:49         ` Andrew Rybchenko
2019-02-27 16:08   ` [dpdk-dev] [PATCH v2] net/sfc: do not use PMD logtype Ferruh Yigit
2019-02-28 15:12     ` Andrew Rybchenko
2019-02-28 17:46 ` [dpdk-dev] [PATCH 0/5] no longer use RTE_LOGTYPE_PMD Ferruh Yigit
2019-02-28 17:55   ` Ferruh Yigit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190227103043.3b62103b@shemminger-XPS-13-9360 \
    --to=stephen@networkplumber.org \
    --cc=Igor.Romanov@oktetlabs.ru \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).