From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Shivasharan Srikanteshwara <shivasharan.srikanteshwara@broadcom.com>
Cc: Sumanesh Samanta <sumanesh.samanta@broadcom.com>,
<linux-pci@vger.kernel.org>, <bhelgaas@google.com>,
<manivannan.sadhasivam@linaro.org>, <logang@deltatee.com>,
<linux-kernel@vger.kernel.org>, <sathya.prakash@broadcom.com>,
<sjeaugey@nvidia.com>
Subject: Re: [PATCH 1/2 v2] PCI/portdrv: Enable reporting inter-switch P2P links
Date: Wed, 16 Oct 2024 14:25:25 +0100 [thread overview]
Message-ID: <20241016142525.000013ca@Huawei.com> (raw)
In-Reply-To: <CAOHJnDv9XK3Pno4pk9bDA1SApnJ-oYmA83EndttpiFh4=i2mMw@mail.gmail.com>
On Mon, 14 Oct 2024 15:10:57 +0530
Shivasharan Srikanteshwara <shivasharan.srikanteshwara@broadcom.com> wrote:
> On Fri, Oct 4, 2024 at 4:09 PM Jonathan Cameron <Jonathan.Cameron@huawei.com>
> wrote:
> >
> > On Thu, 3 Oct 2024 14:41:07 -0600
> > Sumanesh Samanta <sumanesh.samanta@broadcom.com> wrote:
> >
> > > Hi Jonathan,
> > >
> > > >> Need more data that 'there is a link' for this.
> > > >>I'd like to see some info on bandwidth and latency.
> > >
> > > As you too noted in your comments, for now, we are only addressing p2p
> > > connection between "virtual switches", i.e. switches that look
> > > different to the host, but are actually part of the same physical
> > > hardware.
> > > Given that, I am not sure what we should display for bandwidth and
> > > latency. There is no physical link to traverse between the virtual
> > > switches, and usually we take that as "infinite" bandwidth and "zero"
> > > latency.
> >
> > For a case where you have no information, not having attributes is
> > sensible. If there is information (CXL CDAT provides this for switches
> > for instance) then we should have an interface that provides space for
> > that information.
> >
> > > As such, any number here will make little sense until we
> > > start supporting p2p connection between physical switches.
> >
> > As above, it makes sense in a switch as well - if the information
> > is available.
> >
> > > We could,
> > > of course, have some encoding for the time being, like have "INF" for
> > > bandwidth and 0 for latency, but again, those will not be very useful
> > > till the day this scheme is extended to physical switch and we display
> > > real values, like bandwidth and latency for a x16 PCIe link. Thoughts?
> >
> > Hide the sysfs attributes for latency and bandwidth if we simply don't
> > know. Software built on top of this can then assume full bandwidth
> > is available or better still run some measurements to establish the
> > missing data.
> >
> > All I really meant by this suggestion is a directory with space for
> > other info is probably more extensible than a single file.
>
> Hi Jonathan,
> We will make the changes to add a directory for p2p_link related information
> to be exposed to user. We will only populate the information related to the
> inter-switch P2P links. Rest of the attributes can be added for devices that
> report them at a later stage.
> Please check if the directory structure makes sense to you:
> /sys/devices/.../B:D:F/p2p_link/links -> Reading this file will return the
> same
> information that is returned currently by the p2p_link file.
Sounds good to me.
Jonathan
next prev parent reply other threads:[~2024-10-16 13:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-19 8:13 [PATCH 0/2 v2] PCI/portdrv: Report inter switch P2P links through sysfs Shivasharan S
2024-09-19 8:13 ` [PATCH 1/2 v2] PCI/portdrv: Enable reporting inter-switch P2P links Shivasharan S
2024-09-20 4:28 ` kernel test robot
2024-09-24 14:57 ` Jonathan Cameron
2024-10-03 20:41 ` Sumanesh Samanta
2024-10-04 10:39 ` Jonathan Cameron
2024-10-14 9:40 ` Shivasharan Srikanteshwara
2024-10-16 13:25 ` Jonathan Cameron [this message]
2024-09-19 8:13 ` [PATCH 2/2 v2] PCI/P2PDMA: Modify p2p_dma_distance to detect " Shivasharan S
2024-09-20 5:51 ` kernel test robot
2024-09-24 15:08 ` Jonathan Cameron
2024-10-14 9:44 ` Shivasharan Srikanteshwara
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=20241016142525.000013ca@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=manivannan.sadhasivam@linaro.org \
--cc=sathya.prakash@broadcom.com \
--cc=shivasharan.srikanteshwara@broadcom.com \
--cc=sjeaugey@nvidia.com \
--cc=sumanesh.samanta@broadcom.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).