[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG4TOxOrF9aLyujrwNmSsxPBWBPTaLx2yXkOJ88gxCj0QUGDow@mail.gmail.com>
Date: Thu, 20 Jul 2017 15:53:04 -0700
From: Roland Dreier <roland.dreier@...il.com>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Emil Tantilov <emil.s.tantilov@...el.com>
Subject: Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs
On Thu, Jul 20, 2017 at 3:15 PM, Alex Williamson
<alex.williamson@...hat.com> wrote:
> Most of the ACS capabilities are worded as "Must be implemented by
> devices that implement ..." Shouldn't a hard-wired ACS capability
> sufficiently describe that, or is there something wrong with how
> they're hard wired?
Interesting question. I just looked at what the PCI spec says about
the various bits for ACS functions in multi-function devices. Many of
the functions are "must not be implemented." Of the ones that are
"must be implemented if..." the key is that the if is for devices that
support peer-to-peer traffic.
I think the Intel NICs are compliant with the spec - they don't
support any ACS mechanisms for controlling peer-to-peer traffic, but
they also don't implement peer-to-peer traffic. This means that the
PCI standard way of knowing that it is safe to assign individual
functions does not prove it is safe - but with device-specific
knowledge we do know it is safe. Hence a quirk to give that
device-specific information to the kernel.
- R.
Powered by blists - more mailing lists