From: Niklas Cassel <cassel@kernel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: bhelgaas@google.com, kw@linux.com, linux-pci@vger.kernel.org,
Damien Le Moal <dlemoal@kernel.org>,
Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Subject: Re: [PATCH 3/4] misc: pci_endpoint_test: Let PCITEST_{READ,WRITE,COPY} set IRQ type automatically
Date: Fri, 21 Mar 2025 14:27:34 +0100 [thread overview]
Message-ID: <Z91pRhf50ErRt5jD@x1-carbon> (raw)
In-Reply-To: <20250320152732.l346sbaioubb5qut@thinkpad>
Hello Mani,
On Thu, Mar 20, 2025 at 08:57:32PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Mar 18, 2025 at 11:33:34AM +0100, Niklas Cassel wrote:
> > The test cases for read/write/copy currently do:
> > 1) ioctl(PCITEST_SET_IRQTYPE, MSI)
> > 2) ioctl(PCITEST_{READ,WRITE,COPY})
> >
> > This design is quite bad for a few reasons:
> > -It assumes that all PCI EPCs support MSI.
> > -One ioctl should be sufficient for these test cases.
> >
> > Modify the PCITEST_{READ,WRITE,COPY} ioctls to set IRQ type automatically,
> > overwriting the currently configured IRQ type. It there are no IRQ types
> > supported in the CAPS register, fall back to MSI IRQs. This way the
> > implementation is no worse than before this commit.
> >
> > Any test case that requires a specific IRQ type, e.g. MSIX_TEST, will do
> > an explicit PCITEST_SET_IRQTYPE ioctl at the start of the test case, thus
> > it is safe to always overwrite the configured IRQ type.
> >
>
> I don't quite understand this sentence.
What I was trying to say is that it is okay if PCITEST_{READ,WRITE,COPY}
ioctls always overwrite the configured IRQ type, because all test cases
in tools/testing/selftests/pci_endpoint/pci_endpoint_test.c that require
a specific IRQ type, e.g.:
- TEST_F(pci_ep_basic, LEGACY_IRQ_TEST)
will call pci_ep_ioctl(PCITEST_SET_IRQTYPE, PCITEST_IRQ_TYPE_INTX);
before calling pci_ep_ioctl(PCITEST_LEGACY_IRQ, 0);
- TEST_F(pci_ep_basic, MSI_TEST)
will call pci_ep_ioctl(PCITEST_SET_IRQTYPE, PCITEST_IRQ_TYPE_MSI);
before calling pci_ep_ioctl(PCITEST_MSI, i);
- TEST_F(pci_ep_basic, MSIX_TEST)
will call pci_ep_ioctl(PCITEST_SET_IRQTYPE, PCITEST_IRQ_TYPE_MSIX);
before calling pci_ep_ioctl(PCITEST_MSIX, i);
Thus, all test cases will still work, even if PCITEST_{READ,WRITE,COPY}
overwrites the configured IRQ type.
> What if users wants to use a specific
> IRQ type like MSI-X if the platform supports both MSI/MSI-X? That's why I wanted
> to honor 'test->irq_type' if already set before READ,WRITE,COPY testcases.
As I said, I don't think you can have the cake and eat it too ;)
Let me explain:
If you simply run pcitest, it will execute the test cases in the following
order:
1) pci_ep_bar.BARx.BAR_TEST
2) pci_ep_basic.CONSECUTIVE_BAR_TEST
3) pci_ep_basic.LEGACY_IRQ_TEST
4) pci_ep_basic.MSI_TEST
5) pci_ep_basic.MSIX_TEST
6) pci_ep_data_transfer.memcpy.READ_TEST
7) pci_ep_data_transfer.memcpy.WRITE_TEST
8) pci_ep_data_transfer.memcpy.COPY_TEST
Thus, when you reach 6) (READ_TEST), irq_type will already be set, and
READ_TEST will use whatever IRQ type that happened to be the last one that was
executed successfully. That unpredictability doesn't sound like very good
design to me.
To me, it sounds like what you want is actually what is already queued up on
pci/next.
Because with that, READ_TEST / WRITE_TEST / COPY_TEST test cases will always
call pci_ep_ioctl(PCITEST_SET_IRQTYPE, PCITEST_IRQ_TYPE_AUTO);
(If you want the behavior that the READ_TEST / WRITE_TEST / COPY_TEST case
should automatically figure out which IRQ type to use.)
If you want to use a specific IRQ type for READ_TEST / WRITE_TEST / COPY_TEST,
it should be trivial to write a new test case variant (or new test case), that
does SET_IRQ(WHICH_EVER_IRQ_TYPE_YOU_WANT); (depending on the test case variant)
followed by the ioctl() for the test itself.
This determinism is not possible if you move the "automatic IRQ selection"
logic to be within the PCITEST_{READ,WRITE,COPY} ioctls. (As this series does.)
I'm travelling to a conference this weekend, and will be busy all next week.
I've sent two proposals, what is currently queued up on pci/next, and this
series.
As you might guess, I think that IRQ_TYPE_AUTO is the most elegant solution
with regard to the existing design.
But, if you want to make changes before the merge window opens, feel free to:
-Take over this series; or
-Write your own series on top of what is on pci/next; or
-Keep pci/next as it is.
I'm really (honestly) happy with whatever solution, as long as we, once again,
handle EPCs that only support INTx, or only support MSI-X.
(Because ever since your patch series that migrated pcitest to selftests,
READ_TEST / WRITE_TEST / COPY_TEST test cases unconditionally use MSI, which
is a regression for EPCs that only support INTx, or only support MSI-X,
which is the whole reason why I wrote this series.)
Kind regards,
Niklas
next prev parent reply other threads:[~2025-03-21 13:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 10:33 [PATCH 0/4] pci_endpoint_test: Let PCITEST_{READ,WRITE,COPY} set IRQ type automatically Niklas Cassel
2025-03-18 10:33 ` [PATCH 1/4] Revert "misc: pci_endpoint_test: Add support for PCITEST_IRQ_TYPE_AUTO" Niklas Cassel
2025-03-18 10:33 ` [PATCH 2/4] misc: pci_endpoint_test: Fetch supported IRQ types in CAPS register Niklas Cassel
2025-03-18 10:33 ` [PATCH 3/4] misc: pci_endpoint_test: Let PCITEST_{READ,WRITE,COPY} set IRQ type automatically Niklas Cassel
2025-03-20 15:27 ` Manivannan Sadhasivam
2025-03-21 13:27 ` Niklas Cassel [this message]
2025-03-22 2:24 ` Manivannan Sadhasivam
2025-03-22 5:31 ` Niklas Cassel
2025-03-23 11:34 ` Krzysztof Wilczyński
2025-03-24 18:20 ` Niklas Cassel
2025-03-24 18:36 ` Damien Le Moal
2025-03-26 6:23 ` Krzysztof Wilczyński
2025-03-26 14:39 ` Niklas Cassel
2025-03-26 16:17 ` Manivannan Sadhasivam
2025-03-26 19:22 ` Niklas Cassel
2025-03-26 19:58 ` Bjorn Helgaas
2025-04-02 7:24 ` Manivannan Sadhasivam
2025-03-18 10:33 ` [PATCH 4/4] selftests: pci_endpoint: Remove PCITEST_SET_IRQTYPE ioctls for read/write/copy Niklas Cassel
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=Z91pRhf50ErRt5jD@x1-carbon \
--to=cassel@kernel.org \
--cc=bhelgaas@google.com \
--cc=dlemoal@kernel.org \
--cc=hayashi.kunihiko@socionext.com \
--cc=kw@linux.com \
--cc=linux-pci@vger.kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
/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