[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BL2PR07MB23060C776EDAE92B84FCFB768DF00@BL2PR07MB2306.namprd07.prod.outlook.com>
Date: Thu, 15 Sep 2016 05:11:03 +0000
From: "Mintz, Yuval" <Yuval.Mintz@...ium.com>
To: Leon Romanovsky <leon@...nel.org>,
"dledford@...hat.com" <dledford@...hat.com>
CC: Mark Bloch <markb@...lanox.com>,
Ram Amrani <Ram.Amrani@...gic.com>,
"David Miller" <davem@...emloft.net>,
Ariel Elior <Ariel.Elior@...gic.com>,
"Michal Kalderon" <Michal.Kalderon@...gic.com>,
Rajesh Borundia <rajesh.borundia@...gic.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
netdev <netdev@...r.kernel.org>
Subject: RE: [RFC 02/11] Add RoCE driver framework
> > > If you want dynamic prints, you have two options:
> > > 1. Add support of ethtool to whole RDMA stack.
> > > 2. Use dynamic tracing infrastructure.
> >
> > > Which option do you prefer?
> > Option 3 - continuing this discussion. :-)
>
> Sorry,
> I was under impression that you want this driver to be merged, but it looks like It
> was incorrect assumption. Let's continue discussion.
No, this is an RFC - there's no chance for *this* to merge, but this is exactly
the right time to discuss this sort of stuff.
> > Perhaps I misread your intentions - I thought that by dynamic debug
> > you meant that all debug in RDMA should be pr_debug() based, and
> > therefore my objection regarding the ease with which users can
> > configure it.
>
> It is not for all RDMA, but in your proposed driver. You are adding this "debug"
> module argument to your module.
I don't get your answer.
I made a generic remark [and actually one in favor of your arguments],
and instead of saying something meaningful you bash the driver.
> > If all you meant was 'dynamically set' as opposed to 'statically set'
> > then I agree that having that sort of configurability is preferable
> > [Even though end-user would still probably prefer a module parameter
> > for reproductions; As the name implies, 'debug' isn't meant to be used
> > in other situations].
>
> We are not adding code just for fun, but for a real reason, and especially
> interfaces which will be visible to user.
>
> The overall expectation from the driver's authors that they are submitting driver
> which doesn't have bringup issues. For real life scenarios, where the bugs will be
> reveled after some time of usage, this global debug is useless.
This has nothing to do with bringup; Real drivers are experiencing issues years after
they're productized.
> > Do notice you would be harming user-experience of reproductions though
> > - as it would have to follow different mechanisms to open debug prints
> > of various qed* components.
>
> I don't understand this point at all. Do you think that it is normal to ask user to
> debug your driver? Is this called "user-experience"?
No, I call this 'user involved in fixing the driver' - it has nothing to do with
user-experience. Sometimes user have specifics in his system that can't
be easily identified and thus lab reproductions fail, and the user assists
in the reproduction. While I never claimed this is good practice it does happen.
> As a summary, I didn't see in your responses any real life example where you will
> need global debug level for your driver.
Not sure what you you're expecting - a list of BZs /private e-mails where
user reproductions were needed?
You're basically ignoring my claims that such are used, instead wanting
"evidence". I'm not going to try and produce any such.
Doug - I think we need a definite answer from you here; Doesn't look like
this discussion would bear any fruit.
If a debug module parameter is completely unacceptable, we'd remove it
[regardless of what I think about it].
Powered by blists - more mailing lists