Re: [PATCH 1/2] PCI/DPC: Add 'nodpc' parameter

[Derrick, Jonathan]

Hi Bjorn,

On Thu, 2018-08-16 at 15:31 -0500, Bjorn Helgaas wrote:
> On Thu, Aug 16, 2018 at 03:50:47PM +0000, Derrick, Jonathan wrote:
> > On Thu, 2018-08-16 at 08:49 -0700, Matthew Wilcox wrote:
> > > On Wed, Aug 15, 2018 at 03:26:39PM -0600, Jon Derrick wrote:
> > > > Some users may want to disable downstream port containment
> > > > (DPC),
> > > > so
> > > > give them this option
> > > 
> > > Is it possible they might only want to disable DPC on a subset of
> > > the
> > > hierarchy rather than globally?
> > 
> > Absolutely. I was hoping Logan's pci dev_str would land because I
> > have
> > a few others I want to convert to that api for granular tuning
> 
> What's the use case here?  I acknowledge there are cases where we
> need
> them, but I'm not a fan of kernel parameters in general because
> they're a real hassle for users.
> 
> Is there something wrong with DPC?  Is there some way we can make it
> smarter so it does the right thing automatically?
I've encountered some BIOS or switches (not sure who) who've appeared
to have enabled DPC by default, prior to kernel setup. Some users may
just not want this, but it was primarily intended for debugging when I
conceived it.

There's also the ongoing thread in linux-pci about err handling in PPC
EEH, who may also desire to disable DPC until those issues are
resolved.


It can also be disabled with setpci, but is that any less of a hassle?
Genuine question to understand your point of view.


> 
> I'm more OK with a blanket "nodpc" switch intended for debugging.
> If we add the complexity of subsets of the hierarchy it starts
> sounding like an administrative thing that makes me more hesitant. 
> 
That's ok with me. I was having trouble cleanly keeping the string
around after early_param anyways.


To again understand your point of view, is there anything wrong with
administrative things in kernel boot parameters? There will be cases
where we may want to deviate from default or global pci=* parameters
for certain hierarchies and they can't necessarily be set after the
fact (ex, hpmemsize).


> Could this be done via a sysfs switch instead?  That potentially
> could
> work for hot-added things where a kernel parameter doesn't work so
> well.
> 
> Please squash the doc patch and the code change so it's easier to
> keep
> them together.
> 
> Bjorn

Attachment: smime.p7s
Description: S/MIME cryptographic signature