From: Casey Leedom
> Sent: 04 August 2017 21:49
...
> Whenever our Hardware Designers implement new functionality in our hardware,
> they almost always put in A. several "knobs" which can control fundamental
> parameters of the new Hardware Feature, and B. a mechanism of completely
> disabling it
| From: Raj, Ashok
| Sent: Friday, August 4, 2017 1:21 PM
|
| On Fri, Aug 04, 2017 at 08:20:37PM +, Casey Leedom wrote:
| > ...
| > As I've noted a number of times, it would be great if the Intel Hardware
| > Engineers who attempted to implement the Relaxed Ordering semantics in the
| > curren
On Fri, Aug 04, 2017 at 08:20:37PM +, Casey Leedom wrote:
> | From: Raj, Ashok
> | Sent: Thursday, August 3, 2017 1:31 AM
> |
> | I don't understand this completely.. So your driver would know not to send
> | RO TLP's to root complex. But you want to send RO to the NVMe device? This
> | is the
| From: Raj, Ashok
| Sent: Thursday, August 3, 2017 1:31 AM
|
| I don't understand this completely.. So your driver would know not to send
| RO TLP's to root complex. But you want to send RO to the NVMe device? This
| is the peer-2-peer case correct?
Yes, this is the "heavy hammer" issue which yo
On 2017/8/3 17:13, Raj, Ashok wrote:
> Hi Ding
>
> patch looks good, except would reword the patch description for clarity
>
> here is my crack at it, feel free to use.
>
> On Thu, Jul 13, 2017 at 10:21:31PM +0800, Ding Tianhong wrote:
>> The PCIe Device Control Register use the bit 4 to indic
Hi Ding
patch looks good, except would reword the patch description for clarity
here is my crack at it, feel free to use.
On Thu, Jul 13, 2017 at 10:21:31PM +0800, Ding Tianhong wrote:
> The PCIe Device Control Register use the bit 4 to indicate that
> whether the device is permitted to enable r
Hi Casey
On Wed, Aug 02, 2017 at 05:53:52PM +, Casey Leedom wrote:
> Okay, here you go. As you can tell, it's almost a trivial copy of the
> cxgb4 patch.
>
> By the way, I realized that we have yet another hole which is likely not
> to be fixable. If we're dealing with a problematic Ro
Okay, here you go. As you can tell, it's almost a trivial copy of the
cxgb4 patch.
By the way, I realized that we have yet another hole which is likely not
to be fixable. If we're dealing with a problematic Root Complex, and we
instantiate Virtual Functions and attach them to a Virtual Mach
On 2017/7/28 1:49, Alexander Duyck wrote:
> On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong
> wrote:
>>
>>
>> On 2017/7/27 2:26, Casey Leedom wrote:
>>> By the way Ding, two issues:
>>>
>>> 1. Did we ever get any acknowledgement from either Intel or AMD
>>> on this patch? I know that we
On 2017/7/28 2:42, Raj, Ashok wrote:
> Hi Casey
>
>> | Still no Intel and AMD guys has ack this, this is what I am worried about,
>> | should I ping some man again ?
>
>
> I can ack the patch set for Intel specific changes. Now that the doc is made
> public :-).
>
Good, Thanks. :)
> Can you
On 2017/7/28 1:44, Casey Leedom wrote:
> | From: Ding Tianhong
> | Sent: Wednesday, July 26, 2017 6:01 PM
> |
> | On 2017/7/27 3:05, Casey Leedom wrote:
> | >
> | > Ding, send me a note if you'd like me to work that [cxgb4vf patch] up
> | > for you.
> |
> | Ok, you could send the change log and
Hi Casey
> | Still no Intel and AMD guys has ack this, this is what I am worried about,
> | should I ping some man again ?
I can ack the patch set for Intel specific changes. Now that the doc is made
public :-).
Can you/Ding resend the patch series, i do have the most recent v7, some
of the com
On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong wrote:
>
>
> On 2017/7/27 2:26, Casey Leedom wrote:
>> By the way Ding, two issues:
>>
>> 1. Did we ever get any acknowledgement from either Intel or AMD
>> on this patch? I know that we can't ensure that, but it sure would
>> be nice sinc
| From: Ding Tianhong
| Sent: Wednesday, July 26, 2017 6:01 PM
|
| On 2017/7/27 3:05, Casey Leedom wrote:
| >
| > Ding, send me a note if you'd like me to work that [cxgb4vf patch] up
| > for you.
|
| Ok, you could send the change log and I could put it in the v8 version
| together, will you base
On 2017/7/27 2:26, Casey Leedom wrote:
> By the way Ding, two issues:
>
> 1. Did we ever get any acknowledgement from either Intel or AMD
> on this patch? I know that we can't ensure that, but it sure would
> be nice since the PCI Quirks that we're putting in affect their
> produ
On 2017/7/27 3:05, Casey Leedom wrote:
> | From: Alexander Duyck
> | Sent: Wednesday, July 26, 2017 11:44 AM
> |
> | On Jul 26, 2017 11:26 AM, "Casey Leedom" wrote:
> | |
> | | I think that the patch will need to be extended to modify
> | | drivers/pci.c/iov.c:sriov_enable() to explici
| From: Alexander Duyck
| Sent: Wednesday, July 26, 2017 11:44 AM
|
| On Jul 26, 2017 11:26 AM, "Casey Leedom" wrote:
| |
| | I think that the patch will need to be extended to modify
| | drivers/pci.c/iov.c:sriov_enable() to explicitly turn off
| | Relaxed Ordering Enable if the Roo
By the way Ding, two issues:
1. Did we ever get any acknowledgement from either Intel or AMD
on this patch? I know that we can't ensure that, but it sure would
be nice since the PCI Quirks that we're putting in affect their
products.
2. I just realized that there's still a small
On Sat, 22 Jul 2017 12:19:38 +0800
Ding Tianhong wrote:
> Hi Sinan, Bjorn:
>
> On 2017/7/14 21:54, Sinan Kaya wrote:
> > On 7/13/2017 9:26 PM, Ding Tianhong wrote:
> >> There is no code to enable the PCIe Relaxed Ordering bit in the
> >> configuration space,
> >> it is only be enable by defau
Hi Sinan, Bjorn:
On 2017/7/14 21:54, Sinan Kaya wrote:
> On 7/13/2017 9:26 PM, Ding Tianhong wrote:
>> There is no code to enable the PCIe Relaxed Ordering bit in the
>> configuration space,
>> it is only be enable by default according to the PCIe Standard
>> Specification, what we
>> do is to d
On 7/13/2017 9:26 PM, Ding Tianhong wrote:
> There is no code to enable the PCIe Relaxed Ordering bit in the configuration
> space,
> it is only be enable by default according to the PCIe Standard Specification,
> what we
> do is to distinguish the RC problematic platform and clear the Relaxed
>
On 2017/7/14 5:09, Sinan Kaya wrote:
> On 7/13/2017 10:21 AM, Ding Tianhong wrote:
>> static void pci_configure_relaxed_ordering(struct pci_dev *dev)
>> +{
>> +/* We should not alter the relaxed ordering bit for the VF */
>> +if (dev->is_virtfn)
>> +return;
>> +
>> +/* If
On 7/13/2017 10:21 AM, Ding Tianhong wrote:
> static void pci_configure_relaxed_ordering(struct pci_dev *dev)
> +{
> + /* We should not alter the relaxed ordering bit for the VF */
> + if (dev->is_virtfn)
> + return;
> +
> + /* If the releaxed ordering enable bit is not set,
The PCIe Device Control Register use the bit 4 to indicate that
whether the device is permitted to enable relaxed ordering or not.
But relaxed ordering is not safe for some platform which could only
use strong write ordering, so devices are allowed (but not required)
to enable relaxed ordering bit
24 matches
Mail list logo
