From: Sinan Kaya <okaya@codeaurora.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org, timur@codeaurora.org,
cov@codeaurora.org, vikrams@codeaurora.org,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI: enable extended tags support for PCIe endpoints
Date: Fri, 11 Nov 2016 20:11:19 -0500 [thread overview]
Message-ID: <99d136d7-6bce-5faf-c4a9-ba55808c167d@codeaurora.org> (raw)
In-Reply-To: <20161111205801.GC9868@bhelgaas-glaptop.roam.corp.google.com>
On 11/11/2016 3:58 PM, Bjorn Helgaas wrote:
>> I should have checked the capability here before trying to enable it.
>> > I'll post a follow up patch on this.
>> >
>> > Is there any other feedback?
> If this were completely safe to enable for every device that supported
> it, why would there be an enable bit in Device Control?
reading from the ECN here.
https://pcisig.com/sites/default/files/specification_documents/ECN_Extended_Tag_Enable_Default_05Sept2008_final.pdf
The initial value is implementation specific and functions are allowed
to set it to 1 by default.
>
> I don't know anything about extended tags, but it worries me a little
> when there's a "go-fast" switch and no explanation about when and why
> we might need to go slo
Based on my observation, extended tags increase the number of reads that
can be queued up back to back downstream. Otherwise, the requests will not
make progress until 1 tag out of 32 gets available.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2016-11-12 1:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-25 2:10 [PATCH] PCI: enable extended tags support for PCIe endpoints Sinan Kaya
2016-11-10 18:35 ` Sinan Kaya
2016-11-11 20:58 ` Bjorn Helgaas
2016-11-12 1:11 ` Sinan Kaya [this message]
2017-01-25 17:49 ` Sinan Kaya
2017-01-25 18:33 ` Sinan Kaya
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=99d136d7-6bce-5faf-c4a9-ba55808c167d@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=cov@codeaurora.org \
--cc=helgaas@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=timur@codeaurora.org \
--cc=vikrams@codeaurora.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