All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dongdong Liu <liudongdong3@huawei.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: <hch@infradead.org>, <kw@linux.com>, <logang@deltatee.com>,
	<leon@kernel.org>, <linux-pci@vger.kernel.org>,
	<rajur@chelsio.com>, <hverkuil-cisco@xs4all.nl>,
	<linux-media@vger.kernel.org>, <netdev@vger.kernel.org>
Subject: Re: [PATCH V7 9/9] PCI/P2PDMA: Add a 10-Bit Tag check in P2PDMA
Date: Tue, 10 Aug 2021 20:31:30 +0800	[thread overview]
Message-ID: <d113a3f3-6098-314b-32d3-b944daf1186c@huawei.com> (raw)
In-Reply-To: <20210809173113.GA2166744@bjorn-Precision-5520>



On 2021/8/10 1:31, Bjorn Helgaas wrote:
> On Sat, Aug 07, 2021 at 03:11:34PM +0800, Dongdong Liu wrote:
>>
>> On 2021/8/6 2:12, Bjorn Helgaas wrote:
>>> On Wed, Aug 04, 2021 at 09:47:08PM +0800, Dongdong Liu wrote:
>>>> Add a 10-Bit Tag check in the P2PDMA code to ensure that a device with
>>>> 10-Bit Tag Requester doesn't interact with a device that does not
>>>> support 10-BIT Tag Completer. Before that happens, the kernel should
>>>> emit a warning. "echo 0 > /sys/bus/pci/devices/.../10bit_tag" to
>>>> disable 10-BIT Tag Requester for PF device.
>>>> "echo 0 > /sys/bus/pci/devices/.../sriov_vf_10bit_tag_ctl" to disable
>>>> 10-BIT Tag Requester for VF device.
>>>
>>> s/10-BIT/10-Bit/ several times.
>> Will fix.
>>>
>>> Add blank lines between paragraphs.
>> Will fix.
>>>
>>>> Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
>>>> ---
>>>>  drivers/pci/p2pdma.c | 40 ++++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 40 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
>>>> index 50cdde3..948f2be 100644
>>>> --- a/drivers/pci/p2pdma.c
>>>> +++ b/drivers/pci/p2pdma.c
>>>> @@ -19,6 +19,7 @@
>>>>  #include <linux/random.h>
>>>>  #include <linux/seq_buf.h>
>>>>  #include <linux/xarray.h>
>>>> +#include "pci.h"
>>>>
>>>>  enum pci_p2pdma_map_type {
>>>>  	PCI_P2PDMA_MAP_UNKNOWN = 0,
>>>> @@ -410,6 +411,41 @@ static unsigned long map_types_idx(struct pci_dev *client)
>>>>  		(client->bus->number << 8) | client->devfn;
>>>>  }
>>>>
>>>> +static bool check_10bit_tags_vaild(struct pci_dev *a, struct pci_dev *b,
>>>
>>> s/vaild/valid/
>>>
>>> Or maybe s/valid/safe/ or s/valid/supported/, since "valid" isn't
>>> quite the right word here.  We want to know whether the source is
>>> enabled to generate 10-bit tags, and if so, whether the destination
>>> can handle them.
>>>
>>> "if (check_10bit_tags_valid())" does not make sense because
>>> "check_10bit_tags_valid()" is not a question with a yes/no answer.
>>>
>>> "10bit_tags_valid()" *might* be, because "if (10bit_tags_valid())"
>>> makes sense.  But I don't think you can start with a digit.
>>>
>>> Or maybe you want to invert the sense, e.g.,
>>> "10bit_tags_unsupported()", since that avoids negation at the caller:
>>>
>>>   if (10bit_tags_unsupported(a, b) ||
>>>       10bit_tags_unsupported(b, a))
>>>         map_type = PCI_P2PDMA_MAP_NOT_SUPPORTED;
>> Good suggestion. add a pci_ prefix.
>>
>> if (pci_10bit_tags_unsupported(a, b) ||
>>     pci_10bit_tags_unsupported(b, a))
>> 	map_type = PCI_P2PDMA_MAP_NOT_SUPPORTED;
>
> This treats both directions as equally important.  I don't know P2PDMA
> very well, but that doesn't seem like it would necessarily be the
> case.  I would think a common case would be device A doing DMA to B,
> but B *not* doing DMA to A.  So can you tell which direction you're
> setting up here, and can you take advantage of any asymmetry, e.g., by
> enabling 10-bit tags in the direction that supports it even if the
> other direction does not?

Documentation/driver-api/pci/p2pdma.rst
* Provider - A driver which provides or publishes P2P resources like
   memory or doorbell registers to other drivers.
* Client - A driver which makes use of a resource by setting up a
   DMA transaction to or from it.

So we may just check as below.
if (10bit_tags_unsupported(client, provider, verbose)
	map_type = PCI_P2PDMA_MAP_NOT_SUPPORTED;

@Logan What's your opinion?

Thanks,
Dongdong
> .
>

      reply	other threads:[~2021-08-10 12:31 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-04 13:46 [PATCH V7 0/9] PCI: Enable 10-Bit tag support for PCIe devices Dongdong Liu
2021-08-04 13:47 ` [PATCH V7 1/9] PCI: Use cached Device Capabilities Register Dongdong Liu
2021-08-04 13:47 ` [PATCH V7 2/9] PCI: Use cached Device Capabilities 2 Register Dongdong Liu
2021-08-04 13:47 ` [PATCH V7 3/9] PCI: Add 10-Bit Tag register definitions Dongdong Liu
2021-08-04 13:47 ` [PATCH V7 4/9] PCI: Enable 10-Bit Tag support for PCIe Endpoint devices Dongdong Liu
2021-08-04 23:17   ` Bjorn Helgaas
2021-08-05  7:47     ` Dongdong Liu
2021-08-05 19:54       ` Bjorn Helgaas
2021-08-07  6:19         ` Dongdong Liu
2021-08-04 13:47 ` [PATCH V7 5/9] PCI/IOV: Enable 10-Bit tag support for PCIe VF devices Dongdong Liu
2021-08-04 23:29   ` Bjorn Helgaas
2021-08-05  8:03     ` Dongdong Liu
2021-08-06 22:59       ` Bjorn Helgaas
2021-08-07  7:46         ` Dongdong Liu
2021-08-04 13:47 ` [PATCH V7 6/9] PCI: Enable 10-Bit Tag support for PCIe RP devices Dongdong Liu
2021-08-04 23:38   ` Bjorn Helgaas
2021-08-05  8:25     ` Dongdong Liu
2021-08-09 17:26       ` Bjorn Helgaas
2021-08-10 11:59         ` Dongdong Liu
2021-08-04 13:47 ` [PATCH V7 7/9] PCI/sysfs: Add a 10-Bit Tag sysfs file Dongdong Liu
2021-08-04 15:51   ` Logan Gunthorpe
2021-08-05 13:14     ` Dongdong Liu
2021-08-05 13:53       ` Leon Romanovsky
2021-08-05 15:36       ` Logan Gunthorpe
2021-08-04 23:49   ` Bjorn Helgaas
2021-08-05  8:37     ` Dongdong Liu
2021-08-05 15:31       ` Bjorn Helgaas
2021-08-07  7:01         ` Dongdong Liu
2021-08-09 17:37           ` Bjorn Helgaas
2021-08-10 12:16             ` Dongdong Liu
2021-08-04 23:52   ` Bjorn Helgaas
2021-08-05  8:38     ` Dongdong Liu
2021-08-04 13:47 ` [PATCH V7 8/9] PCI/IOV: Add 10-Bit Tag sysfs files for VF devices Dongdong Liu
2021-08-05  0:05   ` Bjorn Helgaas
2021-08-05  8:47     ` Dongdong Liu
2021-08-05  9:39     ` Dongdong Liu
2021-08-04 13:47 ` [PATCH V7 9/9] PCI/P2PDMA: Add a 10-Bit Tag check in P2PDMA Dongdong Liu
2021-08-04 15:56   ` Logan Gunthorpe
2021-08-05  8:49     ` Dongdong Liu
2021-08-05 18:12   ` Bjorn Helgaas
2021-08-07  7:11     ` Dongdong Liu
2021-08-09 17:31       ` Bjorn Helgaas
2021-08-10 12:31         ` Dongdong Liu [this message]

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=d113a3f3-6098-314b-32d3-b944daf1186c@huawei.com \
    --to=liudongdong3@huawei.com \
    --cc=hch@infradead.org \
    --cc=helgaas@kernel.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=kw@linux.com \
    --cc=leon@kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=logang@deltatee.com \
    --cc=netdev@vger.kernel.org \
    --cc=rajur@chelsio.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.