* [PATCH v7 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-13 14:21 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-13 14:21 UTC (permalink / raw) To: leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm Cc: Ding Tianhong Some devices have problems with Transaction Layer Packets with the Relaxed Ordering Attribute set. This patch set adds a new PCIe Device Flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known devices with Relaxed Ordering issues, and a use of this new flag by the cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex Ports. It's been years since I've submitted kernel.org patches, I appolgise for the almost certain submission errors. v2: Alexander point out that the v1 was only a part of the whole solution, some platform which has some issues could use the new flag to indicate that it is not safe to enable relaxed ordering attribute, then we need to clear the relaxed ordering enable bits in the PCI configuration when initializing the device. So add a new second patch to modify the PCI initialization code to clear the relaxed ordering enable bit in the event that the root complex doesn't want relaxed ordering enabled. The third patch was base on the v1's second patch and only be changed to query the relaxed ordering enable bit in the PCI configuration space to allow the Chelsio NIC to send TLPs with the relaxed ordering attributes set. This version didn't plan to drop the defines for Intel Drivers to use the new checking way to enable relaxed ordering because it is not the hardest part of the moment, we could fix it in next patchset when this patches reach the goal. v3: Redesigned the logic for pci_configure_relaxed_ordering when configuration, If a PCIe device didn't enable the relaxed ordering attribute default, we should not do anything in the PCIe configuration, otherwise we should check if any of the devices above us do not support relaxed ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on the result if we get a return that indicate that the relaxed ordering is not supported we should update our device to disable relaxed ordering in configuration space. If the device above us doesn't exist or isn't the PCIe device, we shouldn't do anything and skip updating relaxed ordering because we are probably running in a guest. v4: Rename the functions pcie_get_relaxed_ordering and pcie_disable_relaxed_ordering according John's suggestion, and modify the description, use the true/false as the return value. We shouldn't enable relaxed ordering attribute by the setting in the root complex configuration space for PCIe device, so fix it for cxgb4. Fix some format issues. v5: Removed the unnecessary code for some function which only return the bool value, and add the check for VF device. Make this patch set base on 4.12-rc5. v6: Fix the logic error in the need to enable the relaxed ordering attribute for cxgb4. v7: The cxgb4 drivers will enable the PCIe Capability Device Control[Relaxed Ordering Enable] in PCI Probe() routine, this will break our current solution for some platform which has problematic when enable the relaxed ordering attribute. According to the latest recommendations, remove the enable_pcie_relaxed_ordering(), although it could not cover the Peer-to-Peer scene, but we agree to leave this problem until we really trigger it. Make this patch set base on 4.12 release version. Casey Leedom (2): PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Ding Tianhong (1): PCI: Enable PCIe Relaxed Ordering if supported drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 + drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 17 ++++++++++ drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +-- drivers/pci/pci.c | 32 +++++++++++++++++++ drivers/pci/probe.c | 41 +++++++++++++++++++++++++ drivers/pci/quirks.c | 38 +++++++++++++++++++++++ include/linux/pci.h | 4 +++ 7 files changed, 136 insertions(+), 2 deletions(-) -- 1.9.0 ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-13 14:21 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-13 14:21 UTC (permalink / raw) To: linux-arm-kernel Some devices have problems with Transaction Layer Packets with the Relaxed Ordering Attribute set. This patch set adds a new PCIe Device Flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING, a set of PCI Quirks to catch some known devices with Relaxed Ordering issues, and a use of this new flag by the cxgb4 driver to avoid using Relaxed Ordering with problematic Root Complex Ports. It's been years since I've submitted kernel.org patches, I appolgise for the almost certain submission errors. v2: Alexander point out that the v1 was only a part of the whole solution, some platform which has some issues could use the new flag to indicate that it is not safe to enable relaxed ordering attribute, then we need to clear the relaxed ordering enable bits in the PCI configuration when initializing the device. So add a new second patch to modify the PCI initialization code to clear the relaxed ordering enable bit in the event that the root complex doesn't want relaxed ordering enabled. The third patch was base on the v1's second patch and only be changed to query the relaxed ordering enable bit in the PCI configuration space to allow the Chelsio NIC to send TLPs with the relaxed ordering attributes set. This version didn't plan to drop the defines for Intel Drivers to use the new checking way to enable relaxed ordering because it is not the hardest part of the moment, we could fix it in next patchset when this patches reach the goal. v3: Redesigned the logic for pci_configure_relaxed_ordering when configuration, If a PCIe device didn't enable the relaxed ordering attribute default, we should not do anything in the PCIe configuration, otherwise we should check if any of the devices above us do not support relaxed ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on the result if we get a return that indicate that the relaxed ordering is not supported we should update our device to disable relaxed ordering in configuration space. If the device above us doesn't exist or isn't the PCIe device, we shouldn't do anything and skip updating relaxed ordering because we are probably running in a guest. v4: Rename the functions pcie_get_relaxed_ordering and pcie_disable_relaxed_ordering according John's suggestion, and modify the description, use the true/false as the return value. We shouldn't enable relaxed ordering attribute by the setting in the root complex configuration space for PCIe device, so fix it for cxgb4. Fix some format issues. v5: Removed the unnecessary code for some function which only return the bool value, and add the check for VF device. Make this patch set base on 4.12-rc5. v6: Fix the logic error in the need to enable the relaxed ordering attribute for cxgb4. v7: The cxgb4 drivers will enable the PCIe Capability Device Control[Relaxed Ordering Enable] in PCI Probe() routine, this will break our current solution for some platform which has problematic when enable the relaxed ordering attribute. According to the latest recommendations, remove the enable_pcie_relaxed_ordering(), although it could not cover the Peer-to-Peer scene, but we agree to leave this problem until we really trigger it. Make this patch set base on 4.12 release version. Casey Leedom (2): PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Ding Tianhong (1): PCI: Enable PCIe Relaxed Ordering if supported drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 + drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 17 ++++++++++ drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +-- drivers/pci/pci.c | 32 +++++++++++++++++++ drivers/pci/probe.c | 41 +++++++++++++++++++++++++ drivers/pci/quirks.c | 38 +++++++++++++++++++++++ include/linux/pci.h | 4 +++ 7 files changed, 136 insertions(+), 2 deletions(-) -- 1.9.0 ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING 2017-07-13 14:21 ` Ding Tianhong @ 2017-07-13 14:21 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-13 14:21 UTC (permalink / raw) To: leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm Cc: Ding Tianhong From: Casey Leedom <leedom@chelsio.com> The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed Ordering Attribute should not be used on Transaction Layer Packets destined for the PCIe End Node so flagged. Initially flagged this way are Intel E5-26xx Root Complex Ports which suffer from a Flow Control Credit Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which don't obey PCIe 3.0 ordering rules which can lead to Data Corruption. Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> --- drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++ include/linux/pci.h | 2 ++ 2 files changed, 40 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 6967c6b..1e1cdbe 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -4016,6 +4016,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev) quirk_tw686x_class); /* + * Some devices have problems with Transaction Layer Packets with the Relaxed + * Ordering Attribute set. Such devices should mark themselves and other + * Device Drivers should check before sending TLPs with RO set. + */ +static void quirk_relaxedordering_disable(struct pci_dev *dev) +{ + dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING; +} + +/* + * Intel E5-26xx Root Complex has a Flow Control Credit issue which can + * cause performance problems with Upstream Transaction Layer Packets with + * Relaxed Ordering set. + */ +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f02, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f04, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f08, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); + +/* + * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex + * where Upstream Transaction Layer Packets with the Relaxed Ordering + * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering + * set. This is a violation of the PCIe 3.0 Transaction Ordering Rules + * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0 + * November 10, 2010). As a result, on this platform we can't use Relaxed + * Ordering for Upstream TLPs. + */ +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a00, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a01, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a02, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); + +/* * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same * values for the Attribute as were supplied in the header of the * corresponding Request, except as explicitly allowed when IDO is used." diff --git a/include/linux/pci.h b/include/linux/pci.h index 4869e66..412ec1c 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -188,6 +188,8 @@ enum pci_dev_flags { * the direct_complete optimization. */ PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 11), + /* Don't use Relaxed Ordering for TLPs directed at this device */ + PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 12), }; enum pci_irq_reroute_variant { -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING @ 2017-07-13 14:21 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-13 14:21 UTC (permalink / raw) To: linux-arm-kernel From: Casey Leedom <leedom@chelsio.com> The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed Ordering Attribute should not be used on Transaction Layer Packets destined for the PCIe End Node so flagged. Initially flagged this way are Intel E5-26xx Root Complex Ports which suffer from a Flow Control Credit Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which don't obey PCIe 3.0 ordering rules which can lead to Data Corruption. Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> --- drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++ include/linux/pci.h | 2 ++ 2 files changed, 40 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 6967c6b..1e1cdbe 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -4016,6 +4016,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev) quirk_tw686x_class); /* + * Some devices have problems with Transaction Layer Packets with the Relaxed + * Ordering Attribute set. Such devices should mark themselves and other + * Device Drivers should check before sending TLPs with RO set. + */ +static void quirk_relaxedordering_disable(struct pci_dev *dev) +{ + dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING; +} + +/* + * Intel E5-26xx Root Complex has a Flow Control Credit issue which can + * cause performance problems with Upstream Transaction Layer Packets with + * Relaxed Ordering set. + */ +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f02, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f04, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f08, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); + +/* + * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex + * where Upstream Transaction Layer Packets with the Relaxed Ordering + * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering + * set. This is a violation of the PCIe 3.0 Transaction Ordering Rules + * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0 + * November 10, 2010). As a result, on this platform we can't use Relaxed + * Ordering for Upstream TLPs. + */ +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a00, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a01, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a02, PCI_CLASS_NOT_DEFINED, 8, + quirk_relaxedordering_disable); + +/* * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same * values for the Attribute as were supplied in the header of the * corresponding Request, except as explicitly allowed when IDO is used." diff --git a/include/linux/pci.h b/include/linux/pci.h index 4869e66..412ec1c 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -188,6 +188,8 @@ enum pci_dev_flags { * the direct_complete optimization. */ PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 11), + /* Don't use Relaxed Ordering for TLPs directed@this device */ + PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 12), }; enum pci_irq_reroute_variant { -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 114+ messages in thread
* Re: [PATCH v7 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING 2017-07-13 14:21 ` Ding Tianhong @ 2017-08-03 8:55 ` Raj, Ashok -1 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-03 8:55 UTC (permalink / raw) To: Ding Tianhong Cc: leedom, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm, ashok.raj Hi Ding Not sure if V7 is the last version. can you consider rewording this just to make it a little bit more readable? My suggestion below, feel free to use/modify Otherwise its all good and you can add my Ack. Acked-by: Ashok Raj <ashok.raj@intel.com> On Thu, Jul 13, 2017 at 10:21:30PM +0800, Ding Tianhong wrote: > From: Casey Leedom <leedom@chelsio.com> > > The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed > Ordering Attribute should not be used on Transaction Layer Packets destined > for the PCIe End Node so flagged. Initially flagged this way are Intel > E5-26xx Root Complex Ports which suffer from a Flow Control Credit > Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which > don't obey PCIe 3.0 ordering rules which can lead to Data Corruption. The patch adds a new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING to indicate that Relaxed Ordering (RO) attribute should not be used for Transaction Layer Packets (TLP) targetted towards these affected root complexes. Current list of affected parts include Intel E5-26xx root complex which suffers from flow control credits that result in performance issues. On these affected parts RO can still be used for peer-2-peer traffic. AMD A1100 ARM ("SEATTLE") Root complexes don't obey PCIe 3.0 ordering rules, hence could lead to data-corruption. > > Signed-off-by: Casey Leedom <leedom@chelsio.com> > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> > --- > drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++ > include/linux/pci.h | 2 ++ > 2 files changed, 40 insertions(+) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 6967c6b..1e1cdbe 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -4016,6 +4016,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev) > quirk_tw686x_class); > > /* > + * Some devices have problems with Transaction Layer Packets with the Relaxed > + * Ordering Attribute set. Such devices should mark themselves and other > + * Device Drivers should check before sending TLPs with RO set. > + */ > +static void quirk_relaxedordering_disable(struct pci_dev *dev) > +{ > + dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING; > +} > + > +/* > + * Intel E5-26xx Root Complex has a Flow Control Credit issue which can > + * cause performance problems with Upstream Transaction Layer Packets with > + * Relaxed Ordering set. > + */ > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f02, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f04, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f08, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > + > +/* > + * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex > + * where Upstream Transaction Layer Packets with the Relaxed Ordering > + * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering > + * set. This is a violation of the PCIe 3.0 Transaction Ordering Rules > + * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0 > + * November 10, 2010). As a result, on this platform we can't use Relaxed > + * Ordering for Upstream TLPs. > + */ > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a00, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a01, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a02, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > + > +/* > * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same > * values for the Attribute as were supplied in the header of the > * corresponding Request, except as explicitly allowed when IDO is used." > diff --git a/include/linux/pci.h b/include/linux/pci.h > index 4869e66..412ec1c 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -188,6 +188,8 @@ enum pci_dev_flags { > * the direct_complete optimization. > */ > PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 11), > + /* Don't use Relaxed Ordering for TLPs directed at this device */ > + PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 12), > }; > > enum pci_irq_reroute_variant { > -- > 1.8.3.1 > > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING @ 2017-08-03 8:55 ` Raj, Ashok 0 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-03 8:55 UTC (permalink / raw) To: linux-arm-kernel Hi Ding Not sure if V7 is the last version. can you consider rewording this just to make it a little bit more readable? My suggestion below, feel free to use/modify Otherwise its all good and you can add my Ack. Acked-by: Ashok Raj <ashok.raj@intel.com> On Thu, Jul 13, 2017 at 10:21:30PM +0800, Ding Tianhong wrote: > From: Casey Leedom <leedom@chelsio.com> > > The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed > Ordering Attribute should not be used on Transaction Layer Packets destined > for the PCIe End Node so flagged. Initially flagged this way are Intel > E5-26xx Root Complex Ports which suffer from a Flow Control Credit > Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which > don't obey PCIe 3.0 ordering rules which can lead to Data Corruption. The patch adds a new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING to indicate that Relaxed Ordering (RO) attribute should not be used for Transaction Layer Packets (TLP) targetted towards these affected root complexes. Current list of affected parts include Intel E5-26xx root complex which suffers from flow control credits that result in performance issues. On these affected parts RO can still be used for peer-2-peer traffic. AMD A1100 ARM ("SEATTLE") Root complexes don't obey PCIe 3.0 ordering rules, hence could lead to data-corruption. > > Signed-off-by: Casey Leedom <leedom@chelsio.com> > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> > --- > drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++ > include/linux/pci.h | 2 ++ > 2 files changed, 40 insertions(+) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 6967c6b..1e1cdbe 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -4016,6 +4016,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev) > quirk_tw686x_class); > > /* > + * Some devices have problems with Transaction Layer Packets with the Relaxed > + * Ordering Attribute set. Such devices should mark themselves and other > + * Device Drivers should check before sending TLPs with RO set. > + */ > +static void quirk_relaxedordering_disable(struct pci_dev *dev) > +{ > + dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING; > +} > + > +/* > + * Intel E5-26xx Root Complex has a Flow Control Credit issue which can > + * cause performance problems with Upstream Transaction Layer Packets with > + * Relaxed Ordering set. > + */ > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f02, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f04, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f08, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > + > +/* > + * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex > + * where Upstream Transaction Layer Packets with the Relaxed Ordering > + * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering > + * set. This is a violation of the PCIe 3.0 Transaction Ordering Rules > + * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0 > + * November 10, 2010). As a result, on this platform we can't use Relaxed > + * Ordering for Upstream TLPs. > + */ > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a00, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a01, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a02, PCI_CLASS_NOT_DEFINED, 8, > + quirk_relaxedordering_disable); > + > +/* > * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same > * values for the Attribute as were supplied in the header of the > * corresponding Request, except as explicitly allowed when IDO is used." > diff --git a/include/linux/pci.h b/include/linux/pci.h > index 4869e66..412ec1c 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -188,6 +188,8 @@ enum pci_dev_flags { > * the direct_complete optimization. > */ > PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 11), > + /* Don't use Relaxed Ordering for TLPs directed at this device */ > + PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 12), > }; > > enum pci_irq_reroute_variant { > -- > 1.8.3.1 > > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING 2017-08-03 8:55 ` Raj, Ashok @ 2017-08-03 10:20 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-08-03 10:20 UTC (permalink / raw) To: Raj, Ashok Cc: leedom, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm On 2017/8/3 16:55, Raj, Ashok wrote: > Hi Ding > > Not sure if V7 is the last version. > > can you consider rewording this just to make it a little bit more > readable? My suggestion below, feel free to use/modify > > Otherwise its all good and you can add my Ack. > > Acked-by: Ashok Raj <ashok.raj@intel.com> > > On Thu, Jul 13, 2017 at 10:21:30PM +0800, Ding Tianhong wrote: >> From: Casey Leedom <leedom@chelsio.com> > Thanks, Ashok. :) Regards Ding > >> >> The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed >> Ordering Attribute should not be used on Transaction Layer Packets destined >> for the PCIe End Node so flagged. Initially flagged this way are Intel >> E5-26xx Root Complex Ports which suffer from a Flow Control Credit >> Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which >> don't obey PCIe 3.0 ordering rules which can lead to Data Corruption. > > The patch adds a new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING to indicate that > Relaxed Ordering (RO) attribute should not be used for Transaction Layer > Packets (TLP) targetted towards these affected root complexes. Current list > of affected parts include Intel E5-26xx root complex which suffers from > flow control credits that result in performance issues. On these affected > parts RO can still be used for peer-2-peer traffic. AMD A1100 ARM ("SEATTLE") > Root complexes don't obey PCIe 3.0 ordering rules, hence could lead to > data-corruption. >> >> Signed-off-by: Casey Leedom <leedom@chelsio.com> >> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> >> --- >> drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++ >> include/linux/pci.h | 2 ++ >> 2 files changed, 40 insertions(+) >> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >> index 6967c6b..1e1cdbe 100644 >> --- a/drivers/pci/quirks.c >> +++ b/drivers/pci/quirks.c >> @@ -4016,6 +4016,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev) >> quirk_tw686x_class); >> >> /* >> + * Some devices have problems with Transaction Layer Packets with the Relaxed >> + * Ordering Attribute set. Such devices should mark themselves and other >> + * Device Drivers should check before sending TLPs with RO set. >> + */ >> +static void quirk_relaxedordering_disable(struct pci_dev *dev) >> +{ >> + dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING; >> +} >> + >> +/* >> + * Intel E5-26xx Root Complex has a Flow Control Credit issue which can >> + * cause performance problems with Upstream Transaction Layer Packets with >> + * Relaxed Ordering set. >> + */ >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f02, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f04, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f08, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> + >> +/* >> + * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex >> + * where Upstream Transaction Layer Packets with the Relaxed Ordering >> + * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering >> + * set. This is a violation of the PCIe 3.0 Transaction Ordering Rules >> + * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0 >> + * November 10, 2010). As a result, on this platform we can't use Relaxed >> + * Ordering for Upstream TLPs. >> + */ >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a00, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a01, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a02, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> + >> +/* >> * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same >> * values for the Attribute as were supplied in the header of the >> * corresponding Request, except as explicitly allowed when IDO is used." >> diff --git a/include/linux/pci.h b/include/linux/pci.h >> index 4869e66..412ec1c 100644 >> --- a/include/linux/pci.h >> +++ b/include/linux/pci.h >> @@ -188,6 +188,8 @@ enum pci_dev_flags { >> * the direct_complete optimization. >> */ >> PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 11), >> + /* Don't use Relaxed Ordering for TLPs directed at this device */ >> + PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 12), >> }; >> >> enum pci_irq_reroute_variant { >> -- >> 1.8.3.1 >> >> > > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING @ 2017-08-03 10:20 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-08-03 10:20 UTC (permalink / raw) To: linux-arm-kernel On 2017/8/3 16:55, Raj, Ashok wrote: > Hi Ding > > Not sure if V7 is the last version. > > can you consider rewording this just to make it a little bit more > readable? My suggestion below, feel free to use/modify > > Otherwise its all good and you can add my Ack. > > Acked-by: Ashok Raj <ashok.raj@intel.com> > > On Thu, Jul 13, 2017 at 10:21:30PM +0800, Ding Tianhong wrote: >> From: Casey Leedom <leedom@chelsio.com> > Thanks, Ashok. :) Regards Ding > >> >> The new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING indicates that the Relaxed >> Ordering Attribute should not be used on Transaction Layer Packets destined >> for the PCIe End Node so flagged. Initially flagged this way are Intel >> E5-26xx Root Complex Ports which suffer from a Flow Control Credit >> Performance Problem and AMD A1100 ARM ("SEATTLE") Root Complex Ports which >> don't obey PCIe 3.0 ordering rules which can lead to Data Corruption. > > The patch adds a new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING to indicate that > Relaxed Ordering (RO) attribute should not be used for Transaction Layer > Packets (TLP) targetted towards these affected root complexes. Current list > of affected parts include Intel E5-26xx root complex which suffers from > flow control credits that result in performance issues. On these affected > parts RO can still be used for peer-2-peer traffic. AMD A1100 ARM ("SEATTLE") > Root complexes don't obey PCIe 3.0 ordering rules, hence could lead to > data-corruption. >> >> Signed-off-by: Casey Leedom <leedom@chelsio.com> >> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> >> --- >> drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++ >> include/linux/pci.h | 2 ++ >> 2 files changed, 40 insertions(+) >> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c >> index 6967c6b..1e1cdbe 100644 >> --- a/drivers/pci/quirks.c >> +++ b/drivers/pci/quirks.c >> @@ -4016,6 +4016,44 @@ static void quirk_tw686x_class(struct pci_dev *pdev) >> quirk_tw686x_class); >> >> /* >> + * Some devices have problems with Transaction Layer Packets with the Relaxed >> + * Ordering Attribute set. Such devices should mark themselves and other >> + * Device Drivers should check before sending TLPs with RO set. >> + */ >> +static void quirk_relaxedordering_disable(struct pci_dev *dev) >> +{ >> + dev->dev_flags |= PCI_DEV_FLAGS_NO_RELAXED_ORDERING; >> +} >> + >> +/* >> + * Intel E5-26xx Root Complex has a Flow Control Credit issue which can >> + * cause performance problems with Upstream Transaction Layer Packets with >> + * Relaxed Ordering set. >> + */ >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f02, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f04, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, 0x6f08, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> + >> +/* >> + * The AMD ARM A1100 (AKA "SEATTLE") SoC has a bug in its PCIe Root Complex >> + * where Upstream Transaction Layer Packets with the Relaxed Ordering >> + * Attribute clear are allowed to bypass earlier TLPs with Relaxed Ordering >> + * set. This is a violation of the PCIe 3.0 Transaction Ordering Rules >> + * outlined in Section 2.4.1 (PCI Express(r) Base Specification Revision 3.0 >> + * November 10, 2010). As a result, on this platform we can't use Relaxed >> + * Ordering for Upstream TLPs. >> + */ >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a00, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a01, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AMD, 0x1a02, PCI_CLASS_NOT_DEFINED, 8, >> + quirk_relaxedordering_disable); >> + >> +/* >> * Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same >> * values for the Attribute as were supplied in the header of the >> * corresponding Request, except as explicitly allowed when IDO is used." >> diff --git a/include/linux/pci.h b/include/linux/pci.h >> index 4869e66..412ec1c 100644 >> --- a/include/linux/pci.h >> +++ b/include/linux/pci.h >> @@ -188,6 +188,8 @@ enum pci_dev_flags { >> * the direct_complete optimization. >> */ >> PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 11), >> + /* Don't use Relaxed Ordering for TLPs directed at this device */ >> + PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 12), >> }; >> >> enum pci_irq_reroute_variant { >> -- >> 1.8.3.1 >> >> > > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-13 14:21 ` Ding Tianhong (?) @ 2017-07-13 14:21 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-13 14:21 UTC (permalink / raw) To: leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm Cc: Ding Tianhong 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 by default. If a PCIe device didn't enable the relaxed ordering attribute default, we should not do anything in the PCIe configuration, otherwise we should check if any of the devices above us do not support relaxed ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on the result if we get a return that indicate that the relaxed ordering is not supported we should update our device to disable relaxed ordering in configuration space. If the device above us doesn't exist or isn't the PCIe device, we shouldn't do anything and skip updating relaxed ordering because we are probably running in a guest machine. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> --- drivers/pci/pci.c | 29 +++++++++++++++++++++++++++++ drivers/pci/probe.c | 37 +++++++++++++++++++++++++++++++++++++ include/linux/pci.h | 2 ++ 3 files changed, 68 insertions(+) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index d88edf5..7a6b32f 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4854,6 +4854,35 @@ int pcie_set_mps(struct pci_dev *dev, int mps) EXPORT_SYMBOL(pcie_set_mps); /** + * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit + * @dev: PCI device to query + * + * If possible clear relaxed ordering + */ +int pcie_clear_relaxed_ordering(struct pci_dev *dev) +{ + return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, + PCI_EXP_DEVCTL_RELAX_EN); +} +EXPORT_SYMBOL(pcie_clear_relaxed_ordering); + +/** + * pcie_relaxed_ordering_supported - Probe for PCIe relexed ordering support + * @dev: PCI device to query + * + * Returns true if the device support relaxed ordering attribute. + */ +bool pcie_relaxed_ordering_supported(struct pci_dev *dev) +{ + u16 v; + + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v); + + return !!(v & PCI_EXP_DEVCTL_RELAX_EN); +} +EXPORT_SYMBOL(pcie_relaxed_ordering_supported); + +/** * pcie_get_minimum_link - determine minimum link settings of a PCI device * @dev: PCI device to query * @speed: storage for minimum speed diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index c31310d..48df012 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1762,6 +1762,42 @@ static void pci_configure_extended_tags(struct pci_dev *dev) PCI_EXP_DEVCTL_EXT_TAG); } +/** + * pci_dev_should_disable_relaxed_ordering - check if the PCI device + * should disable the relaxed ordering attribute. + * @dev: PCI device + * + * Return true if any of the PCI devices above us do not support + * relaxed ordering. + */ +static bool pci_dev_should_disable_relaxed_ordering(struct pci_dev *dev) +{ + while (dev) { + if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) + return true; + + dev = dev->bus->self; + } + + return false; +} + +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, do nothing. */ + if (!pcie_relaxed_ordering_supported(dev)) + return; + + if (pci_dev_should_disable_relaxed_ordering(dev)) { + pcie_clear_relaxed_ordering(dev); + dev_info(&dev->dev, "Disable Relaxed Ordering\n"); + } +} + static void pci_configure_device(struct pci_dev *dev) { struct hotplug_params hpp; @@ -1769,6 +1805,7 @@ static void pci_configure_device(struct pci_dev *dev) pci_configure_mps(dev); pci_configure_extended_tags(dev); + pci_configure_relaxed_ordering(dev); memset(&hpp, 0, sizeof(hpp)); ret = pci_get_hp_params(dev, &hpp); diff --git a/include/linux/pci.h b/include/linux/pci.h index 412ec1c..3aa23a2 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1127,6 +1127,8 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev, void pci_pme_wakeup_bus(struct pci_bus *bus); void pci_d3cold_enable(struct pci_dev *dev); void pci_d3cold_disable(struct pci_dev *dev); +int pcie_clear_relaxed_ordering(struct pci_dev *dev); +bool pcie_relaxed_ordering_supported(struct pci_dev *dev); /* PCI Virtual Channel */ int pci_save_vc_state(struct pci_dev *dev); -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-13 14:21 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-13 14:21 UTC (permalink / raw) To: linux-arm-kernel 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 by default. If a PCIe device didn't enable the relaxed ordering attribute default, we should not do anything in the PCIe configuration, otherwise we should check if any of the devices above us do not support relaxed ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on the result if we get a return that indicate that the relaxed ordering is not supported we should update our device to disable relaxed ordering in configuration space. If the device above us doesn't exist or isn't the PCIe device, we shouldn't do anything and skip updating relaxed ordering because we are probably running in a guest machine. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> --- drivers/pci/pci.c | 29 +++++++++++++++++++++++++++++ drivers/pci/probe.c | 37 +++++++++++++++++++++++++++++++++++++ include/linux/pci.h | 2 ++ 3 files changed, 68 insertions(+) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index d88edf5..7a6b32f 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4854,6 +4854,35 @@ int pcie_set_mps(struct pci_dev *dev, int mps) EXPORT_SYMBOL(pcie_set_mps); /** + * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit + * @dev: PCI device to query + * + * If possible clear relaxed ordering + */ +int pcie_clear_relaxed_ordering(struct pci_dev *dev) +{ + return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, + PCI_EXP_DEVCTL_RELAX_EN); +} +EXPORT_SYMBOL(pcie_clear_relaxed_ordering); + +/** + * pcie_relaxed_ordering_supported - Probe for PCIe relexed ordering support + * @dev: PCI device to query + * + * Returns true if the device support relaxed ordering attribute. + */ +bool pcie_relaxed_ordering_supported(struct pci_dev *dev) +{ + u16 v; + + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v); + + return !!(v & PCI_EXP_DEVCTL_RELAX_EN); +} +EXPORT_SYMBOL(pcie_relaxed_ordering_supported); + +/** * pcie_get_minimum_link - determine minimum link settings of a PCI device * @dev: PCI device to query * @speed: storage for minimum speed diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index c31310d..48df012 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1762,6 +1762,42 @@ static void pci_configure_extended_tags(struct pci_dev *dev) PCI_EXP_DEVCTL_EXT_TAG); } +/** + * pci_dev_should_disable_relaxed_ordering - check if the PCI device + * should disable the relaxed ordering attribute. + * @dev: PCI device + * + * Return true if any of the PCI devices above us do not support + * relaxed ordering. + */ +static bool pci_dev_should_disable_relaxed_ordering(struct pci_dev *dev) +{ + while (dev) { + if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) + return true; + + dev = dev->bus->self; + } + + return false; +} + +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, do nothing. */ + if (!pcie_relaxed_ordering_supported(dev)) + return; + + if (pci_dev_should_disable_relaxed_ordering(dev)) { + pcie_clear_relaxed_ordering(dev); + dev_info(&dev->dev, "Disable Relaxed Ordering\n"); + } +} + static void pci_configure_device(struct pci_dev *dev) { struct hotplug_params hpp; @@ -1769,6 +1805,7 @@ static void pci_configure_device(struct pci_dev *dev) pci_configure_mps(dev); pci_configure_extended_tags(dev); + pci_configure_relaxed_ordering(dev); memset(&hpp, 0, sizeof(hpp)); ret = pci_get_hp_params(dev, &hpp); diff --git a/include/linux/pci.h b/include/linux/pci.h index 412ec1c..3aa23a2 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1127,6 +1127,8 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev, void pci_pme_wakeup_bus(struct pci_bus *bus); void pci_d3cold_enable(struct pci_dev *dev); void pci_d3cold_disable(struct pci_dev *dev); +int pcie_clear_relaxed_ordering(struct pci_dev *dev); +bool pcie_relaxed_ordering_supported(struct pci_dev *dev); /* PCI Virtual Channel */ int pci_save_vc_state(struct pci_dev *dev); -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-13 14:21 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-13 14:21 UTC (permalink / raw) To: leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm Cc: Ding Tianhong 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 by default. If a PCIe device didn't enable the relaxed ordering attribute default, we should not do anything in the PCIe configuration, otherwise we should check if any of the devices above us do not support relaxed ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on the result if we get a return that indicate that the relaxed ordering is not supported we should update our device to disable relaxed ordering in configuration space. If the device above us doesn't exist or isn't the PCIe device, we shouldn't do anything and skip updating relaxed ordering because we are probably running in a guest machine. Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> --- drivers/pci/pci.c | 29 +++++++++++++++++++++++++++++ drivers/pci/probe.c | 37 +++++++++++++++++++++++++++++++++++++ include/linux/pci.h | 2 ++ 3 files changed, 68 insertions(+) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index d88edf5..7a6b32f 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -4854,6 +4854,35 @@ int pcie_set_mps(struct pci_dev *dev, int mps) EXPORT_SYMBOL(pcie_set_mps); /** + * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit + * @dev: PCI device to query + * + * If possible clear relaxed ordering + */ +int pcie_clear_relaxed_ordering(struct pci_dev *dev) +{ + return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, + PCI_EXP_DEVCTL_RELAX_EN); +} +EXPORT_SYMBOL(pcie_clear_relaxed_ordering); + +/** + * pcie_relaxed_ordering_supported - Probe for PCIe relexed ordering support + * @dev: PCI device to query + * + * Returns true if the device support relaxed ordering attribute. + */ +bool pcie_relaxed_ordering_supported(struct pci_dev *dev) +{ + u16 v; + + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v); + + return !!(v & PCI_EXP_DEVCTL_RELAX_EN); +} +EXPORT_SYMBOL(pcie_relaxed_ordering_supported); + +/** * pcie_get_minimum_link - determine minimum link settings of a PCI device * @dev: PCI device to query * @speed: storage for minimum speed diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index c31310d..48df012 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1762,6 +1762,42 @@ static void pci_configure_extended_tags(struct pci_dev *dev) PCI_EXP_DEVCTL_EXT_TAG); } +/** + * pci_dev_should_disable_relaxed_ordering - check if the PCI device + * should disable the relaxed ordering attribute. + * @dev: PCI device + * + * Return true if any of the PCI devices above us do not support + * relaxed ordering. + */ +static bool pci_dev_should_disable_relaxed_ordering(struct pci_dev *dev) +{ + while (dev) { + if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) + return true; + + dev = dev->bus->self; + } + + return false; +} + +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, do nothing. */ + if (!pcie_relaxed_ordering_supported(dev)) + return; + + if (pci_dev_should_disable_relaxed_ordering(dev)) { + pcie_clear_relaxed_ordering(dev); + dev_info(&dev->dev, "Disable Relaxed Ordering\n"); + } +} + static void pci_configure_device(struct pci_dev *dev) { struct hotplug_params hpp; @@ -1769,6 +1805,7 @@ static void pci_configure_device(struct pci_dev *dev) pci_configure_mps(dev); pci_configure_extended_tags(dev); + pci_configure_relaxed_ordering(dev); memset(&hpp, 0, sizeof(hpp)); ret = pci_get_hp_params(dev, &hpp); diff --git a/include/linux/pci.h b/include/linux/pci.h index 412ec1c..3aa23a2 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -1127,6 +1127,8 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev, void pci_pme_wakeup_bus(struct pci_bus *bus); void pci_d3cold_enable(struct pci_dev *dev); void pci_d3cold_disable(struct pci_dev *dev); +int pcie_clear_relaxed_ordering(struct pci_dev *dev); +bool pcie_relaxed_ordering_supported(struct pci_dev *dev); /* PCI Virtual Channel */ int pci_save_vc_state(struct pci_dev *dev); -- 1.8.3.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-13 14:21 ` Ding Tianhong @ 2017-07-13 21:09 ` Sinan Kaya -1 siblings, 0 replies; 114+ messages in thread From: Sinan Kaya @ 2017-07-13 21:09 UTC (permalink / raw) To: Ding Tianhong, leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm 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, do nothing. */ > + if (!pcie_relaxed_ordering_supported(dev)) > + return; > + > + if (pci_dev_should_disable_relaxed_ordering(dev)) { > + pcie_clear_relaxed_ordering(dev); > + dev_info(&dev->dev, "Disable Relaxed Ordering\n"); > + } > +} I couldn't find anywhere where you actually enable the relaxed ordering like the subject suggests. -- 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. ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-13 21:09 ` Sinan Kaya 0 siblings, 0 replies; 114+ messages in thread From: Sinan Kaya @ 2017-07-13 21:09 UTC (permalink / raw) To: linux-arm-kernel 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, do nothing. */ > + if (!pcie_relaxed_ordering_supported(dev)) > + return; > + > + if (pci_dev_should_disable_relaxed_ordering(dev)) { > + pcie_clear_relaxed_ordering(dev); > + dev_info(&dev->dev, "Disable Relaxed Ordering\n"); > + } > +} I couldn't find anywhere where you actually enable the relaxed ordering like the subject suggests. -- 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. ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-13 21:09 ` Sinan Kaya @ 2017-07-14 1:26 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-14 1:26 UTC (permalink / raw) To: Sinan Kaya, leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm 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 the releaxed ordering enable bit is not set, do nothing. */ >> + if (!pcie_relaxed_ordering_supported(dev)) >> + return; >> + >> + if (pci_dev_should_disable_relaxed_ordering(dev)) { >> + pcie_clear_relaxed_ordering(dev); >> + dev_info(&dev->dev, "Disable Relaxed Ordering\n"); >> + } >> +} > > I couldn't find anywhere where you actually enable the relaxed ordering > like the subject suggests. > 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 Ordering bit to tell the PCIe EP don't send any TLPs with Relaxed Ordering Attributes to the Root Complex. Thanks Ding ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-14 1:26 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-14 1:26 UTC (permalink / raw) To: linux-arm-kernel 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 the releaxed ordering enable bit is not set, do nothing. */ >> + if (!pcie_relaxed_ordering_supported(dev)) >> + return; >> + >> + if (pci_dev_should_disable_relaxed_ordering(dev)) { >> + pcie_clear_relaxed_ordering(dev); >> + dev_info(&dev->dev, "Disable Relaxed Ordering\n"); >> + } >> +} > > I couldn't find anywhere where you actually enable the relaxed ordering > like the subject suggests. > 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 Ordering bit to tell the PCIe EP don't send any TLPs with Relaxed Ordering Attributes to the Root Complex. Thanks Ding ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-14 1:26 ` Ding Tianhong @ 2017-07-14 13:54 ` Sinan Kaya -1 siblings, 0 replies; 114+ messages in thread From: Sinan Kaya @ 2017-07-14 13:54 UTC (permalink / raw) To: Ding Tianhong, leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm 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 Ordering bit > to tell the PCIe EP don't send any TLPs with Relaxed Ordering Attributes to the Root > Complex. Maybe, you should change the patch commit as "Disable PCIe Relaxed Ordering if not supported"... -- 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. ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-14 13:54 ` Sinan Kaya 0 siblings, 0 replies; 114+ messages in thread From: Sinan Kaya @ 2017-07-14 13:54 UTC (permalink / raw) To: linux-arm-kernel 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 Ordering bit > to tell the PCIe EP don't send any TLPs with Relaxed Ordering Attributes to the Root > Complex. Maybe, you should change the patch commit as "Disable PCIe Relaxed Ordering if not supported"... -- 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. ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-14 13:54 ` Sinan Kaya @ 2017-07-22 4:19 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-22 4:19 UTC (permalink / raw) To: Sinan Kaya, leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm, Bjorn Helgaas 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 distinguish the RC problematic platform and clear the Relaxed Ordering bit >> to tell the PCIe EP don't send any TLPs with Relaxed Ordering Attributes to the Root >> Complex. > > Maybe, you should change the patch commit as > "Disable PCIe Relaxed Ordering if not supported"... I agree that to use the new commit title as your suggested, thanks. :) @Bjorn do you want me to spawn a new patchset with the new commit title and the Reviewed-by from Casey on the patch 3, or maybe you could pick this up and modify it own ? thanks. Ding > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-22 4:19 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-22 4:19 UTC (permalink / raw) To: linux-arm-kernel 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 distinguish the RC problematic platform and clear the Relaxed Ordering bit >> to tell the PCIe EP don't send any TLPs with Relaxed Ordering Attributes to the Root >> Complex. > > Maybe, you should change the patch commit as > "Disable PCIe Relaxed Ordering if not supported"... I agree that to use the new commit title as your suggested, thanks. :) @Bjorn do you want me to spawn a new patchset with the new commit title and the Reviewed-by from Casey on the patch 3, or maybe you could pick this up and modify it own ? thanks. Ding > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-22 4:19 ` Ding Tianhong @ 2017-07-24 15:05 ` Alex Williamson -1 siblings, 0 replies; 114+ messages in thread From: Alex Williamson @ 2017-07-24 15:05 UTC (permalink / raw) To: Ding Tianhong Cc: Sinan Kaya, leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm On Sat, 22 Jul 2017 12:19:38 +0800 Ding Tianhong <dingtianhong@huawei.com> 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 default according to the PCIe Standard Specification, what we > >> do is to distinguish the RC problematic platform and clear the Relaxed Ordering bit > >> to tell the PCIe EP don't send any TLPs with Relaxed Ordering Attributes to the Root > >> Complex. > > > > Maybe, you should change the patch commit as > > "Disable PCIe Relaxed Ordering if not supported"... > > I agree that to use the new commit title as your suggested, thanks. :) > > @Bjorn do you want me to spawn a new patchset with the new commit title > and the Reviewed-by from Casey on the patch 3, or maybe you could pick this > up and modify it own ? thanks. Hi Ding, Bjorn is currently on holiday so it might be a good idea to respin the series with any updates so nothing is lost. Thanks, Alex ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-24 15:05 ` Alex Williamson 0 siblings, 0 replies; 114+ messages in thread From: Alex Williamson @ 2017-07-24 15:05 UTC (permalink / raw) To: linux-arm-kernel On Sat, 22 Jul 2017 12:19:38 +0800 Ding Tianhong <dingtianhong@huawei.com> 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 default according to the PCIe Standard Specification, what we > >> do is to distinguish the RC problematic platform and clear the Relaxed Ordering bit > >> to tell the PCIe EP don't send any TLPs with Relaxed Ordering Attributes to the Root > >> Complex. > > > > Maybe, you should change the patch commit as > > "Disable PCIe Relaxed Ordering if not supported"... > > I agree that to use the new commit title as your suggested, thanks. :) > > @Bjorn do you want me to spawn a new patchset with the new commit title > and the Reviewed-by from Casey on the patch 3, or maybe you could pick this > up and modify it own ? thanks. Hi Ding, Bjorn is currently on holiday so it might be a good idea to respin the series with any updates so nothing is lost. Thanks, Alex ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-24 15:05 ` Alex Williamson (?) (?) @ 2017-07-26 18:26 ` Casey Leedom -1 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-26 18:26 UTC (permalink / raw) To: Alex Williamson, Ding Tianhong Cc: Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm 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 hole in the patch with respect to PCIe SR-IOV Virtual Functions. When the PCI Quirk notices a problematic PCIe Device and marks it to note that it's not "happy" receiving Transaction Layer Packets with the Relaxed Ordering Attribute set, it's my understanding that your current patch iterates down the PCIe Fabric and turns off the PCIe Capability Device Control[Relaxed Ordering Enable]. But this scan may miss any SR-IOV VFs because they probably won't be instantiated at that time. And, at a later time, when they are instantiated, they could well have their Relaxed Ordering Enable set. 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 Root Complex is marked for no RO TLPs. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-26 18:26 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-26 18:26 UTC (permalink / raw) To: linux-arm-kernel 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 hole in the patch with respect to PCIe SR-IOV Virtual Functions. When the PCI Quirk notices a problematic PCIe Device and marks it to note that it's not "happy" receiving Transaction Layer Packets with the Relaxed Ordering Attribute set, it's my understanding that your current patch iterates down the PCIe Fabric and turns off the PCIe Capability Device Control[Relaxed Ordering Enable]. But this scan may miss any SR-IOV VFs because they probably won't be instantiated at that time. And, at a later time, when they are instantiated, they could well have their Relaxed Ordering Enable set. 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 Root Complex is marked for no RO TLPs. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-26 18:26 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-26 18:26 UTC (permalink / raw) To: Alex Williamson, Ding Tianhong Cc: Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm 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 hole in the patch with respect to PCIe SR-IOV Virtual Functions. When the PCI Quirk notices a problematic PCIe Device and marks it to note that it's not "happy" receiving Transaction Layer Packets with the Relaxed Ordering Attribute set, it's my understanding that your current patch iterates down the PCIe Fabric and turns off the PCIe Capability Device Control[Relaxed Ordering Enable]. But this scan may miss any SR-IOV VFs because they probably won't be instantiated at that time. And, at a later time, when they are instantiated, they could well have their Relaxed Ordering Enable set. 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 Root Complex is marked for no RO TLPs. Casey= ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-26 18:26 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-26 18:26 UTC (permalink / raw) To: Alex Williamson, Ding Tianhong Cc: Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas 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 hole in the patch with respect to PCIe SR-IOV Virtual Functions. When the PCI Quirk notices a problematic PCIe Device and marks it to note that it's not "happy" receiving Transaction Layer Packets with the Relaxed Ordering Attribute set, it's my understanding that your current patch iterates down the PCIe Fabric and turns off the PCIe Capability Device Control[Relaxed Ordering Enable]. But this scan may miss any SR-IOV VFs because they probably won't be instantiated at that time. And, at a later time, when they are instantiated, they could well have their Relaxed Ordering Enable set. 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 Root Complex is marked for no RO TLPs. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
[parent not found: <CAKgT0UeAad6WArvrE71MFJywDs1wOnCF-iJRnbNLrL+knqhXeA@mail.gmail.com>]
[parent not found: <CAKgT0Uf5hdXUXja_jUB6_kBg6pyX8zXuOMOGzCVNgeBFMUsWqQ@mail.gmail.com>]
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported [not found] ` <CAKgT0Uf5hdXUXja_jUB6_kBg6pyX8zXuOMOGzCVNgeBFMUsWqQ@mail.gmail.com> @ 2017-07-26 18:44 ` Alexander Duyck 2017-07-26 19:05 ` Casey Leedom 0 siblings, 1 reply; 114+ messages in thread From: Alexander Duyck @ 2017-07-26 18:44 UTC (permalink / raw) To: Casey Leedom Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR, asit.k.mallick, jeffrey.t.kirsher, mark.rutland, gabriele.paoloni, Michael Werner, bhelgaas, patrick.j.cramer, Ding Tianhong, linuxarm, amira, Bob.Shaw [-- Attachment #1: Type: text/plain, Size: 1369 bytes --] On Jul 26, 2017 11:26 AM, "Casey Leedom" <leedom@chelsio.com> 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 products. 2. I just realized that there's still a small hole in the patch with respect to PCIe SR-IOV Virtual Functions. When the PCI Quirk notices a problematic PCIe Device and marks it to note that it's not "happy" receiving Transaction Layer Packets with the Relaxed Ordering Attribute set, it's my understanding that your current patch iterates down the PCIe Fabric and turns off the PCIe Capability Device Control[Relaxed Ordering Enable]. But this scan may miss any SR-IOV VFs because they probably won't be instantiated at that time. And, at a later time, when they are instantiated, they could well have their Relaxed Ordering Enable set. 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 Root Complex is marked for no RO TLPs. Casey I'm not sure that would be an issue. Wouldn't most VFs inherit the PF's settings? Also I thought most of the VF configuration space is read only. - Alex [-- Attachment #2: Type: text/html, Size: 2114 bytes --] ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-26 18:44 ` Alexander Duyck 2017-07-26 19:05 ` Casey Leedom (?) @ 2017-07-26 19:05 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-26 19:05 UTC (permalink / raw) To: Alexander Duyck Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR, asit.k.mallick, jeffrey.t.kirsher, mark.rutland, gabriele.paoloni, Michael Werner, bhelgaas, patrick.j.cramer, Ding Tianhong, linuxarm, amira, Bob.Shaw | From: Alexander Duyck <alexander.duyck@gmail.com> | Sent: Wednesday, July 26, 2017 11:44 AM | | On Jul 26, 2017 11:26 AM, "Casey Leedom" <leedom@chelsio.com> 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 Root Complex is marked | for no RO TLPs. | | I'm not sure that would be an issue. Wouldn't most VFs inherit the PF's settings? Ah yes, you're right. This is covered in section 3.5.4 of the Single Root I/O Virtualization and Sharing Specification, Revision 1.0 (September 11, 2007), governing the PCIe Capability Device Control register. It states that the VF version of that register shall follow the setting of the corresponding PF. So we should enhance the cxgb4vf/sge.c:t4vf_sge_alloc_rxq() in the same way we did for the cxgb4 driver, but that's not critical since the Relaxed Ordering Enable supersedes the internal chip's desire to use the Relaxed Ordering Attribute. Ding, send me a note if you'd like me to work that up for you. | Also I thought most of the VF configuration space is read only. Yes, but not all of it. And when a VF is exported to a Virtual Machine, then the Hypervisor captures and interprets all accesses to the VF's PCIe Configuration Space from the VM. Thanks again for reminding me of the subtle aspect of the SR_IOV specification that I forgot. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-26 19:05 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-26 19:05 UTC (permalink / raw) To: linux-arm-kernel | From: Alexander Duyck <alexander.duyck@gmail.com> | Sent: Wednesday, July 26, 2017 11:44 AM | | On Jul 26, 2017 11:26 AM, "Casey Leedom" <leedom@chelsio.com> 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 Root Complex is marked | ? ? for no RO TLPs. | | I'm not sure that would be an issue. Wouldn't most VFs inherit the PF's settings? Ah yes, you're right. This is covered in section 3.5.4 of the Single Root I/O Virtualization and Sharing Specification, Revision 1.0 (September 11, 2007), governing the PCIe Capability Device Control register. It states that the VF version of that register shall follow the setting of the corresponding PF. So we should enhance the cxgb4vf/sge.c:t4vf_sge_alloc_rxq() in the same way we did for the cxgb4 driver, but that's not critical since the Relaxed Ordering Enable supersedes the internal chip's desire to use the Relaxed Ordering Attribute. Ding, send me a note if you'd like me to work that up for you. | Also I thought most of the VF configuration space is read only. Yes, but not all of it. And when a VF is exported to a Virtual Machine, then the Hypervisor captures and interprets all accesses to the VF's PCIe Configuration Space from the VM. Thanks again for reminding me of the subtle aspect of the SR_IOV specification that I forgot. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-26 19:05 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-26 19:05 UTC (permalink / raw) To: Alexander Duyck Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR, asit.k.mallick, jeffrey.t.kirsher, mark.rutland, gabriele.paoloni, Michael Werner, bhelgaas, patrick.j.cramer, Ding Tianhong, linuxarm, amira, Bob.Shaw | From: Alexander Duyck <alexander.duyck@gmail.com> | Sent: Wednesday, July 26, 2017 11:44 AM |=20 | On Jul 26, 2017 11:26 AM, "Casey Leedom" <leedom@chelsio.com> wrote: | | | | =A0 =A0 I think that the patch will need to be extended to modify | | =A0 =A0 drivers/pci.c/iov.c:sriov_enable() to explicitly turn off | | =A0 =A0 Relaxed Ordering Enable if the Root Complex is marked | =A0 =A0 for no RO TLPs. |=20 | I'm not sure that would be an issue. Wouldn't most VFs inherit the PF's s= ettings? Ah yes, you're right. This is covered in section 3.5.4 of the Single Root = I/O Virtualization and Sharing Specification, Revision 1.0 (September 11, 2007)= , governing the PCIe Capability Device Control register. It states that the = VF version of that register shall follow the setting of the corresponding PF. So we should enhance the cxgb4vf/sge.c:t4vf_sge_alloc_rxq() in the same way we did for the cxgb4 driver, but that's not critical since the Relaxed Ordering Enable supersedes the internal chip's desire to use the Relaxed Ordering Attribute. Ding, send me a note if you'd like me to work that up for you. | Also I thought most of the VF configuration space is read only. Yes, but not all of it. And when a VF is exported to a Virtual Machine, then the Hypervisor captures and interprets all accesses to the VF's PCIe Configuration Space from the VM. Thanks again for reminding me of the subtle aspect of the SR_IOV specification that I forgot. Casey= ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-26 19:05 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-26 19:05 UTC (permalink / raw) To: Alexander Duyck Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR | From: Alexander Duyck <alexander.duyck@gmail.com> | Sent: Wednesday, July 26, 2017 11:44 AM | | On Jul 26, 2017 11:26 AM, "Casey Leedom" <leedom@chelsio.com> 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 Root Complex is marked | for no RO TLPs. | | I'm not sure that would be an issue. Wouldn't most VFs inherit the PF's settings? Ah yes, you're right. This is covered in section 3.5.4 of the Single Root I/O Virtualization and Sharing Specification, Revision 1.0 (September 11, 2007), governing the PCIe Capability Device Control register. It states that the VF version of that register shall follow the setting of the corresponding PF. So we should enhance the cxgb4vf/sge.c:t4vf_sge_alloc_rxq() in the same way we did for the cxgb4 driver, but that's not critical since the Relaxed Ordering Enable supersedes the internal chip's desire to use the Relaxed Ordering Attribute. Ding, send me a note if you'd like me to work that up for you. | Also I thought most of the VF configuration space is read only. Yes, but not all of it. And when a VF is exported to a Virtual Machine, then the Hypervisor captures and interprets all accesses to the VF's PCIe Configuration Space from the VM. Thanks again for reminding me of the subtle aspect of the SR_IOV specification that I forgot. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-26 19:05 ` Casey Leedom (?) (?) @ 2017-07-27 1:01 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-27 1:01 UTC (permalink / raw) To: Casey Leedom, Alexander Duyck Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR, asit.k.mallick, jeffrey.t.kirsher, mark.rutland, gabriele.paoloni, Michael Werner, bhelgaas, patrick.j.cramer, linuxarm, amira, Bob.Shaw On 2017/7/27 3:05, Casey Leedom wrote: > | From: Alexander Duyck <alexander.duyck@gmail.com> > | Sent: Wednesday, July 26, 2017 11:44 AM > | > | On Jul 26, 2017 11:26 AM, "Casey Leedom" <leedom@chelsio.com> 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 Root Complex is marked > | for no RO TLPs. > | > | I'm not sure that would be an issue. Wouldn't most VFs inherit the PF's settings? > > Ah yes, you're right. This is covered in section 3.5.4 of the Single Root I/O > Virtualization and Sharing Specification, Revision 1.0 (September 11, 2007), > governing the PCIe Capability Device Control register. It states that the VF > version of that register shall follow the setting of the corresponding PF. > > So we should enhance the cxgb4vf/sge.c:t4vf_sge_alloc_rxq() in the same > way we did for the cxgb4 driver, but that's not critical since the Relaxed > Ordering Enable supersedes the internal chip's desire to use the Relaxed > Ordering Attribute. > > Ding, send me a note if you'd like me to work that up for you. > Ok, you could send the change log and I could put it in the v8 version together, will you base on the patch 3/3 or build a independence patch? Ding > | Also I thought most of the VF configuration space is read only. > > Yes, but not all of it. And when a VF is exported to a Virtual Machine, > then the Hypervisor captures and interprets all accesses to the VF's > PCIe Configuration Space from the VM. > > Thanks again for reminding me of the subtle aspect of the SR_IOV > specification that I forgot. > > Casey > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 1:01 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-27 1:01 UTC (permalink / raw) To: linux-arm-kernel On 2017/7/27 3:05, Casey Leedom wrote: > | From: Alexander Duyck <alexander.duyck@gmail.com> > | Sent: Wednesday, July 26, 2017 11:44 AM > | > | On Jul 26, 2017 11:26 AM, "Casey Leedom" <leedom@chelsio.com> 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 Root Complex is marked > | for no RO TLPs. > | > | I'm not sure that would be an issue. Wouldn't most VFs inherit the PF's settings? > > Ah yes, you're right. This is covered in section 3.5.4 of the Single Root I/O > Virtualization and Sharing Specification, Revision 1.0 (September 11, 2007), > governing the PCIe Capability Device Control register. It states that the VF > version of that register shall follow the setting of the corresponding PF. > > So we should enhance the cxgb4vf/sge.c:t4vf_sge_alloc_rxq() in the same > way we did for the cxgb4 driver, but that's not critical since the Relaxed > Ordering Enable supersedes the internal chip's desire to use the Relaxed > Ordering Attribute. > > Ding, send me a note if you'd like me to work that up for you. > Ok, you could send the change log and I could put it in the v8 version together, will you base on the patch 3/3 or build a independence patch? Ding > | Also I thought most of the VF configuration space is read only. > > Yes, but not all of it. And when a VF is exported to a Virtual Machine, > then the Hypervisor captures and interprets all accesses to the VF's > PCIe Configuration Space from the VM. > > Thanks again for reminding me of the subtle aspect of the SR_IOV > specification that I forgot. > > Casey > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 1:01 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-27 1:01 UTC (permalink / raw) To: Casey Leedom, Alexander Duyck Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR, asit.k.mallick, jeffrey.t.kirsher, mark.rutland, gabriele.paoloni, Michael Werner, bhelgaas, patrick.j.cramer, linuxarm, amira, Bob.Shaw On 2017/7/27 3:05, Casey Leedom wrote: > | From: Alexander Duyck <alexander.duyck@gmail.com> > | Sent: Wednesday, July 26, 2017 11:44 AM > | > | On Jul 26, 2017 11:26 AM, "Casey Leedom" <leedom@chelsio.com> 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 Root Complex is marked > | for no RO TLPs. > | > | I'm not sure that would be an issue. Wouldn't most VFs inherit the PF's settings? > > Ah yes, you're right. This is covered in section 3.5.4 of the Single Root I/O > Virtualization and Sharing Specification, Revision 1.0 (September 11, 2007), > governing the PCIe Capability Device Control register. It states that the VF > version of that register shall follow the setting of the corresponding PF. > > So we should enhance the cxgb4vf/sge.c:t4vf_sge_alloc_rxq() in the same > way we did for the cxgb4 driver, but that's not critical since the Relaxed > Ordering Enable supersedes the internal chip's desire to use the Relaxed > Ordering Attribute. > > Ding, send me a note if you'd like me to work that up for you. > Ok, you could send the change log and I could put it in the v8 version together, will you base on the patch 3/3 or build a independence patch? Ding > | Also I thought most of the VF configuration space is read only. > > Yes, but not all of it. And when a VF is exported to a Virtual Machine, > then the Hypervisor captures and interprets all accesses to the VF's > PCIe Configuration Space from the VM. > > Thanks again for reminding me of the subtle aspect of the SR_IOV > specification that I forgot. > > Casey > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 1:01 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-27 1:01 UTC (permalink / raw) To: Casey Leedom, Alexander Duyck Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR On 2017/7/27 3:05, Casey Leedom wrote: > | From: Alexander Duyck <alexander.duyck@gmail.com> > | Sent: Wednesday, July 26, 2017 11:44 AM > | > | On Jul 26, 2017 11:26 AM, "Casey Leedom" <leedom@chelsio.com> 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 Root Complex is marked > | for no RO TLPs. > | > | I'm not sure that would be an issue. Wouldn't most VFs inherit the PF's settings? > > Ah yes, you're right. This is covered in section 3.5.4 of the Single Root I/O > Virtualization and Sharing Specification, Revision 1.0 (September 11, 2007), > governing the PCIe Capability Device Control register. It states that the VF > version of that register shall follow the setting of the corresponding PF. > > So we should enhance the cxgb4vf/sge.c:t4vf_sge_alloc_rxq() in the same > way we did for the cxgb4 driver, but that's not critical since the Relaxed > Ordering Enable supersedes the internal chip's desire to use the Relaxed > Ordering Attribute. > > Ding, send me a note if you'd like me to work that up for you. > Ok, you could send the change log and I could put it in the v8 version together, will you base on the patch 3/3 or build a independence patch? Ding > | Also I thought most of the VF configuration space is read only. > > Yes, but not all of it. And when a VF is exported to a Virtual Machine, > then the Hypervisor captures and interprets all accesses to the VF's > PCIe Configuration Space from the VM. > > Thanks again for reminding me of the subtle aspect of the SR_IOV > specification that I forgot. > > Casey > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-27 1:01 ` Ding Tianhong (?) (?) @ 2017-07-27 17:44 ` Casey Leedom -1 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-27 17:44 UTC (permalink / raw) To: Ding Tianhong, Alexander Duyck Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR, asit.k.mallick, jeffrey.t.kirsher, mark.rutland, gabriele.paoloni, Michael Werner, bhelgaas, patrick.j.cramer, linuxarm, amira, Bob.Shaw, patrick.j.cramer | From: Ding Tianhong <dingtianhong@huawei.com> | 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 the patch 3/3 or build a independence patch? Which ever you'd prefer. It would basically mirror the same exact code that you've got for cxgb4. I.e. testing the setting of the VF's PCIe Capability Device Control[Relaxed Ordering Enable], setting a new flag in adpater->flags, testing that flag in cxgb4vf/sge.c:t4vf_sge_alloc_rxq(). But since the VF's PF will already have disabled the PF's Relaxed Ordering Enable, the VF will also have it's Relaxed Ordering Enable disabled and any effort by the internal chip to send TLPs with the Relaxed Ordering Attribute will be gated by the PCIe logic. So it's not critical that this be in the first patch. Your call. Let me know if you'd like me to send that to you. | From: Ding Tianhong <dingtianhong@huawei.com> | Sent: Wednesday, July 26, 2017 6:08 PM | | On 2017/7/27 2:26, Casey Leedom wrote: | > | > 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. | | Still no Intel and AMD guys has ack this, this is what I am worried about, | should I ping some man again ? By amusing coincidence, Patrik Cramer (now Cc'ed) from Intel sent me a note yesterday with a link to the official Intel performance tuning documentation which covers this issue: https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf In section 3.9.1 we have: 3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory and Toward MMIO Regions (P2P) In order to maximize performance for PCIe devices in the processors listed in Table 3-6 below, the soft- ware should determine whether the accesses are toward coherent memory (system memory) or toward MMIO regions (P2P access to other devices). If the access is toward MMIO region, then software can command HW to set the RO bit in the TLP header, as this would allow hardware to achieve maximum throughput for these types of accesses. For accesses toward coherent memory, software can command HW to clear the RO bit in the TLP header (no RO), as this would allow hardware to achieve maximum throughput for these types of accesses. Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing PCIe Performance Processor CPU RP Device IDs Intel Xeon processors based on 6F01H-6F0EH Broadwell microarchitecture Intel Xeon processors based on 2F01H-2F0EH Haswell microarchitecture Unfortunately that's a pretty thin section. But it does expand the set of Intel Root Complexes for which our Linux PCI Quirk will need to cover. So you should add those to the next (and hopefully final) spin of your patch. And, it also verifies the need to handle the use of Relaxed Ordering more subtlely than simply turning it off since the NVMe peer-to-peer example I keep bringing up would fall into the "need to use Relaxed Ordering" case ... It would have been nice to know why this is happening and if any future processor would fix this. After all, Relaxed Ordering, is just supposed to be a hint. At worst, a receiving device could just ignore the attribute entirely. Obviously someone made an effort to implement it but ... it didn't go the way they wanted. And, it also would have been nice to know if there was any hidden register in these Intel Root Complexes which can completely turn off the effort to pay attention to the Relaxed Ordering Attribute. We've spend an enormous amount of effort on this issue here on the Linux PCI email list struggling mightily to come up with a way to determine when it's safe/recommended/not-recommended/unsafe to use Relaxed Ordering when directing TLPs towards the Root Complex. And some architectures require RO for decent performance so we can't just "turn it off" unilatterally. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 17:44 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-27 17:44 UTC (permalink / raw) To: linux-arm-kernel | From: Ding Tianhong <dingtianhong@huawei.com> | 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 the patch 3/3 or build a independence patch? Which ever you'd prefer. It would basically mirror the same exact code that you've got for cxgb4. I.e. testing the setting of the VF's PCIe Capability Device Control[Relaxed Ordering Enable], setting a new flag in adpater->flags, testing that flag in cxgb4vf/sge.c:t4vf_sge_alloc_rxq(). But since the VF's PF will already have disabled the PF's Relaxed Ordering Enable, the VF will also have it's Relaxed Ordering Enable disabled and any effort by the internal chip to send TLPs with the Relaxed Ordering Attribute will be gated by the PCIe logic. So it's not critical that this be in the first patch. Your call. Let me know if you'd like me to send that to you. | From: Ding Tianhong <dingtianhong@huawei.com> | Sent: Wednesday, July 26, 2017 6:08 PM | | On 2017/7/27 2:26, Casey Leedom wrote: | > | > 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. | | Still no Intel and AMD guys has ack this, this is what I am worried about, | should I ping some man again ? By amusing coincidence, Patrik Cramer (now Cc'ed) from Intel sent me a note yesterday with a link to the official Intel performance tuning documentation which covers this issue: https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf In section 3.9.1 we have: 3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory and Toward MMIO Regions (P2P) In order to maximize performance for PCIe devices in the processors listed in Table 3-6 below, the soft- ware should determine whether the accesses are toward coherent memory (system memory) or toward MMIO regions (P2P access to other devices). If the access is toward MMIO region, then software can command HW to set the RO bit in the TLP header, as this would allow hardware to achieve maximum throughput for these types of accesses. For accesses toward coherent memory, software can command HW to clear the RO bit in the TLP header (no RO), as this would allow hardware to achieve maximum throughput for these types of accesses. Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing PCIe Performance Processor CPU RP Device IDs Intel Xeon processors based on 6F01H-6F0EH Broadwell microarchitecture Intel Xeon processors based on 2F01H-2F0EH Haswell microarchitecture Unfortunately that's a pretty thin section. But it does expand the set of Intel Root Complexes for which our Linux PCI Quirk will need to cover. So you should add those to the next (and hopefully final) spin of your patch. And, it also verifies the need to handle the use of Relaxed Ordering more subtlely than simply turning it off since the NVMe peer-to-peer example I keep bringing up would fall into the "need to use Relaxed Ordering" case ... It would have been nice to know why this is happening and if any future processor would fix this. After all, Relaxed Ordering, is just supposed to be a hint. At worst, a receiving device could just ignore the attribute entirely. Obviously someone made an effort to implement it but ... it didn't go the way they wanted. And, it also would have been nice to know if there was any hidden register in these Intel Root Complexes which can completely turn off the effort to pay attention to the Relaxed Ordering Attribute. We've spend an enormous amount of effort on this issue here on the Linux PCI email list struggling mightily to come up with a way to determine when it's safe/recommended/not-recommended/unsafe to use Relaxed Ordering when directing TLPs towards the Root Complex. And some architectures require RO for decent performance so we can't just "turn it off" unilatterally. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 17:44 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-27 17:44 UTC (permalink / raw) To: Ding Tianhong, Alexander Duyck Cc: mark.rutland, gabriele.paoloni, asit.k.mallick, linux-pci, will.deacon, linuxarm, Sinan Kaya, ashok.raj, Bjorn Helgaas, jeffrey.t.kirsher, catalin.marinas, Ganesh GR, Bob.Shaw, patrick.j.cramer, Alex Williamson, bhelgaas, Michael Werner, linux-arm-kernel, amira, Netdev, linux-kernel, David.Laight, Suravee.Suthikulpanit, robin.murphy, davem, l.stach | From: Ding Tianhong <dingtianhong@huawei.com> | 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 the patch 3/3 or build a independence patch? Which ever you'd prefer. It would basically mirror the same exact code that you've got for cxgb4. I.e. testing the setting of the VF's PCIe Capability Device Control[Relaxed Ordering Enable], setting a new flag in adpater->flags, testing that flag in cxgb4vf/sge.c:t4vf_sge_alloc_rxq(). But since the VF's PF will already have disabled the PF's Relaxed Ordering Enable, the VF will also have it's Relaxed Ordering Enable disabled and any effort by the internal chip to send TLPs with the Relaxed Ordering Attribute will be gated by the PCIe logic. So it's not critical that this be in the first patch. Your call. Let me know if you'd like me to send that to you. | From: Ding Tianhong <dingtianhong@huawei.com> | Sent: Wednesday, July 26, 2017 6:08 PM | | On 2017/7/27 2:26, Casey Leedom wrote: | > | > 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. | | Still no Intel and AMD guys has ack this, this is what I am worried about, | should I ping some man again ? By amusing coincidence, Patrik Cramer (now Cc'ed) from Intel sent me a note yesterday with a link to the official Intel performance tuning documentation which covers this issue: https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf In section 3.9.1 we have: 3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory and Toward MMIO Regions (P2P) In order to maximize performance for PCIe devices in the processors listed in Table 3-6 below, the soft- ware should determine whether the accesses are toward coherent memory (system memory) or toward MMIO regions (P2P access to other devices). If the access is toward MMIO region, then software can command HW to set the RO bit in the TLP header, as this would allow hardware to achieve maximum throughput for these types of accesses. For accesses toward coherent memory, software can command HW to clear the RO bit in the TLP header (no RO), as this would allow hardware to achieve maximum throughput for these types of accesses. Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing PCIe Performance Processor CPU RP Device IDs Intel Xeon processors based on 6F01H-6F0EH Broadwell microarchitecture Intel Xeon processors based on 2F01H-2F0EH Haswell microarchitecture Unfortunately that's a pretty thin section. But it does expand the set of Intel Root Complexes for which our Linux PCI Quirk will need to cover. So you should add those to the next (and hopefully final) spin of your patch. And, it also verifies the need to handle the use of Relaxed Ordering more subtlely than simply turning it off since the NVMe peer-to-peer example I keep bringing up would fall into the "need to use Relaxed Ordering" case ... It would have been nice to know why this is happening and if any future processor would fix this. After all, Relaxed Ordering, is just supposed to be a hint. At worst, a receiving device could just ignore the attribute entirely. Obviously someone made an effort to implement it but ... it didn't go the way they wanted. And, it also would have been nice to know if there was any hidden register in these Intel Root Complexes which can completely turn off the effort to pay attention to the Relaxed Ordering Attribute. We've spend an enormous amount of effort on this issue here on the Linux PCI email list struggling mightily to come up with a way to determine when it's safe/recommended/not-recommended/unsafe to use Relaxed Ordering when directing TLPs towards the Root Complex. And some architectures require RO for decent performance so we can't just "turn it off" unilatterally. Casey _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 17:44 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-27 17:44 UTC (permalink / raw) To: Ding Tianhong, Alexander Duyck Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR | From: Ding Tianhong <dingtianhong@huawei.com> | 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 the patch 3/3 or build a independence patch? Which ever you'd prefer. It would basically mirror the same exact code that you've got for cxgb4. I.e. testing the setting of the VF's PCIe Capability Device Control[Relaxed Ordering Enable], setting a new flag in adpater->flags, testing that flag in cxgb4vf/sge.c:t4vf_sge_alloc_rxq(). But since the VF's PF will already have disabled the PF's Relaxed Ordering Enable, the VF will also have it's Relaxed Ordering Enable disabled and any effort by the internal chip to send TLPs with the Relaxed Ordering Attribute will be gated by the PCIe logic. So it's not critical that this be in the first patch. Your call. Let me know if you'd like me to send that to you. | From: Ding Tianhong <dingtianhong@huawei.com> | Sent: Wednesday, July 26, 2017 6:08 PM | | On 2017/7/27 2:26, Casey Leedom wrote: | > | > 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. | | Still no Intel and AMD guys has ack this, this is what I am worried about, | should I ping some man again ? By amusing coincidence, Patrik Cramer (now Cc'ed) from Intel sent me a note yesterday with a link to the official Intel performance tuning documentation which covers this issue: https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf In section 3.9.1 we have: 3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory and Toward MMIO Regions (P2P) In order to maximize performance for PCIe devices in the processors listed in Table 3-6 below, the soft- ware should determine whether the accesses are toward coherent memory (system memory) or toward MMIO regions (P2P access to other devices). If the access is toward MMIO region, then software can command HW to set the RO bit in the TLP header, as this would allow hardware to achieve maximum throughput for these types of accesses. For accesses toward coherent memory, software can command HW to clear the RO bit in the TLP header (no RO), as this would allow hardware to achieve maximum throughput for these types of accesses. Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing PCIe Performance Processor CPU RP Device IDs Intel Xeon processors based on 6F01H-6F0EH Broadwell microarchitecture Intel Xeon processors based on 2F01H-2F0EH Haswell microarchitecture Unfortunately that's a pretty thin section. But it does expand the set of Intel Root Complexes for which our Linux PCI Quirk will need to cover. So you should add those to the next (and hopefully final) spin of your patch. And, it also verifies the need to handle the use of Relaxed Ordering more subtlely than simply turning it off since the NVMe peer-to-peer example I keep bringing up would fall into the "need to use Relaxed Ordering" case ... It would have been nice to know why this is happening and if any future processor would fix this. After all, Relaxed Ordering, is just supposed to be a hint. At worst, a receiving device could just ignore the attribute entirely. Obviously someone made an effort to implement it but ... it didn't go the way they wanted. And, it also would have been nice to know if there was any hidden register in these Intel Root Complexes which can completely turn off the effort to pay attention to the Relaxed Ordering Attribute. We've spend an enormous amount of effort on this issue here on the Linux PCI email list struggling mightily to come up with a way to determine when it's safe/recommended/not-recommended/unsafe to use Relaxed Ordering when directing TLPs towards the Root Complex. And some architectures require RO for decent performance so we can't just "turn it off" unilatterally. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-27 17:44 ` Casey Leedom (?) (?) @ 2017-07-27 18:42 ` Raj, Ashok -1 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-07-27 18:42 UTC (permalink / raw) To: Casey Leedom Cc: Ding Tianhong, Alexander Duyck, Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR, asit.k.mallick, jeffrey.t.kirsher, mark.rutland, gabriele.paoloni, Michael Werner, bhelgaas, patrick.j.cramer, linuxarm, amira, Bob.Shaw, ashok.raj 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 commit message wasn't easy to ready. Seems like this patch has gotten bigger than originally intended, but seems to be for the overall good :-). Sorry for staying silent up until now. Cheers, Ashok ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 18:42 ` Raj, Ashok 0 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-07-27 18:42 UTC (permalink / raw) To: linux-arm-kernel 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 commit message wasn't easy to ready. Seems like this patch has gotten bigger than originally intended, but seems to be for the overall good :-). Sorry for staying silent up until now. Cheers, Ashok ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 18:42 ` Raj, Ashok 0 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-07-27 18:42 UTC (permalink / raw) To: Casey Leedom Cc: Ding Tianhong, Alexander Duyck, Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR, asit.k.mallick, jeffrey.t.kirsher, mark.rutland, gabriele.paoloni, Michael Werner, bhelgaas, patrick.j.cramer, linuxarm, amira, Bob.Shaw, ashok.raj 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 commit message wasn't easy to ready. Seems like this patch has gotten bigger than originally intended, but seems to be for the overall good :-). Sorry for staying silent up until now. Cheers, Ashok ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 18:42 ` Raj, Ashok 0 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-07-27 18:42 UTC (permalink / raw) To: Casey Leedom Cc: Ding Tianhong, Alexander Duyck, Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, 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 commit message wasn't easy to ready. Seems like this patch has gotten bigger than originally intended, but seems to be for the overall good :-). Sorry for staying silent up until now. Cheers, Ashok ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-27 18:42 ` Raj, Ashok (?) (?) @ 2017-07-28 2:57 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 2:57 UTC (permalink / raw) To: Raj, Ashok, Casey Leedom Cc: Alexander Duyck, Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR, asit.k.mallick, jeffrey.t.kirsher, mark.rutland, gabriele.paoloni, Michael Werner, bhelgaas, patrick.j.cramer, linuxarm, amira, Bob.Shaw 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/Ding resend the patch series, i do have the most recent v7, some > of the commit message wasn't easy to ready. Seems like this patch has > gotten bigger than originally intended, but seems to be for the overall > good :-). > OK, I will send v8 patch set and which will update the patch title and add Casey's new modification for his vf driver, thanks. Ding > Sorry for staying silent up until now. > > Cheers, > Ashok > > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-28 2:57 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 2:57 UTC (permalink / raw) To: linux-arm-kernel 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/Ding resend the patch series, i do have the most recent v7, some > of the commit message wasn't easy to ready. Seems like this patch has > gotten bigger than originally intended, but seems to be for the overall > good :-). > OK, I will send v8 patch set and which will update the patch title and add Casey's new modification for his vf driver, thanks. Ding > Sorry for staying silent up until now. > > Cheers, > Ashok > > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-28 2:57 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 2:57 UTC (permalink / raw) To: Raj, Ashok, Casey Leedom Cc: mark.rutland, gabriele.paoloni, asit.k.mallick, linux-pci, will.deacon, linuxarm, Alexander Duyck, Sinan Kaya, amira, Bjorn Helgaas, jeffrey.t.kirsher, catalin.marinas, Ganesh GR, Bob.Shaw, patrick.j.cramer, Alex Williamson, bhelgaas, Michael Werner, linux-arm-kernel, Netdev, linux-kernel, David.Laight, Suravee.Suthikulpanit, robin.murphy, davem, l.stach 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/Ding resend the patch series, i do have the most recent v7, some > of the commit message wasn't easy to ready. Seems like this patch has > gotten bigger than originally intended, but seems to be for the overall > good :-). > OK, I will send v8 patch set and which will update the patch title and add Casey's new modification for his vf driver, thanks. Ding > Sorry for staying silent up until now. > > Cheers, > Ashok > > . > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-28 2:57 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 2:57 UTC (permalink / raw) To: Raj, Ashok, Casey Leedom Cc: Alexander Duyck, Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR 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/Ding resend the patch series, i do have the most recent v7, some > of the commit message wasn't easy to ready. Seems like this patch has > gotten bigger than originally intended, but seems to be for the overall > good :-). > OK, I will send v8 patch set and which will update the patch title and add Casey's new modification for his vf driver, thanks. Ding > Sorry for staying silent up until now. > > Cheers, > Ashok > > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-27 17:44 ` Casey Leedom (?) (?) @ 2017-07-28 2:48 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 2:48 UTC (permalink / raw) To: Casey Leedom, Alexander Duyck Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR, asit.k.mallick, jeffrey.t.kirsher, mark.rutland, gabriele.paoloni, Michael Werner, bhelgaas, patrick.j.cramer, linuxarm, amira, Bob.Shaw On 2017/7/28 1:44, Casey Leedom wrote: > | From: Ding Tianhong <dingtianhong@huawei.com> > | 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 the patch 3/3 or build a independence patch? > > Which ever you'd prefer. It would basically mirror the same exact code that > you've got for cxgb4. I.e. testing the setting of the VF's PCIe Capability > Device Control[Relaxed Ordering Enable], setting a new flag in > adpater->flags, testing that flag in cxgb4vf/sge.c:t4vf_sge_alloc_rxq(). > But since the VF's PF will already have disabled the PF's Relaxed Ordering > Enable, the VF will also have it's Relaxed Ordering Enable disabled and any > effort by the internal chip to send TLPs with the Relaxed Ordering Attribute > will be gated by the PCIe logic. So it's not critical that this be in the > first patch. Your call. Let me know if you'd like me to send that to you. > Good, please Send it to me, I will put it together and send the v8 this week, I think Bjorn will be back next week .:) > > | From: Ding Tianhong <dingtianhong@huawei.com> > | Sent: Wednesday, July 26, 2017 6:08 PM > | > | On 2017/7/27 2:26, Casey Leedom wrote: > | > > | > 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. > | > | Still no Intel and AMD guys has ack this, this is what I am worried about, > | should I ping some man again ? > > By amusing coincidence, Patrik Cramer (now Cc'ed) from Intel sent me a note > yesterday with a link to the official Intel performance tuning documentation > which covers this issue: > > https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf > > In section 3.9.1 we have: > > 3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory > and Toward MMIO Regions (P2P) > > In order to maximize performance for PCIe devices in the processors > listed in Table 3-6 below, the soft- ware should determine whether the > accesses are toward coherent memory (system memory) or toward MMIO > regions (P2P access to other devices). If the access is toward MMIO > region, then software can command HW to set the RO bit in the TLP > header, as this would allow hardware to achieve maximum throughput for > these types of accesses. For accesses toward coherent memory, software > can command HW to clear the RO bit in the TLP header (no RO), as this > would allow hardware to achieve maximum throughput for these types of > accesses. > > Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing > PCIe Performance > > Processor CPU RP Device IDs > > Intel Xeon processors based on 6F01H-6F0EH > Broadwell microarchitecture > > Intel Xeon processors based on 2F01H-2F0EH > Haswell microarchitecture > > Unfortunately that's a pretty thin section. But it does expand the set of > Intel Root Complexes for which our Linux PCI Quirk will need to cover. So > you should add those to the next (and hopefully final) spin of your patch. > And, it also verifies the need to handle the use of Relaxed Ordering more > subtlely than simply turning it off since the NVMe peer-to-peer example I > keep bringing up would fall into the "need to use Relaxed Ordering" case ... > > It would have been nice to know why this is happening and if any future > processor would fix this. After all, Relaxed Ordering, is just supposed to > be a hint. At worst, a receiving device could just ignore the attribute > entirely. Obviously someone made an effort to implement it but ... it > didn't go the way they wanted. > > And, it also would have been nice to know if there was any hidden register > in these Intel Root Complexes which can completely turn off the effort to > pay attention to the Relaxed Ordering Attribute. We've spend an enormous > amount of effort on this issue here on the Linux PCI email list struggling > mightily to come up with a way to determine when it's > safe/recommended/not-recommended/unsafe to use Relaxed Ordering when > directing TLPs towards the Root Complex. And some architectures require RO > for decent performance so we can't just "turn it off" unilatterally. > I am glad to hear that more person were focus on this problem, It would be great if they could enter our discussion and give us more suggestion. :) Thanks Ding > Casey > > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-28 2:48 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 2:48 UTC (permalink / raw) To: linux-arm-kernel On 2017/7/28 1:44, Casey Leedom wrote: > | From: Ding Tianhong <dingtianhong@huawei.com> > | 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 the patch 3/3 or build a independence patch? > > Which ever you'd prefer. It would basically mirror the same exact code that > you've got for cxgb4. I.e. testing the setting of the VF's PCIe Capability > Device Control[Relaxed Ordering Enable], setting a new flag in > adpater->flags, testing that flag in cxgb4vf/sge.c:t4vf_sge_alloc_rxq(). > But since the VF's PF will already have disabled the PF's Relaxed Ordering > Enable, the VF will also have it's Relaxed Ordering Enable disabled and any > effort by the internal chip to send TLPs with the Relaxed Ordering Attribute > will be gated by the PCIe logic. So it's not critical that this be in the > first patch. Your call. Let me know if you'd like me to send that to you. > Good? please Send it to me, I will put it together and send the v8 this week, I think Bjorn will be back next week .:) > > | From: Ding Tianhong <dingtianhong@huawei.com> > | Sent: Wednesday, July 26, 2017 6:08 PM > | > | On 2017/7/27 2:26, Casey Leedom wrote: > | > > | > 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. > | > | Still no Intel and AMD guys has ack this, this is what I am worried about, > | should I ping some man again ? > > By amusing coincidence, Patrik Cramer (now Cc'ed) from Intel sent me a note > yesterday with a link to the official Intel performance tuning documentation > which covers this issue: > > https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf > > In section 3.9.1 we have: > > 3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory > and Toward MMIO Regions (P2P) > > In order to maximize performance for PCIe devices in the processors > listed in Table 3-6 below, the soft- ware should determine whether the > accesses are toward coherent memory (system memory) or toward MMIO > regions (P2P access to other devices). If the access is toward MMIO > region, then software can command HW to set the RO bit in the TLP > header, as this would allow hardware to achieve maximum throughput for > these types of accesses. For accesses toward coherent memory, software > can command HW to clear the RO bit in the TLP header (no RO), as this > would allow hardware to achieve maximum throughput for these types of > accesses. > > Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing > PCIe Performance > > Processor CPU RP Device IDs > > Intel Xeon processors based on 6F01H-6F0EH > Broadwell microarchitecture > > Intel Xeon processors based on 2F01H-2F0EH > Haswell microarchitecture > > Unfortunately that's a pretty thin section. But it does expand the set of > Intel Root Complexes for which our Linux PCI Quirk will need to cover. So > you should add those to the next (and hopefully final) spin of your patch. > And, it also verifies the need to handle the use of Relaxed Ordering more > subtlely than simply turning it off since the NVMe peer-to-peer example I > keep bringing up would fall into the "need to use Relaxed Ordering" case ... > > It would have been nice to know why this is happening and if any future > processor would fix this. After all, Relaxed Ordering, is just supposed to > be a hint. At worst, a receiving device could just ignore the attribute > entirely. Obviously someone made an effort to implement it but ... it > didn't go the way they wanted. > > And, it also would have been nice to know if there was any hidden register > in these Intel Root Complexes which can completely turn off the effort to > pay attention to the Relaxed Ordering Attribute. We've spend an enormous > amount of effort on this issue here on the Linux PCI email list struggling > mightily to come up with a way to determine when it's > safe/recommended/not-recommended/unsafe to use Relaxed Ordering when > directing TLPs towards the Root Complex. And some architectures require RO > for decent performance so we can't just "turn it off" unilatterally. > I am glad to hear that more person were focus on this problem, It would be great if they could enter our discussion and give us more suggestion. :) Thanks Ding > Casey > > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-28 2:48 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 2:48 UTC (permalink / raw) To: Casey Leedom, Alexander Duyck Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR, asit.k.mallick, jeffrey.t.kirsher, mark.rutland, gabriele.paoloni, Michael Werner, bhelgaas, patrick.j.cramer, linuxarm, amira, Bob.Shaw On 2017/7/28 1:44, Casey Leedom wrote: > | From: Ding Tianhong <dingtianhong@huawei.com> > | 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 the patch 3/3 or build a independence patch? > > Which ever you'd prefer. It would basically mirror the same exact code that > you've got for cxgb4. I.e. testing the setting of the VF's PCIe Capability > Device Control[Relaxed Ordering Enable], setting a new flag in > adpater->flags, testing that flag in cxgb4vf/sge.c:t4vf_sge_alloc_rxq(). > But since the VF's PF will already have disabled the PF's Relaxed Ordering > Enable, the VF will also have it's Relaxed Ordering Enable disabled and any > effort by the internal chip to send TLPs with the Relaxed Ordering Attribute > will be gated by the PCIe logic. So it's not critical that this be in the > first patch. Your call. Let me know if you'd like me to send that to you. > Good, please Send it to me, I will put it together and send the v8 this week, I think Bjorn will be back next week .:) > > | From: Ding Tianhong <dingtianhong@huawei.com> > | Sent: Wednesday, July 26, 2017 6:08 PM > | > | On 2017/7/27 2:26, Casey Leedom wrote: > | > > | > 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. > | > | Still no Intel and AMD guys has ack this, this is what I am worried about, > | should I ping some man again ? > > By amusing coincidence, Patrik Cramer (now Cc'ed) from Intel sent me a note > yesterday with a link to the official Intel performance tuning documentation > which covers this issue: > > https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf > > In section 3.9.1 we have: > > 3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory > and Toward MMIO Regions (P2P) > > In order to maximize performance for PCIe devices in the processors > listed in Table 3-6 below, the soft- ware should determine whether the > accesses are toward coherent memory (system memory) or toward MMIO > regions (P2P access to other devices). If the access is toward MMIO > region, then software can command HW to set the RO bit in the TLP > header, as this would allow hardware to achieve maximum throughput for > these types of accesses. For accesses toward coherent memory, software > can command HW to clear the RO bit in the TLP header (no RO), as this > would allow hardware to achieve maximum throughput for these types of > accesses. > > Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing > PCIe Performance > > Processor CPU RP Device IDs > > Intel Xeon processors based on 6F01H-6F0EH > Broadwell microarchitecture > > Intel Xeon processors based on 2F01H-2F0EH > Haswell microarchitecture > > Unfortunately that's a pretty thin section. But it does expand the set of > Intel Root Complexes for which our Linux PCI Quirk will need to cover. So > you should add those to the next (and hopefully final) spin of your patch. > And, it also verifies the need to handle the use of Relaxed Ordering more > subtlely than simply turning it off since the NVMe peer-to-peer example I > keep bringing up would fall into the "need to use Relaxed Ordering" case ... > > It would have been nice to know why this is happening and if any future > processor would fix this. After all, Relaxed Ordering, is just supposed to > be a hint. At worst, a receiving device could just ignore the attribute > entirely. Obviously someone made an effort to implement it but ... it > didn't go the way they wanted. > > And, it also would have been nice to know if there was any hidden register > in these Intel Root Complexes which can completely turn off the effort to > pay attention to the Relaxed Ordering Attribute. We've spend an enormous > amount of effort on this issue here on the Linux PCI email list struggling > mightily to come up with a way to determine when it's > safe/recommended/not-recommended/unsafe to use Relaxed Ordering when > directing TLPs towards the Root Complex. And some architectures require RO > for decent performance so we can't just "turn it off" unilatterally. > I am glad to hear that more person were focus on this problem, It would be great if they could enter our discussion and give us more suggestion. :) Thanks Ding > Casey > > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-28 2:48 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 2:48 UTC (permalink / raw) To: Casey Leedom, Alexander Duyck Cc: Netdev, Bjorn Helgaas, linux-arm-kernel, David.Laight, ashok.raj, Alex Williamson, l.stach, Suravee.Suthikulpanit, catalin.marinas, linux-pci, will.deacon, Sinan Kaya, robin.murphy, linux-kernel, davem, Ganesh GR On 2017/7/28 1:44, Casey Leedom wrote: > | From: Ding Tianhong <dingtianhong@huawei.com> > | 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 the patch 3/3 or build a independence patch? > > Which ever you'd prefer. It would basically mirror the same exact code that > you've got for cxgb4. I.e. testing the setting of the VF's PCIe Capability > Device Control[Relaxed Ordering Enable], setting a new flag in > adpater->flags, testing that flag in cxgb4vf/sge.c:t4vf_sge_alloc_rxq(). > But since the VF's PF will already have disabled the PF's Relaxed Ordering > Enable, the VF will also have it's Relaxed Ordering Enable disabled and any > effort by the internal chip to send TLPs with the Relaxed Ordering Attribute > will be gated by the PCIe logic. So it's not critical that this be in the > first patch. Your call. Let me know if you'd like me to send that to you. > Good, please Send it to me, I will put it together and send the v8 this week, I think Bjorn will be back next week .:) > > | From: Ding Tianhong <dingtianhong@huawei.com> > | Sent: Wednesday, July 26, 2017 6:08 PM > | > | On 2017/7/27 2:26, Casey Leedom wrote: > | > > | > 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. > | > | Still no Intel and AMD guys has ack this, this is what I am worried about, > | should I ping some man again ? > > By amusing coincidence, Patrik Cramer (now Cc'ed) from Intel sent me a note > yesterday with a link to the official Intel performance tuning documentation > which covers this issue: > > https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf > > In section 3.9.1 we have: > > 3.9.1 Optimizing PCIe Performance for Accesses Toward Coherent Memory > and Toward MMIO Regions (P2P) > > In order to maximize performance for PCIe devices in the processors > listed in Table 3-6 below, the soft- ware should determine whether the > accesses are toward coherent memory (system memory) or toward MMIO > regions (P2P access to other devices). If the access is toward MMIO > region, then software can command HW to set the RO bit in the TLP > header, as this would allow hardware to achieve maximum throughput for > these types of accesses. For accesses toward coherent memory, software > can command HW to clear the RO bit in the TLP header (no RO), as this > would allow hardware to achieve maximum throughput for these types of > accesses. > > Table 3-6. Intel Processor CPU RP Device IDs for Processors Optimizing > PCIe Performance > > Processor CPU RP Device IDs > > Intel Xeon processors based on 6F01H-6F0EH > Broadwell microarchitecture > > Intel Xeon processors based on 2F01H-2F0EH > Haswell microarchitecture > > Unfortunately that's a pretty thin section. But it does expand the set of > Intel Root Complexes for which our Linux PCI Quirk will need to cover. So > you should add those to the next (and hopefully final) spin of your patch. > And, it also verifies the need to handle the use of Relaxed Ordering more > subtlely than simply turning it off since the NVMe peer-to-peer example I > keep bringing up would fall into the "need to use Relaxed Ordering" case ... > > It would have been nice to know why this is happening and if any future > processor would fix this. After all, Relaxed Ordering, is just supposed to > be a hint. At worst, a receiving device could just ignore the attribute > entirely. Obviously someone made an effort to implement it but ... it > didn't go the way they wanted. > > And, it also would have been nice to know if there was any hidden register > in these Intel Root Complexes which can completely turn off the effort to > pay attention to the Relaxed Ordering Attribute. We've spend an enormous > amount of effort on this issue here on the Linux PCI email list struggling > mightily to come up with a way to determine when it's > safe/recommended/not-recommended/unsafe to use Relaxed Ordering when > directing TLPs towards the Root Complex. And some architectures require RO > for decent performance so we can't just "turn it off" unilatterally. > I am glad to hear that more person were focus on this problem, It would be great if they could enter our discussion and give us more suggestion. :) Thanks Ding > Casey > > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-26 18:26 ` Casey Leedom (?) (?) @ 2017-07-27 1:08 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-27 1:08 UTC (permalink / raw) To: Casey Leedom, Alex Williamson Cc: Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm 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 > products. > Still no Intel and AMD guys has ack this, this is what I am worried about, should I ping some man again ? Thanks Ding > > Casey > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 1:08 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-27 1:08 UTC (permalink / raw) To: linux-arm-kernel 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 > products. > Still no Intel and AMD guys has ack this, this is what I am worried about, should I ping some man again ? Thanks Ding > > Casey > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 1:08 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-27 1:08 UTC (permalink / raw) To: Casey Leedom, Alex Williamson Cc: Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm 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 > products. > Still no Intel and AMD guys has ack this, this is what I am worried about, should I ping some man again ? Thanks Ding > > Casey > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 1:08 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-27 1:08 UTC (permalink / raw) To: Casey Leedom, Alex Williamson Cc: mark.rutland, gabriele.paoloni, asit.k.mallick, catalin.marinas, will.deacon, linuxarm, alexander.duyck, Sinan Kaya, ashok.raj, helgaas, jeffrey.t.kirsher, linux-pci, Ganesh GR, Bob.Shaw, patrick.j.cramer, bhelgaas, Michael Werner, linux-arm-kernel@lists.infradead.org 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 > products. > Still no Intel and AMD guys has ack this, this is what I am worried about, should I ping some man again ? Thanks Ding > > Casey > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-27 1:08 ` Ding Tianhong (?) (?) @ 2017-07-27 17:49 ` Alexander Duyck -1 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-27 17:49 UTC (permalink / raw) To: Ding Tianhong Cc: Casey Leedom, Alex Williamson, Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong <dingtianhong@huawei.com> 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 since the PCI Quirks that we're putting in affect their >> products. >> > > Still no Intel and AMD guys has ack this, this is what I am worried about, should I > ping some man again ? > > Thanks > Ding I probably wouldn't worry about it too much. If anything all this patch is doing is disabling relaxed ordering on the platforms we know have issues based on what Casey originally had. If nothing else we can follow up once the patches are in the kernel and if somebody has an issue then. You can include my acked-by, but it is mostly related to how this interacts with NICs, and not so much about the PCI chipsets themselves. Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 17:49 ` Alexander Duyck 0 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-27 17:49 UTC (permalink / raw) To: linux-arm-kernel On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong <dingtianhong@huawei.com> 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 since the PCI Quirks that we're putting in affect their >> products. >> > > Still no Intel and AMD guys has ack this, this is what I am worried about, should I > ping some man again ? > > Thanks > Ding I probably wouldn't worry about it too much. If anything all this patch is doing is disabling relaxed ordering on the platforms we know have issues based on what Casey originally had. If nothing else we can follow up once the patches are in the kernel and if somebody has an issue then. You can include my acked-by, but it is mostly related to how this interacts with NICs, and not so much about the PCI chipsets themselves. Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 17:49 ` Alexander Duyck 0 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-27 17:49 UTC (permalink / raw) To: Ding Tianhong Cc: Casey Leedom, Alex Williamson, Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong <dingtianhong@huawei.com> 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 since the PCI Quirks that we're putting in affect their >> products. >> > > Still no Intel and AMD guys has ack this, this is what I am worried about, should I > ping some man again ? > > Thanks > Ding I probably wouldn't worry about it too much. If anything all this patch is doing is disabling relaxed ordering on the platforms we know have issues based on what Casey originally had. If nothing else we can follow up once the patches are in the kernel and if somebody has an issue then. You can include my acked-by, but it is mostly related to how this interacts with NICs, and not so much about the PCI chipsets themselves. Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-27 17:49 ` Alexander Duyck 0 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-27 17:49 UTC (permalink / raw) To: Ding Tianhong Cc: Casey Leedom, Alex Williamson, Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong <dingtianhong@huawei.com> 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 since the PCI Quirks that we're putting in affect their >> products. >> > > Still no Intel and AMD guys has ack this, this is what I am worried about, should I > ping some man again ? > > Thanks > Ding I probably wouldn't worry about it too much. If anything all this patch is doing is disabling relaxed ordering on the platforms we know have issues based on what Casey originally had. If nothing else we can follow up once the patches are in the kernel and if somebody has an issue then. You can include my acked-by, but it is mostly related to how this interacts with NICs, and not so much about the PCI chipsets themselves. Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-27 17:49 ` Alexander Duyck (?) (?) @ 2017-07-28 3:00 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 3:00 UTC (permalink / raw) To: Alexander Duyck Cc: Casey Leedom, Alex Williamson, Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm On 2017/7/28 1:49, Alexander Duyck wrote: > On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong <dingtianhong@huawei.com> 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 since the PCI Quirks that we're putting in affect their >>> products. >>> >> >> Still no Intel and AMD guys has ack this, this is what I am worried about, should I >> ping some man again ? >> >> Thanks >> Ding > > > I probably wouldn't worry about it too much. If anything all this > patch is doing is disabling relaxed ordering on the platforms we know > have issues based on what Casey originally had. If nothing else we can > follow up once the patches are in the kernel and if somebody has an > issue then. > > You can include my acked-by, but it is mostly related to how this > interacts with NICs, and not so much about the PCI chipsets > themselves. > > Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> > Thanks, Alex. :) > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-28 3:00 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 3:00 UTC (permalink / raw) To: linux-arm-kernel On 2017/7/28 1:49, Alexander Duyck wrote: > On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong <dingtianhong@huawei.com> 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 since the PCI Quirks that we're putting in affect their >>> products. >>> >> >> Still no Intel and AMD guys has ack this, this is what I am worried about, should I >> ping some man again ? >> >> Thanks >> Ding > > > I probably wouldn't worry about it too much. If anything all this > patch is doing is disabling relaxed ordering on the platforms we know > have issues based on what Casey originally had. If nothing else we can > follow up once the patches are in the kernel and if somebody has an > issue then. > > You can include my acked-by, but it is mostly related to how this > interacts with NICs, and not so much about the PCI chipsets > themselves. > > Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> > Thanks, Alex. :) > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-28 3:00 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 3:00 UTC (permalink / raw) To: Alexander Duyck Cc: Casey Leedom, Alex Williamson, Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm On 2017/7/28 1:49, Alexander Duyck wrote: > On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong <dingtianhong@huawei.com> 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 since the PCI Quirks that we're putting in affect their >>> products. >>> >> >> Still no Intel and AMD guys has ack this, this is what I am worried about, should I >> ping some man again ? >> >> Thanks >> Ding > > > I probably wouldn't worry about it too much. If anything all this > patch is doing is disabling relaxed ordering on the platforms we know > have issues based on what Casey originally had. If nothing else we can > follow up once the patches are in the kernel and if somebody has an > issue then. > > You can include my acked-by, but it is mostly related to how this > interacts with NICs, and not so much about the PCI chipsets > themselves. > > Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> > Thanks, Alex. :) > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-07-28 3:00 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-28 3:00 UTC (permalink / raw) To: Alexander Duyck Cc: mark.rutland, gabriele.paoloni, asit.k.mallick, catalin.marinas, will.deacon, linuxarm, Sinan Kaya, ashok.raj, helgaas, jeffrey.t.kirsher, linux-pci, Ganesh GR, Bob.Shaw, Casey Leedom, patrick.j.cramer, Alex Williamson, bhelgaas, Michael Werner, linux-arm-kernel@lists.infradead.org On 2017/7/28 1:49, Alexander Duyck wrote: > On Wed, Jul 26, 2017 at 6:08 PM, Ding Tianhong <dingtianhong@huawei.com> 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 since the PCI Quirks that we're putting in affect their >>> products. >>> >> >> Still no Intel and AMD guys has ack this, this is what I am worried about, should I >> ping some man again ? >> >> Thanks >> Ding > > > I probably wouldn't worry about it too much. If anything all this > patch is doing is disabling relaxed ordering on the platforms we know > have issues based on what Casey originally had. If nothing else we can > follow up once the patches are in the kernel and if somebody has an > issue then. > > You can include my acked-by, but it is mostly related to how this > interacts with NICs, and not so much about the PCI chipsets > themselves. > > Acked-by: Alexander Duyck <alexander.h.duyck@intel.com> > Thanks, Alex. :) > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-28 3:00 ` Ding Tianhong (?) (?) @ 2017-08-02 17:53 ` Casey Leedom -1 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-02 17:53 UTC (permalink / raw) To: Ding Tianhong, Alexander Duyck Cc: Alex Williamson, Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm 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 Machine along with an NVMe device which can deal with Relaxed Ordering TLPs, the VF driver in the VM will be able to tell that it shouldn't attempt to send RO TLPs to the RC because it will see the state of its own PCIe Capability Device Control[Relaxed Ordering Enable] (a copy of the setting in the VF's corresponding PF), but it won't be able to change that and send non-RO TLPs to the RC, and RO TLPs to the NVMe device. Oh well. I sure wish that the Intel guys would pop up with a hidden register change for these problematic Intel RCs that perform poorly with RO TLPs. Their silence has been frustrating. Casey ---------- cxgb4vf Ethernet driver now queries PCIe configuration space to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h index 109bc63..08c6ddb 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h +++ b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h @@ -408,6 +408,7 @@ enum { /* adapter flags */ USING_MSI = (1UL << 1), USING_MSIX = (1UL << 2), QUEUES_BOUND = (1UL << 3), + ROOT_NO_RELAXED_ORDERING = (1UL << 4), }; /* diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c index ac7a150..59e7639 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c +++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c @@ -2888,6 +2888,24 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev, */ adapter->name = pci_name(pdev); adapter->msg_enable = DFLT_MSG_ENABLE; + + /* If possible, we use PCIe Relaxed Ordering Attribute to deliver + * Ingress Packet Data to Free List Buffers in order to allow for + * chipset performance optimizations between the Root Complex and + * Memory Controllers. (Messages to the associated Ingress Queue + * notifying new Packet Placement in the Free Lists Buffers will be + * send without the Relaxed Ordering Attribute thus guaranteeing that + * all preceding PCIe Transaction Layer Packets will be processed + * first.) But some Root Complexes have various issues with Upstream + * Transaction Layer Packets with the Relaxed Ordering Attribute set. + * The PCIe devices which under the Root Complexes will be cleared the + * Relaxed Ordering bit in the configuration space, So we check our + * PCIe configuration space to see if it's flagged with advice against + * using Relaxed Ordering. + */ + if (!pcie_relaxed_ordering_supported(pdev)) + adapter->flags |= ROOT_NO_RELAXED_ORDERING; + err = adap_init0(adapter); if (err) goto err_unmap_bar; diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c index e37dde2..05498e7 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c +++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c @@ -2205,6 +2205,7 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct sge_rspq *rspq, struct port_info *pi = netdev_priv(dev); struct fw_iq_cmd cmd, rpl; int ret, iqandst, flsz = 0; + int relaxed = !(adapter->flags & ROOT_NO_RELAXED_ORDERING); /* * If we're using MSI interrupts and we're not initializing the @@ -2300,6 +2301,8 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct sge_rspq *rspq, cpu_to_be32( FW_IQ_CMD_FL0HOSTFCMODE_V(SGE_HOSTFCMODE_NONE) | FW_IQ_CMD_FL0PACKEN_F | + FW_IQ_CMD_FL0FETCHRO_V(relaxed) | + FW_IQ_CMD_FL0DATARO_V(relaxed) | FW_IQ_CMD_FL0PADEN_F); /* In T6, for egress queue type FL there is internal overhead ^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-02 17:53 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-02 17:53 UTC (permalink / raw) To: linux-arm-kernel ? 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 Machine along with an NVMe device which can deal with Relaxed Ordering TLPs, the VF driver in the VM will be able to tell that it shouldn't attempt to send RO TLPs to the RC because it will see the state of its own PCIe Capability Device Control[Relaxed Ordering Enable] (a copy of the setting in the VF's corresponding PF), but it won't be able to change that and send non-RO TLPs to the RC, and RO TLPs to the NVMe device.? Oh well. ? I sure wish that the Intel guys would pop up with a hidden register change for these problematic Intel RCs that perform poorly with RO TLPs.? Their silence has been frustrating. Casey ---------- cxgb4vf Ethernet driver now queries PCIe configuration space to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h index 109bc63..08c6ddb 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h +++ b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h @@ -408,6 +408,7 @@ enum { /* adapter flags */ USING_MSI = (1UL << 1), USING_MSIX = (1UL << 2), QUEUES_BOUND = (1UL << 3), + ROOT_NO_RELAXED_ORDERING = (1UL << 4), }; /* diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c index ac7a150..59e7639 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c +++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c @@ -2888,6 +2888,24 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev, */ adapter->name = pci_name(pdev); adapter->msg_enable = DFLT_MSG_ENABLE; + + /* If possible, we use PCIe Relaxed Ordering Attribute to deliver + * Ingress Packet Data to Free List Buffers in order to allow for + * chipset performance optimizations between the Root Complex and + * Memory Controllers. (Messages to the associated Ingress Queue + * notifying new Packet Placement in the Free Lists Buffers will be + * send without the Relaxed Ordering Attribute thus guaranteeing that + * all preceding PCIe Transaction Layer Packets will be processed + * first.) But some Root Complexes have various issues with Upstream + * Transaction Layer Packets with the Relaxed Ordering Attribute set. + * The PCIe devices which under the Root Complexes will be cleared the + * Relaxed Ordering bit in the configuration space, So we check our + * PCIe configuration space to see if it's flagged with advice against + * using Relaxed Ordering. + */ + if (!pcie_relaxed_ordering_supported(pdev)) + adapter->flags |= ROOT_NO_RELAXED_ORDERING; + err = adap_init0(adapter); if (err) goto err_unmap_bar; diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c index e37dde2..05498e7 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c +++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c @@ -2205,6 +2205,7 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct sge_rspq *rspq, struct port_info *pi = netdev_priv(dev); struct fw_iq_cmd cmd, rpl; int ret, iqandst, flsz = 0; + int relaxed = !(adapter->flags & ROOT_NO_RELAXED_ORDERING); /* * If we're using MSI interrupts and we're not initializing the @@ -2300,6 +2301,8 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct sge_rspq *rspq, cpu_to_be32( FW_IQ_CMD_FL0HOSTFCMODE_V(SGE_HOSTFCMODE_NONE) | FW_IQ_CMD_FL0PACKEN_F | + FW_IQ_CMD_FL0FETCHRO_V(relaxed) | + FW_IQ_CMD_FL0DATARO_V(relaxed) | FW_IQ_CMD_FL0PADEN_F); /* In T6, for egress queue type FL there is internal overhead ^ permalink raw reply related [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-02 17:53 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-02 17:53 UTC (permalink / raw) To: Ding Tianhong, Alexander Duyck Cc: mark.rutland, gabriele.paoloni, asit.k.mallick, catalin.marinas, will.deacon, linuxarm, Sinan Kaya, ashok.raj, helgaas, jeffrey.t.kirsher, linux-pci, Ganesh GR, Bob.Shaw, patrick.j.cramer, Alex Williamson, bhelgaas, Michael Werner, linux-arm-kernel, amira, netdev, linux-kernel, David.Laight, Suravee.Suthikulpanit, robin.murphy, davem, l.stach =A0 Okay, here you go.=A0 As you can tell, it's almost a trivial copy of the cxgb4 patch. =A0 =A0 By the way, I realized that we have yet another hole which is likely not to be fixable.=A0 If we're dealing with a problematic Root Complex, and we instantiate Virtual Functions and attach them to a Virtual Machine along with an NVMe device which can deal with Relaxed Ordering TLPs, the VF driver in the VM will be able to tell that it shouldn't attempt to send RO TLPs to the RC because it will see the state of its own PCIe Capability Device Control[Relaxed Ordering Enable] (a copy of the setting in the VF's corresponding PF), but it won't be able to change that and send non-RO TLPs to the RC, and RO TLPs to the NVMe device.=A0 Oh well. =A0 I sure wish that the Intel guys would pop up with a hidden register cha= nge for these problematic Intel RCs that perform poorly with RO TLPs.=A0 Their silence has been frustrating. Casey ---------- cxgb4vf Ethernet driver now queries PCIe configuration space to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h b/drivers/net/e= thernet/chelsio/cxgb4vf/adapter.h index 109bc63..08c6ddb 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h +++ b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h @@ -408,6 +408,7 @@ enum { /* adapter flags */ USING_MSI =3D (1UL << 1), USING_MSIX =3D (1UL << 2), QUEUES_BOUND =3D (1UL << 3), + ROOT_NO_RELAXED_ORDERING =3D (1UL << 4), }; = /* diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/= net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c index ac7a150..59e7639 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c +++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c @@ -2888,6 +2888,24 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev, */ adapter->name =3D pci_name(pdev); adapter->msg_enable =3D DFLT_MSG_ENABLE; + + /* If possible, we use PCIe Relaxed Ordering Attribute to deliver + * Ingress Packet Data to Free List Buffers in order to allow for + * chipset performance optimizations between the Root Complex and + * Memory Controllers. (Messages to the associated Ingress Queue + * notifying new Packet Placement in the Free Lists Buffers will be + * send without the Relaxed Ordering Attribute thus guaranteeing that + * all preceding PCIe Transaction Layer Packets will be processed + * first.) But some Root Complexes have various issues with Upstream + * Transaction Layer Packets with the Relaxed Ordering Attribute set. + * The PCIe devices which under the Root Complexes will be cleared the + * Relaxed Ordering bit in the configuration space, So we check our + * PCIe configuration space to see if it's flagged with advice against + * using Relaxed Ordering. + */ + if (!pcie_relaxed_ordering_supported(pdev)) + adapter->flags |=3D ROOT_NO_RELAXED_ORDERING; + err =3D adap_init0(adapter); if (err) goto err_unmap_bar; diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c b/drivers/net/ether= net/chelsio/cxgb4vf/sge.c index e37dde2..05498e7 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c +++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c @@ -2205,6 +2205,7 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struc= t sge_rspq *rspq, struct port_info *pi =3D netdev_priv(dev); struct fw_iq_cmd cmd, rpl; int ret, iqandst, flsz =3D 0; + int relaxed =3D !(adapter->flags & ROOT_NO_RELAXED_ORDERING); = /* * If we're using MSI interrupts and we're not initializing the @@ -2300,6 +2301,8 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struc= t sge_rspq *rspq, cpu_to_be32( FW_IQ_CMD_FL0HOSTFCMODE_V(SGE_HOSTFCMODE_NONE) | FW_IQ_CMD_FL0PACKEN_F | + FW_IQ_CMD_FL0FETCHRO_V(relaxed) | + FW_IQ_CMD_FL0DATARO_V(relaxed) | FW_IQ_CMD_FL0PADEN_F); = /* In T6, for egress queue type FL there is internal overhead _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-02 17:53 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-02 17:53 UTC (permalink / raw) To: Ding Tianhong, Alexander Duyck Cc: Alex Williamson, Sinan Kaya, ashok.raj, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher 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 Machine along with an NVMe device which can deal with Relaxed Ordering TLPs, the VF driver in the VM will be able to tell that it shouldn't attempt to send RO TLPs to the RC because it will see the state of its own PCIe Capability Device Control[Relaxed Ordering Enable] (a copy of the setting in the VF's corresponding PF), but it won't be able to change that and send non-RO TLPs to the RC, and RO TLPs to the NVMe device. Oh well. I sure wish that the Intel guys would pop up with a hidden register change for these problematic Intel RCs that perform poorly with RO TLPs. Their silence has been frustrating. Casey ---------- cxgb4vf Ethernet driver now queries PCIe configuration space to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h index 109bc63..08c6ddb 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h +++ b/drivers/net/ethernet/chelsio/cxgb4vf/adapter.h @@ -408,6 +408,7 @@ enum { /* adapter flags */ USING_MSI = (1UL << 1), USING_MSIX = (1UL << 2), QUEUES_BOUND = (1UL << 3), + ROOT_NO_RELAXED_ORDERING = (1UL << 4), }; /* diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c index ac7a150..59e7639 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c +++ b/drivers/net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c @@ -2888,6 +2888,24 @@ static int cxgb4vf_pci_probe(struct pci_dev *pdev, */ adapter->name = pci_name(pdev); adapter->msg_enable = DFLT_MSG_ENABLE; + + /* If possible, we use PCIe Relaxed Ordering Attribute to deliver + * Ingress Packet Data to Free List Buffers in order to allow for + * chipset performance optimizations between the Root Complex and + * Memory Controllers. (Messages to the associated Ingress Queue + * notifying new Packet Placement in the Free Lists Buffers will be + * send without the Relaxed Ordering Attribute thus guaranteeing that + * all preceding PCIe Transaction Layer Packets will be processed + * first.) But some Root Complexes have various issues with Upstream + * Transaction Layer Packets with the Relaxed Ordering Attribute set. + * The PCIe devices which under the Root Complexes will be cleared the + * Relaxed Ordering bit in the configuration space, So we check our + * PCIe configuration space to see if it's flagged with advice against + * using Relaxed Ordering. + */ + if (!pcie_relaxed_ordering_supported(pdev)) + adapter->flags |= ROOT_NO_RELAXED_ORDERING; + err = adap_init0(adapter); if (err) goto err_unmap_bar; diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c index e37dde2..05498e7 100644 --- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c +++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c @@ -2205,6 +2205,7 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct sge_rspq *rspq, struct port_info *pi = netdev_priv(dev); struct fw_iq_cmd cmd, rpl; int ret, iqandst, flsz = 0; + int relaxed = !(adapter->flags & ROOT_NO_RELAXED_ORDERING); /* * If we're using MSI interrupts and we're not initializing the @@ -2300,6 +2301,8 @@ int t4vf_sge_alloc_rxq(struct adapter *adapter, struct sge_rspq *rspq, cpu_to_be32( FW_IQ_CMD_FL0HOSTFCMODE_V(SGE_HOSTFCMODE_NONE) | FW_IQ_CMD_FL0PACKEN_F | + FW_IQ_CMD_FL0FETCHRO_V(relaxed) | + FW_IQ_CMD_FL0DATARO_V(relaxed) | FW_IQ_CMD_FL0PADEN_F); /* In T6, for egress queue type FL there is internal overhead ^ permalink raw reply related [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-08-02 17:53 ` Casey Leedom (?) (?) @ 2017-08-03 8:31 ` Raj, Ashok -1 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-03 8:31 UTC (permalink / raw) To: Casey Leedom Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm, ashok.raj Hi Casey On Wed, Aug 02, 2017 at 05:53:52PM +0000, 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 Root Complex, and we > instantiate Virtual Functions and attach them to a Virtual Machine along > with an NVMe device which can deal with Relaxed Ordering TLPs, the VF driver > in the VM will be able to tell that it shouldn't attempt to send RO TLPs to > the RC because it will see the state of its own PCIe Capability Device > Control[Relaxed Ordering Enable] (a copy of the setting in the VF's > corresponding PF), but it won't be able to change that and send non-RO TLPs > to the RC, and RO TLPs to the NVMe device. Oh well. 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? The issue in the current patchset is that we device to turn off the device capability for all devices in the hierarchy so one would expect that the NVMe also would have RO turned off i suppose. The other approach is to not turn off the device capabilty, but let the driver do the right thing. i.e for transactions towards system memory vs. peer-2-peer? But since we wanted to take a big hammer approach because some platforms there can be data-corruption and we can't let trust guest drivers to do the right thing. This isn't something we can fix in this current version. One possible approach is to provide a strict flag, where we use this heavy hammer approach only on platforms that have a serious implication, and the other is we let the driver do the right thing depending on the platform. Worst case if the driver doesn't do the right thing, you would see perf issues but nothing bad would happen. It would allow you to select when to turn on RO and when to turn it off. Cheers, Ashok ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-03 8:31 ` Raj, Ashok 0 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-03 8:31 UTC (permalink / raw) To: linux-arm-kernel Hi Casey On Wed, Aug 02, 2017 at 05:53:52PM +0000, 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 Root Complex, and we > instantiate Virtual Functions and attach them to a Virtual Machine along > with an NVMe device which can deal with Relaxed Ordering TLPs, the VF driver > in the VM will be able to tell that it shouldn't attempt to send RO TLPs to > the RC because it will see the state of its own PCIe Capability Device > Control[Relaxed Ordering Enable] (a copy of the setting in the VF's > corresponding PF), but it won't be able to change that and send non-RO TLPs > to the RC, and RO TLPs to the NVMe device.? Oh well. 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? The issue in the current patchset is that we device to turn off the device capability for all devices in the hierarchy so one would expect that the NVMe also would have RO turned off i suppose. The other approach is to not turn off the device capabilty, but let the driver do the right thing. i.e for transactions towards system memory vs. peer-2-peer? But since we wanted to take a big hammer approach because some platforms there can be data-corruption and we can't let trust guest drivers to do the right thing. This isn't something we can fix in this current version. One possible approach is to provide a strict flag, where we use this heavy hammer approach only on platforms that have a serious implication, and the other is we let the driver do the right thing depending on the platform. Worst case if the driver doesn't do the right thing, you would see perf issues but nothing bad would happen. It would allow you to select when to turn on RO and when to turn it off. Cheers, Ashok ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-03 8:31 ` Raj, Ashok 0 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-03 8:31 UTC (permalink / raw) To: Casey Leedom Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm, ashok.raj Hi Casey On Wed, Aug 02, 2017 at 05:53:52PM +0000, 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 Root Complex, and we > instantiate Virtual Functions and attach them to a Virtual Machine along > with an NVMe device which can deal with Relaxed Ordering TLPs, the VF driver > in the VM will be able to tell that it shouldn't attempt to send RO TLPs to > the RC because it will see the state of its own PCIe Capability Device > Control[Relaxed Ordering Enable] (a copy of the setting in the VF's > corresponding PF), but it won't be able to change that and send non-RO TLPs > to the RC, and RO TLPs to the NVMe device. Oh well. 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? The issue in the current patchset is that we device to turn off the device capability for all devices in the hierarchy so one would expect that the NVMe also would have RO turned off i suppose. The other approach is to not turn off the device capabilty, but let the driver do the right thing. i.e for transactions towards system memory vs. peer-2-peer? But since we wanted to take a big hammer approach because some platforms there can be data-corruption and we can't let trust guest drivers to do the right thing. This isn't something we can fix in this current version. One possible approach is to provide a strict flag, where we use this heavy hammer approach only on platforms that have a serious implication, and the other is we let the driver do the right thing depending on the platform. Worst case if the driver doesn't do the right thing, you would see perf issues but nothing bad would happen. It would allow you to select when to turn on RO and when to turn it off. Cheers, Ashok ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-03 8:31 ` Raj, Ashok 0 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-03 8:31 UTC (permalink / raw) To: Casey Leedom Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, Hi Casey On Wed, Aug 02, 2017 at 05:53:52PM +0000, 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 Root Complex, and we > instantiate Virtual Functions and attach them to a Virtual Machine along > with an NVMe device which can deal with Relaxed Ordering TLPs, the VF driver > in the VM will be able to tell that it shouldn't attempt to send RO TLPs to > the RC because it will see the state of its own PCIe Capability Device > Control[Relaxed Ordering Enable] (a copy of the setting in the VF's > corresponding PF), but it won't be able to change that and send non-RO TLPs > to the RC, and RO TLPs to the NVMe device. Oh well. 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? The issue in the current patchset is that we device to turn off the device capability for all devices in the hierarchy so one would expect that the NVMe also would have RO turned off i suppose. The other approach is to not turn off the device capabilty, but let the driver do the right thing. i.e for transactions towards system memory vs. peer-2-peer? But since we wanted to take a big hammer approach because some platforms there can be data-corruption and we can't let trust guest drivers to do the right thing. This isn't something we can fix in this current version. One possible approach is to provide a strict flag, where we use this heavy hammer approach only on platforms that have a serious implication, and the other is we let the driver do the right thing depending on the platform. Worst case if the driver doesn't do the right thing, you would see perf issues but nothing bad would happen. It would allow you to select when to turn on RO and when to turn it off. Cheers, Ashok ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-08-03 8:31 ` Raj, Ashok (?) (?) @ 2017-08-04 20:20 ` Casey Leedom -1 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-04 20:20 UTC (permalink / raw) To: Raj, Ashok Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm | From: Raj, Ashok <ashok.raj@intel.com> | 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 you alluded to later. There are applications where a device will want to send TLPs to a Root Complex without Relaxed Ordering set, but will want to use it when sending TLPs to a Peer device (say, an NVMe storage device). The current approach doesn't make that easy ... and in fact, I still don't kow how to code a solution for this with the proposed APIs. This means that we may be trading off one performance problem for another and that Relaxed Ordering may be doomed for use under Linux for the foreseeable future. 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 current generation of Root Complexes had left the ability to turn off the logic which is obviously not working. If there was a way to disable the logic via an undocumented register, then we could have the Linux PCI Quirk do that. Since Relaxed Ordering is just a hint, it's completely legitimate to completely ignore it. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-04 20:20 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-04 20:20 UTC (permalink / raw) To: linux-arm-kernel | From: Raj, Ashok <ashok.raj@intel.com> | 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 you alluded to later. There are applications where a device will want to send TLPs to a Root Complex without Relaxed Ordering set, but will want to use it when sending TLPs to a Peer device (say, an NVMe storage device). The current approach doesn't make that easy ... and in fact, I still don't kow how to code a solution for this with the proposed APIs. This means that we may be trading off one performance problem for another and that Relaxed Ordering may be doomed for use under Linux for the foreseeable future. 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 current generation of Root Complexes had left the ability to turn off the logic which is obviously not working. If there was a way to disable the logic via an undocumented register, then we could have the Linux PCI Quirk do that. Since Relaxed Ordering is just a hint, it's completely legitimate to completely ignore it. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-04 20:20 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-04 20:20 UTC (permalink / raw) To: Raj, Ashok Cc: mark.rutland, gabriele.paoloni, asit.k.mallick, catalin.marinas, will.deacon, linuxarm, Alexander Duyck, Sinan Kaya, amira, helgaas, jeffrey.t.kirsher, Ding Tianhong, Ganesh GR, Bob.Shaw, patrick.j.cramer, Alex Williamson, bhelgaas, Michael Werner, linux-arm-kernel, linux-pci, netdev, linux-kernel, David.Laight, Suravee.Suthikulpanit, robin.murphy, davem, l.stach | From: Raj, Ashok <ashok.raj@intel.com> | 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 you alluded to later. There are applications where a device will want to send TLPs to a Root Complex without Relaxed Ordering set, but will want to use it when sending TLPs to a Peer device (say, an NVMe storage device). The current approach doesn't make that easy ... and in fact, I still don't kow how to code a solution for this with the proposed APIs. This means that we may be trading off one performance problem for another and that Relaxed Ordering may be doomed for use under Linux for the foreseeable future. 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 current generation of Root Complexes had left the ability to turn off the logic which is obviously not working. If there was a way to disable the logic via an undocumented register, then we could have the Linux PCI Quirk do that. Since Relaxed Ordering is just a hint, it's completely legitimate to completely ignore it. Casey _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-04 20:20 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-04 20:20 UTC (permalink / raw) To: Raj, Ashok Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, | From: Raj, Ashok <ashok.raj@intel.com> | 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 you alluded to later. There are applications where a device will want to send TLPs to a Root Complex without Relaxed Ordering set, but will want to use it when sending TLPs to a Peer device (say, an NVMe storage device). The current approach doesn't make that easy ... and in fact, I still don't kow how to code a solution for this with the proposed APIs. This means that we may be trading off one performance problem for another and that Relaxed Ordering may be doomed for use under Linux for the foreseeable future. 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 current generation of Root Complexes had left the ability to turn off the logic which is obviously not working. If there was a way to disable the logic via an undocumented register, then we could have the Linux PCI Quirk do that. Since Relaxed Ordering is just a hint, it's completely legitimate to completely ignore it. Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-08-04 20:20 ` Casey Leedom (?) (?) @ 2017-08-04 20:21 ` Raj, Ashok -1 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-04 20:21 UTC (permalink / raw) To: Casey Leedom Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm, ashok.raj On Fri, Aug 04, 2017 at 08:20:37PM +0000, Casey Leedom wrote: > | From: Raj, Ashok <ashok.raj@intel.com> > | 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 you alluded to later. There are > applications where a device will want to send TLPs to a Root Complex without > Relaxed Ordering set, but will want to use it when sending TLPs to a Peer > device (say, an NVMe storage device). The current approach doesn't make > that easy ... and in fact, I still don't kow how to code a solution for this > with the proposed APIs. This means that we may be trading off one > performance problem for another and that Relaxed Ordering may be doomed for > use under Linux for the foreseeable future. > > 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 > current generation of Root Complexes had left the ability to turn off the > logic which is obviously not working. If there was a way to disable the > logic via an undocumented register, then we could have the Linux PCI Quirk > do that. Since Relaxed Ordering is just a hint, it's completely legitimate > to completely ignore it. Suppose you are looking for the existence of a chicken bit to instruct the port to ignore RO traffic. So all we would do is turn the chicken bit on but would permit p2p traffic to be allowed since we won't turn off the capability as currently proposed. Let me look into that keep you posted. Cheers, Ashok > > Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-04 20:21 ` Raj, Ashok 0 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-04 20:21 UTC (permalink / raw) To: linux-arm-kernel On Fri, Aug 04, 2017 at 08:20:37PM +0000, Casey Leedom wrote: > | From: Raj, Ashok <ashok.raj@intel.com> > | 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 you alluded to later. There are > applications where a device will want to send TLPs to a Root Complex without > Relaxed Ordering set, but will want to use it when sending TLPs to a Peer > device (say, an NVMe storage device). The current approach doesn't make > that easy ... and in fact, I still don't kow how to code a solution for this > with the proposed APIs. This means that we may be trading off one > performance problem for another and that Relaxed Ordering may be doomed for > use under Linux for the foreseeable future. > > 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 > current generation of Root Complexes had left the ability to turn off the > logic which is obviously not working. If there was a way to disable the > logic via an undocumented register, then we could have the Linux PCI Quirk > do that. Since Relaxed Ordering is just a hint, it's completely legitimate > to completely ignore it. Suppose you are looking for the existence of a chicken bit to instruct the port to ignore RO traffic. So all we would do is turn the chicken bit on but would permit p2p traffic to be allowed since we won't turn off the capability as currently proposed. Let me look into that keep you posted. Cheers, Ashok > > Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-04 20:21 ` Raj, Ashok 0 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-04 20:21 UTC (permalink / raw) To: Casey Leedom Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm, ashok.raj On Fri, Aug 04, 2017 at 08:20:37PM +0000, Casey Leedom wrote: > | From: Raj, Ashok <ashok.raj@intel.com> > | 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 you alluded to later. There are > applications where a device will want to send TLPs to a Root Complex without > Relaxed Ordering set, but will want to use it when sending TLPs to a Peer > device (say, an NVMe storage device). The current approach doesn't make > that easy ... and in fact, I still don't kow how to code a solution for this > with the proposed APIs. This means that we may be trading off one > performance problem for another and that Relaxed Ordering may be doomed for > use under Linux for the foreseeable future. > > 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 > current generation of Root Complexes had left the ability to turn off the > logic which is obviously not working. If there was a way to disable the > logic via an undocumented register, then we could have the Linux PCI Quirk > do that. Since Relaxed Ordering is just a hint, it's completely legitimate > to completely ignore it. Suppose you are looking for the existence of a chicken bit to instruct the port to ignore RO traffic. So all we would do is turn the chicken bit on but would permit p2p traffic to be allowed since we won't turn off the capability as currently proposed. Let me look into that keep you posted. Cheers, Ashok > > Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-04 20:21 ` Raj, Ashok 0 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-04 20:21 UTC (permalink / raw) To: Casey Leedom Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, On Fri, Aug 04, 2017 at 08:20:37PM +0000, Casey Leedom wrote: > | From: Raj, Ashok <ashok.raj@intel.com> > | 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 you alluded to later. There are > applications where a device will want to send TLPs to a Root Complex without > Relaxed Ordering set, but will want to use it when sending TLPs to a Peer > device (say, an NVMe storage device). The current approach doesn't make > that easy ... and in fact, I still don't kow how to code a solution for this > with the proposed APIs. This means that we may be trading off one > performance problem for another and that Relaxed Ordering may be doomed for > use under Linux for the foreseeable future. > > 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 > current generation of Root Complexes had left the ability to turn off the > logic which is obviously not working. If there was a way to disable the > logic via an undocumented register, then we could have the Linux PCI Quirk > do that. Since Relaxed Ordering is just a hint, it's completely legitimate > to completely ignore it. Suppose you are looking for the existence of a chicken bit to instruct the port to ignore RO traffic. So all we would do is turn the chicken bit on but would permit p2p traffic to be allowed since we won't turn off the capability as currently proposed. Let me look into that keep you posted. Cheers, Ashok > > Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-08-04 20:21 ` Raj, Ashok (?) (?) @ 2017-08-04 20:48 ` Casey Leedom -1 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-04 20:48 UTC (permalink / raw) To: Raj, Ashok Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm | From: Raj, Ashok <ashok.raj@intel.com> | Sent: Friday, August 4, 2017 1:21 PM | | On Fri, Aug 04, 2017 at 08:20:37PM +0000, 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 | > current generation of Root Complexes had left the ability to turn off the | > logic which is obviously not working. If there was a way to disable the | > logic via an undocumented register, then we could have the Linux PCI Quirk | > do that. Since Relaxed Ordering is just a hint, it's completely legitimate | > to completely ignore it. | | Suppose you are looking for the existence of a chicken bit to instruct the | port to ignore RO traffic. So all we would do is turn the chicken bit on | but would permit p2p traffic to be allowed since we won't turn off the | capability as currently proposed. | | Let me look into that keep you posted. Huh, I'd never heard it called a "chicken bit" before, but yes, that's what I'm talking about. 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 if necessary. This stems from the incredibly long Design -> Deployment cyle for Hardware (as opposed to the edit->compile->run cycle for s! It's obvious that handling Relaxed Ordering is a new Hardware Feature for Intel's Root Complexes since previous versions simply ignored it (because that's legal[1]). If I was a Hardware Engineer tasked with implementing Relaxed Ordering semantics for a device, I would certainly have also implemented a switch to turn it off in case there were unintended consequences (performance in this case). And if there is such a mechanism to simply disable processing of Relaxed Ordering semantics in the Root Complex, that would be a far easier "fix" for this problem ... and leave the code in place to continue sending Relaxed Ordering TLPs for a future Root Complex implementation which got it right ... Casey [1] One can't ~quite~ just ignore the Relaxed Ordering Attribute on an incoming Transaction Layer Packet Request: PCIe completion rules (see section 2.2.9 of the PCIe 3.0 specificatin) require that the Relaxed Ordering and No Snoop Attributes in a Request TLP be reflected back verbatim in any corresponding Response TLP. (The rules for ID-Based Ordering are more complex.) ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-04 20:48 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-04 20:48 UTC (permalink / raw) To: linux-arm-kernel | From: Raj, Ashok <ashok.raj@intel.com> | Sent: Friday, August 4, 2017 1:21 PM | | On Fri, Aug 04, 2017 at 08:20:37PM +0000, 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 | > current generation of Root Complexes had left the ability to turn off the | > logic which is obviously not working. If there was a way to disable the | > logic via an undocumented register, then we could have the Linux PCI Quirk | > do that. Since Relaxed Ordering is just a hint, it's completely legitimate | > to completely ignore it. | | Suppose you are looking for the existence of a chicken bit to instruct the | port to ignore RO traffic. So all we would do is turn the chicken bit on | but would permit p2p traffic to be allowed since we won't turn off the | capability as currently proposed. | | Let me look into that keep you posted. Huh, I'd never heard it called a "chicken bit" before, but yes, that's what I'm talking about. 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 if necessary. This stems from the incredibly long Design -> Deployment cyle for Hardware (as opposed to the edit->compile->run cycle for s! It's obvious that handling Relaxed Ordering is a new Hardware Feature for Intel's Root Complexes since previous versions simply ignored it (because that's legal[1]). If I was a Hardware Engineer tasked with implementing Relaxed Ordering semantics for a device, I would certainly have also implemented a switch to turn it off in case there were unintended consequences (performance in this case). And if there is such a mechanism to simply disable processing of Relaxed Ordering semantics in the Root Complex, that would be a far easier "fix" for this problem ... and leave the code in place to continue sending Relaxed Ordering TLPs for a future Root Complex implementation which got it right ... Casey [1] One can't ~quite~ just ignore the Relaxed Ordering Attribute on an incoming Transaction Layer Packet Request: PCIe completion rules (see section 2.2.9 of the PCIe 3.0 specificatin) require that the Relaxed Ordering and No Snoop Attributes in a Request TLP be reflected back verbatim in any corresponding Response TLP. (The rules for ID-Based Ordering are more complex.) ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-04 20:48 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-04 20:48 UTC (permalink / raw) To: Raj, Ashok Cc: mark.rutland, gabriele.paoloni, asit.k.mallick, catalin.marinas, will.deacon, linuxarm, Alexander Duyck, Sinan Kaya, amira, helgaas, jeffrey.t.kirsher, Ding Tianhong, Ganesh GR, Bob.Shaw, patrick.j.cramer, Alex Williamson, bhelgaas, Michael Werner, linux-arm-kernel, linux-pci, netdev, linux-kernel, David.Laight, Suravee.Suthikulpanit, robin.murphy, davem, l.stach | From: Raj, Ashok <ashok.raj@intel.com> | Sent: Friday, August 4, 2017 1:21 PM | | On Fri, Aug 04, 2017 at 08:20:37PM +0000, 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 | > current generation of Root Complexes had left the ability to turn off the | > logic which is obviously not working. If there was a way to disable the | > logic via an undocumented register, then we could have the Linux PCI Quirk | > do that. Since Relaxed Ordering is just a hint, it's completely legitimate | > to completely ignore it. | | Suppose you are looking for the existence of a chicken bit to instruct the | port to ignore RO traffic. So all we would do is turn the chicken bit on | but would permit p2p traffic to be allowed since we won't turn off the | capability as currently proposed. | | Let me look into that keep you posted. Huh, I'd never heard it called a "chicken bit" before, but yes, that's what I'm talking about. 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 if necessary. This stems from the incredibly long Design -> Deployment cyle for Hardware (as opposed to the edit->compile->run cycle for s! It's obvious that handling Relaxed Ordering is a new Hardware Feature for Intel's Root Complexes since previous versions simply ignored it (because that's legal[1]). If I was a Hardware Engineer tasked with implementing Relaxed Ordering semantics for a device, I would certainly have also implemented a switch to turn it off in case there were unintended consequences (performance in this case). And if there is such a mechanism to simply disable processing of Relaxed Ordering semantics in the Root Complex, that would be a far easier "fix" for this problem ... and leave the code in place to continue sending Relaxed Ordering TLPs for a future Root Complex implementation which got it right ... Casey [1] One can't ~quite~ just ignore the Relaxed Ordering Attribute on an incoming Transaction Layer Packet Request: PCIe completion rules (see section 2.2.9 of the PCIe 3.0 specificatin) require that the Relaxed Ordering and No Snoop Attributes in a Request TLP be reflected back verbatim in any corresponding Response TLP. (The rules for ID-Based Ordering are more complex.) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-04 20:48 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-08-04 20:48 UTC (permalink / raw) To: Raj, Ashok Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, | From: Raj, Ashok <ashok.raj@intel.com> | Sent: Friday, August 4, 2017 1:21 PM | | On Fri, Aug 04, 2017 at 08:20:37PM +0000, 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 | > current generation of Root Complexes had left the ability to turn off the | > logic which is obviously not working. If there was a way to disable the | > logic via an undocumented register, then we could have the Linux PCI Quirk | > do that. Since Relaxed Ordering is just a hint, it's completely legitimate | > to completely ignore it. | | Suppose you are looking for the existence of a chicken bit to instruct the | port to ignore RO traffic. So all we would do is turn the chicken bit on | but would permit p2p traffic to be allowed since we won't turn off the | capability as currently proposed. | | Let me look into that keep you posted. Huh, I'd never heard it called a "chicken bit" before, but yes, that's what I'm talking about. 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 if necessary. This stems from the incredibly long Design -> Deployment cyle for Hardware (as opposed to the edit->compile->run cycle for s! It's obvious that handling Relaxed Ordering is a new Hardware Feature for Intel's Root Complexes since previous versions simply ignored it (because that's legal[1]). If I was a Hardware Engineer tasked with implementing Relaxed Ordering semantics for a device, I would certainly have also implemented a switch to turn it off in case there were unintended consequences (performance in this case). And if there is such a mechanism to simply disable processing of Relaxed Ordering semantics in the Root Complex, that would be a far easier "fix" for this problem ... and leave the code in place to continue sending Relaxed Ordering TLPs for a future Root Complex implementation which got it right ... Casey [1] One can't ~quite~ just ignore the Relaxed Ordering Attribute on an incoming Transaction Layer Packet Request: PCIe completion rules (see section 2.2.9 of the PCIe 3.0 specificatin) require that the Relaxed Ordering and No Snoop Attributes in a Request TLP be reflected back verbatim in any corresponding Response TLP. (The rules for ID-Based Ordering are more complex.) ^ permalink raw reply [flat|nested] 114+ messages in thread
* RE: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-08-04 20:48 ` Casey Leedom (?) (?) @ 2017-08-07 9:04 ` David Laight -1 siblings, 0 replies; 114+ messages in thread From: David Laight @ 2017-08-07 9:04 UTC (permalink / raw) To: 'Casey Leedom', Raj, Ashok Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm 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 if necessary. This stems from the incredibly long Design -> > Deployment cyle for Hardware (as opposed to the edit->compile->run cycle for s! Indeed, I'd also expect there to be an undocumented flag to turn it on (broken) in earlier parts to allow testing. David ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-07 9:04 ` David Laight 0 siblings, 0 replies; 114+ messages in thread From: David Laight @ 2017-08-07 9:04 UTC (permalink / raw) To: linux-arm-kernel 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 if necessary. This stems from the incredibly long Design -> > Deployment cyle for Hardware (as opposed to the edit->compile->run cycle for s! Indeed, I'd also expect there to be an undocumented flag to turn it on (broken) in earlier parts to allow testing. David ^ permalink raw reply [flat|nested] 114+ messages in thread
* RE: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-07 9:04 ` David Laight 0 siblings, 0 replies; 114+ messages in thread From: David Laight @ 2017-08-07 9:04 UTC (permalink / raw) To: 'Casey Leedom', Raj, Ashok Cc: mark.rutland, gabriele.paoloni, asit.k.mallick, catalin.marinas, will.deacon, linuxarm, Alexander Duyck, Sinan Kaya, amira, helgaas, jeffrey.t.kirsher, Ding Tianhong, Ganesh GR, Bob.Shaw, patrick.j.cramer, Alex Williamson, bhelgaas, Michael Werner, linux-arm-kernel, linux-pci, netdev, linux-kernel, Suravee.Suthikulpanit, robin.murphy, davem, l.stach 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 if necessary. This stems from the incredibly long Design -> > Deployment cyle for Hardware (as opposed to the edit->compile->run cycle for s! Indeed, I'd also expect there to be an undocumented flag to turn it on (broken) in earlier parts to allow testing. David _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 114+ messages in thread
* RE: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-07 9:04 ` David Laight 0 siblings, 0 replies; 114+ messages in thread From: David Laight @ 2017-08-07 9:04 UTC (permalink / raw) To: 'Casey Leedom', Raj, Ashok Cc: Ding Tianhong, Alexander Duyck, Alex Williamson, Sinan Kaya, bhelgaas, helgaas, Michael Werner, Ganesh GR, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, jeffrey.t.kirsher, 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 if necessary. This stems from the incredibly long Design -> > Deployment cyle for Hardware (as opposed to the edit->compile->run cycle for s! Indeed, I'd also expect there to be an undocumented flag to turn it on (broken) in earlier parts to allow testing. David ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-07-13 14:21 ` Ding Tianhong @ 2017-08-03 9:13 ` Raj, Ashok -1 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-03 9:13 UTC (permalink / raw) To: Ding Tianhong Cc: leedom, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm, ashok.raj 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 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 by default. > > If a PCIe device didn't enable the relaxed ordering attribute default, > we should not do anything in the PCIe configuration, otherwise we > should check if any of the devices above us do not support relaxed > ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on > the result if we get a return that indicate that the relaxed ordering > is not supported we should update our device to disable relaxed ordering > in configuration space. If the device above us doesn't exist or isn't > the PCIe device, we shouldn't do anything and skip updating relaxed ordering > because we are probably running in a guest machine. When bit4 is set in the PCIe Device Control register, it indicates whether the device is permitted to use relaxed ordering. On some platforms using relaxed ordering can have performance issues or due to erratum can cause data-corruption. In such cases devices must avoid using relaxed ordering. This patch checks if there is any node in the hierarchy that indicates that using relaxed ordering is not safe. In such cases the patch turns off the relaxed ordering by clearing the eapability for this device. > > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> > --- > drivers/pci/pci.c | 29 +++++++++++++++++++++++++++++ > drivers/pci/probe.c | 37 +++++++++++++++++++++++++++++++++++++ > include/linux/pci.h | 2 ++ > 3 files changed, 68 insertions(+) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index d88edf5..7a6b32f 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -4854,6 +4854,35 @@ int pcie_set_mps(struct pci_dev *dev, int mps) > EXPORT_SYMBOL(pcie_set_mps); > > /** > + * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit > + * @dev: PCI device to query > + * > + * If possible clear relaxed ordering > + */ > +int pcie_clear_relaxed_ordering(struct pci_dev *dev) > +{ > + return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, > + PCI_EXP_DEVCTL_RELAX_EN); > +} > +EXPORT_SYMBOL(pcie_clear_relaxed_ordering); > + > +/** > + * pcie_relaxed_ordering_supported - Probe for PCIe relexed ordering support > + * @dev: PCI device to query > + * > + * Returns true if the device support relaxed ordering attribute. > + */ > +bool pcie_relaxed_ordering_supported(struct pci_dev *dev) > +{ > + u16 v; > + > + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v); > + > + return !!(v & PCI_EXP_DEVCTL_RELAX_EN); > +} > +EXPORT_SYMBOL(pcie_relaxed_ordering_supported); > + > +/** > * pcie_get_minimum_link - determine minimum link settings of a PCI device > * @dev: PCI device to query > * @speed: storage for minimum speed > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index c31310d..48df012 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -1762,6 +1762,42 @@ static void pci_configure_extended_tags(struct pci_dev *dev) > PCI_EXP_DEVCTL_EXT_TAG); > } > > +/** > + * pci_dev_should_disable_relaxed_ordering - check if the PCI device > + * should disable the relaxed ordering attribute. > + * @dev: PCI device > + * > + * Return true if any of the PCI devices above us do not support > + * relaxed ordering. > + */ > +static bool pci_dev_should_disable_relaxed_ordering(struct pci_dev *dev) > +{ > + while (dev) { > + if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) > + return true; > + > + dev = dev->bus->self; > + } > + > + return false; > +} > + > +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, do nothing. */ > + if (!pcie_relaxed_ordering_supported(dev)) > + return; > + > + if (pci_dev_should_disable_relaxed_ordering(dev)) { > + pcie_clear_relaxed_ordering(dev); > + dev_info(&dev->dev, "Disable Relaxed Ordering\n"); > + } > +} > + > static void pci_configure_device(struct pci_dev *dev) > { > struct hotplug_params hpp; > @@ -1769,6 +1805,7 @@ static void pci_configure_device(struct pci_dev *dev) > > pci_configure_mps(dev); > pci_configure_extended_tags(dev); > + pci_configure_relaxed_ordering(dev); > > memset(&hpp, 0, sizeof(hpp)); > ret = pci_get_hp_params(dev, &hpp); > diff --git a/include/linux/pci.h b/include/linux/pci.h > index 412ec1c..3aa23a2 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -1127,6 +1127,8 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev, > void pci_pme_wakeup_bus(struct pci_bus *bus); > void pci_d3cold_enable(struct pci_dev *dev); > void pci_d3cold_disable(struct pci_dev *dev); > +int pcie_clear_relaxed_ordering(struct pci_dev *dev); > +bool pcie_relaxed_ordering_supported(struct pci_dev *dev); > > /* PCI Virtual Channel */ > int pci_save_vc_state(struct pci_dev *dev); > -- > 1.8.3.1 > > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-03 9:13 ` Raj, Ashok 0 siblings, 0 replies; 114+ messages in thread From: Raj, Ashok @ 2017-08-03 9:13 UTC (permalink / raw) To: linux-arm-kernel 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 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 by default. > > If a PCIe device didn't enable the relaxed ordering attribute default, > we should not do anything in the PCIe configuration, otherwise we > should check if any of the devices above us do not support relaxed > ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on > the result if we get a return that indicate that the relaxed ordering > is not supported we should update our device to disable relaxed ordering > in configuration space. If the device above us doesn't exist or isn't > the PCIe device, we shouldn't do anything and skip updating relaxed ordering > because we are probably running in a guest machine. When bit4 is set in the PCIe Device Control register, it indicates whether the device is permitted to use relaxed ordering. On some platforms using relaxed ordering can have performance issues or due to erratum can cause data-corruption. In such cases devices must avoid using relaxed ordering. This patch checks if there is any node in the hierarchy that indicates that using relaxed ordering is not safe. In such cases the patch turns off the relaxed ordering by clearing the eapability for this device. > > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> > --- > drivers/pci/pci.c | 29 +++++++++++++++++++++++++++++ > drivers/pci/probe.c | 37 +++++++++++++++++++++++++++++++++++++ > include/linux/pci.h | 2 ++ > 3 files changed, 68 insertions(+) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index d88edf5..7a6b32f 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -4854,6 +4854,35 @@ int pcie_set_mps(struct pci_dev *dev, int mps) > EXPORT_SYMBOL(pcie_set_mps); > > /** > + * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit > + * @dev: PCI device to query > + * > + * If possible clear relaxed ordering > + */ > +int pcie_clear_relaxed_ordering(struct pci_dev *dev) > +{ > + return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, > + PCI_EXP_DEVCTL_RELAX_EN); > +} > +EXPORT_SYMBOL(pcie_clear_relaxed_ordering); > + > +/** > + * pcie_relaxed_ordering_supported - Probe for PCIe relexed ordering support > + * @dev: PCI device to query > + * > + * Returns true if the device support relaxed ordering attribute. > + */ > +bool pcie_relaxed_ordering_supported(struct pci_dev *dev) > +{ > + u16 v; > + > + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v); > + > + return !!(v & PCI_EXP_DEVCTL_RELAX_EN); > +} > +EXPORT_SYMBOL(pcie_relaxed_ordering_supported); > + > +/** > * pcie_get_minimum_link - determine minimum link settings of a PCI device > * @dev: PCI device to query > * @speed: storage for minimum speed > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c > index c31310d..48df012 100644 > --- a/drivers/pci/probe.c > +++ b/drivers/pci/probe.c > @@ -1762,6 +1762,42 @@ static void pci_configure_extended_tags(struct pci_dev *dev) > PCI_EXP_DEVCTL_EXT_TAG); > } > > +/** > + * pci_dev_should_disable_relaxed_ordering - check if the PCI device > + * should disable the relaxed ordering attribute. > + * @dev: PCI device > + * > + * Return true if any of the PCI devices above us do not support > + * relaxed ordering. > + */ > +static bool pci_dev_should_disable_relaxed_ordering(struct pci_dev *dev) > +{ > + while (dev) { > + if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) > + return true; > + > + dev = dev->bus->self; > + } > + > + return false; > +} > + > +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, do nothing. */ > + if (!pcie_relaxed_ordering_supported(dev)) > + return; > + > + if (pci_dev_should_disable_relaxed_ordering(dev)) { > + pcie_clear_relaxed_ordering(dev); > + dev_info(&dev->dev, "Disable Relaxed Ordering\n"); > + } > +} > + > static void pci_configure_device(struct pci_dev *dev) > { > struct hotplug_params hpp; > @@ -1769,6 +1805,7 @@ static void pci_configure_device(struct pci_dev *dev) > > pci_configure_mps(dev); > pci_configure_extended_tags(dev); > + pci_configure_relaxed_ordering(dev); > > memset(&hpp, 0, sizeof(hpp)); > ret = pci_get_hp_params(dev, &hpp); > diff --git a/include/linux/pci.h b/include/linux/pci.h > index 412ec1c..3aa23a2 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -1127,6 +1127,8 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev, > void pci_pme_wakeup_bus(struct pci_bus *bus); > void pci_d3cold_enable(struct pci_dev *dev); > void pci_d3cold_disable(struct pci_dev *dev); > +int pcie_clear_relaxed_ordering(struct pci_dev *dev); > +bool pcie_relaxed_ordering_supported(struct pci_dev *dev); > > /* PCI Virtual Channel */ > int pci_save_vc_state(struct pci_dev *dev); > -- > 1.8.3.1 > > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported 2017-08-03 9:13 ` Raj, Ashok @ 2017-08-03 10:22 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-08-03 10:22 UTC (permalink / raw) To: Raj, Ashok Cc: leedom, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm 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 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 by default. >> >> If a PCIe device didn't enable the relaxed ordering attribute default, >> we should not do anything in the PCIe configuration, otherwise we >> should check if any of the devices above us do not support relaxed >> ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on >> the result if we get a return that indicate that the relaxed ordering >> is not supported we should update our device to disable relaxed ordering >> in configuration space. If the device above us doesn't exist or isn't >> the PCIe device, we shouldn't do anything and skip updating relaxed ordering >> because we are probably running in a guest machine. > > When bit4 is set in the PCIe Device Control register, it indicates > whether the device is permitted to use relaxed ordering. > On some platforms using relaxed ordering can have performance issues or > due to erratum can cause data-corruption. In such cases devices must avoid > using relaxed ordering. > > This patch checks if there is any node in the hierarchy that indicates that > using relaxed ordering is not safe. In such cases the patch turns off the > relaxed ordering by clearing the eapability for this device. > Good, thanks for the commit, I will send v8 and update the patch description. Ding >> >> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> >> --- >> drivers/pci/pci.c | 29 +++++++++++++++++++++++++++++ >> drivers/pci/probe.c | 37 +++++++++++++++++++++++++++++++++++++ >> include/linux/pci.h | 2 ++ >> 3 files changed, 68 insertions(+) >> >> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c >> index d88edf5..7a6b32f 100644 >> --- a/drivers/pci/pci.c >> +++ b/drivers/pci/pci.c >> @@ -4854,6 +4854,35 @@ int pcie_set_mps(struct pci_dev *dev, int mps) >> EXPORT_SYMBOL(pcie_set_mps); >> >> /** >> + * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit >> + * @dev: PCI device to query >> + * >> + * If possible clear relaxed ordering >> + */ >> +int pcie_clear_relaxed_ordering(struct pci_dev *dev) >> +{ >> + return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, >> + PCI_EXP_DEVCTL_RELAX_EN); >> +} >> +EXPORT_SYMBOL(pcie_clear_relaxed_ordering); >> + >> +/** >> + * pcie_relaxed_ordering_supported - Probe for PCIe relexed ordering support >> + * @dev: PCI device to query >> + * >> + * Returns true if the device support relaxed ordering attribute. >> + */ >> +bool pcie_relaxed_ordering_supported(struct pci_dev *dev) >> +{ >> + u16 v; >> + >> + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v); >> + >> + return !!(v & PCI_EXP_DEVCTL_RELAX_EN); >> +} >> +EXPORT_SYMBOL(pcie_relaxed_ordering_supported); >> + >> +/** >> * pcie_get_minimum_link - determine minimum link settings of a PCI device >> * @dev: PCI device to query >> * @speed: storage for minimum speed >> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c >> index c31310d..48df012 100644 >> --- a/drivers/pci/probe.c >> +++ b/drivers/pci/probe.c >> @@ -1762,6 +1762,42 @@ static void pci_configure_extended_tags(struct pci_dev *dev) >> PCI_EXP_DEVCTL_EXT_TAG); >> } >> >> +/** >> + * pci_dev_should_disable_relaxed_ordering - check if the PCI device >> + * should disable the relaxed ordering attribute. >> + * @dev: PCI device >> + * >> + * Return true if any of the PCI devices above us do not support >> + * relaxed ordering. >> + */ >> +static bool pci_dev_should_disable_relaxed_ordering(struct pci_dev *dev) >> +{ >> + while (dev) { >> + if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) >> + return true; >> + >> + dev = dev->bus->self; >> + } >> + >> + return false; >> +} >> + >> +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, do nothing. */ >> + if (!pcie_relaxed_ordering_supported(dev)) >> + return; >> + >> + if (pci_dev_should_disable_relaxed_ordering(dev)) { >> + pcie_clear_relaxed_ordering(dev); >> + dev_info(&dev->dev, "Disable Relaxed Ordering\n"); >> + } >> +} >> + >> static void pci_configure_device(struct pci_dev *dev) >> { >> struct hotplug_params hpp; >> @@ -1769,6 +1805,7 @@ static void pci_configure_device(struct pci_dev *dev) >> >> pci_configure_mps(dev); >> pci_configure_extended_tags(dev); >> + pci_configure_relaxed_ordering(dev); >> >> memset(&hpp, 0, sizeof(hpp)); >> ret = pci_get_hp_params(dev, &hpp); >> diff --git a/include/linux/pci.h b/include/linux/pci.h >> index 412ec1c..3aa23a2 100644 >> --- a/include/linux/pci.h >> +++ b/include/linux/pci.h >> @@ -1127,6 +1127,8 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev, >> void pci_pme_wakeup_bus(struct pci_bus *bus); >> void pci_d3cold_enable(struct pci_dev *dev); >> void pci_d3cold_disable(struct pci_dev *dev); >> +int pcie_clear_relaxed_ordering(struct pci_dev *dev); >> +bool pcie_relaxed_ordering_supported(struct pci_dev *dev); >> >> /* PCI Virtual Channel */ >> int pci_save_vc_state(struct pci_dev *dev); >> -- >> 1.8.3.1 >> >> > > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported @ 2017-08-03 10:22 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-08-03 10:22 UTC (permalink / raw) To: linux-arm-kernel 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 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 by default. >> >> If a PCIe device didn't enable the relaxed ordering attribute default, >> we should not do anything in the PCIe configuration, otherwise we >> should check if any of the devices above us do not support relaxed >> ordering by the PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag, then base on >> the result if we get a return that indicate that the relaxed ordering >> is not supported we should update our device to disable relaxed ordering >> in configuration space. If the device above us doesn't exist or isn't >> the PCIe device, we shouldn't do anything and skip updating relaxed ordering >> because we are probably running in a guest machine. > > When bit4 is set in the PCIe Device Control register, it indicates > whether the device is permitted to use relaxed ordering. > On some platforms using relaxed ordering can have performance issues or > due to erratum can cause data-corruption. In such cases devices must avoid > using relaxed ordering. > > This patch checks if there is any node in the hierarchy that indicates that > using relaxed ordering is not safe. In such cases the patch turns off the > relaxed ordering by clearing the eapability for this device. > Good, thanks for the commit, I will send v8 and update the patch description. Ding >> >> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> >> --- >> drivers/pci/pci.c | 29 +++++++++++++++++++++++++++++ >> drivers/pci/probe.c | 37 +++++++++++++++++++++++++++++++++++++ >> include/linux/pci.h | 2 ++ >> 3 files changed, 68 insertions(+) >> >> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c >> index d88edf5..7a6b32f 100644 >> --- a/drivers/pci/pci.c >> +++ b/drivers/pci/pci.c >> @@ -4854,6 +4854,35 @@ int pcie_set_mps(struct pci_dev *dev, int mps) >> EXPORT_SYMBOL(pcie_set_mps); >> >> /** >> + * pcie_clear_relaxed_ordering - clear PCI Express relaxed ordering bit >> + * @dev: PCI device to query >> + * >> + * If possible clear relaxed ordering >> + */ >> +int pcie_clear_relaxed_ordering(struct pci_dev *dev) >> +{ >> + return pcie_capability_clear_word(dev, PCI_EXP_DEVCTL, >> + PCI_EXP_DEVCTL_RELAX_EN); >> +} >> +EXPORT_SYMBOL(pcie_clear_relaxed_ordering); >> + >> +/** >> + * pcie_relaxed_ordering_supported - Probe for PCIe relexed ordering support >> + * @dev: PCI device to query >> + * >> + * Returns true if the device support relaxed ordering attribute. >> + */ >> +bool pcie_relaxed_ordering_supported(struct pci_dev *dev) >> +{ >> + u16 v; >> + >> + pcie_capability_read_word(dev, PCI_EXP_DEVCTL, &v); >> + >> + return !!(v & PCI_EXP_DEVCTL_RELAX_EN); >> +} >> +EXPORT_SYMBOL(pcie_relaxed_ordering_supported); >> + >> +/** >> * pcie_get_minimum_link - determine minimum link settings of a PCI device >> * @dev: PCI device to query >> * @speed: storage for minimum speed >> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c >> index c31310d..48df012 100644 >> --- a/drivers/pci/probe.c >> +++ b/drivers/pci/probe.c >> @@ -1762,6 +1762,42 @@ static void pci_configure_extended_tags(struct pci_dev *dev) >> PCI_EXP_DEVCTL_EXT_TAG); >> } >> >> +/** >> + * pci_dev_should_disable_relaxed_ordering - check if the PCI device >> + * should disable the relaxed ordering attribute. >> + * @dev: PCI device >> + * >> + * Return true if any of the PCI devices above us do not support >> + * relaxed ordering. >> + */ >> +static bool pci_dev_should_disable_relaxed_ordering(struct pci_dev *dev) >> +{ >> + while (dev) { >> + if (dev->dev_flags & PCI_DEV_FLAGS_NO_RELAXED_ORDERING) >> + return true; >> + >> + dev = dev->bus->self; >> + } >> + >> + return false; >> +} >> + >> +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, do nothing. */ >> + if (!pcie_relaxed_ordering_supported(dev)) >> + return; >> + >> + if (pci_dev_should_disable_relaxed_ordering(dev)) { >> + pcie_clear_relaxed_ordering(dev); >> + dev_info(&dev->dev, "Disable Relaxed Ordering\n"); >> + } >> +} >> + >> static void pci_configure_device(struct pci_dev *dev) >> { >> struct hotplug_params hpp; >> @@ -1769,6 +1805,7 @@ static void pci_configure_device(struct pci_dev *dev) >> >> pci_configure_mps(dev); >> pci_configure_extended_tags(dev); >> + pci_configure_relaxed_ordering(dev); >> >> memset(&hpp, 0, sizeof(hpp)); >> ret = pci_get_hp_params(dev, &hpp); >> diff --git a/include/linux/pci.h b/include/linux/pci.h >> index 412ec1c..3aa23a2 100644 >> --- a/include/linux/pci.h >> +++ b/include/linux/pci.h >> @@ -1127,6 +1127,8 @@ int pci_add_ext_cap_save_buffer(struct pci_dev *dev, >> void pci_pme_wakeup_bus(struct pci_bus *bus); >> void pci_d3cold_enable(struct pci_dev *dev); >> void pci_d3cold_disable(struct pci_dev *dev); >> +int pcie_clear_relaxed_ordering(struct pci_dev *dev); >> +bool pcie_relaxed_ordering_supported(struct pci_dev *dev); >> >> /* PCI Virtual Channel */ >> int pci_save_vc_state(struct pci_dev *dev); >> -- >> 1.8.3.1 >> >> > > . > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag 2017-07-13 14:21 ` Ding Tianhong (?) @ 2017-07-13 14:21 ` Ding Tianhong -1 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-13 14:21 UTC (permalink / raw) To: leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm Cc: Ding Tianhong From: Casey Leedom <leedom@chelsio.com> cxgb4 Ethernet driver now queries PCIe configuration space to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability Device Control[Relaxed Ordering Enable] at probe routine, to make sure the driver will not send the Relaxed Ordering TLPs to the Root Complex which could not deal the Relaxed Ordering TLPs. Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> --- drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 + drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 23 +++++++++++++++++------ drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +++-- 3 files changed, 21 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h index ef4be78..09ea62e 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h @@ -529,6 +529,7 @@ enum { /* adapter flags */ USING_SOFT_PARAMS = (1 << 6), MASTER_PF = (1 << 7), FW_OFLD_CONN = (1 << 9), + ROOT_NO_RELAXED_ORDERING = (1 << 10), }; enum { diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c index e403fa1..391e484 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c @@ -4654,11 +4654,6 @@ static void print_port_info(const struct net_device *dev) dev->name, adap->params.vpd.id, adap->name, buf); } -static void enable_pcie_relaxed_ordering(struct pci_dev *dev) -{ - pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN); -} - /* * Free the following resources: * - memory used for tables @@ -4908,7 +4903,6 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) } pci_enable_pcie_error_reporting(pdev); - enable_pcie_relaxed_ordering(pdev); pci_set_master(pdev); pci_save_state(pdev); @@ -4947,6 +4941,23 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) adapter->msg_enable = DFLT_MSG_ENABLE; memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map)); + /* If possible, we use PCIe Relaxed Ordering Attribute to deliver + * Ingress Packet Data to Free List Buffers in order to allow for + * chipset performance optimizations between the Root Complex and + * Memory Controllers. (Messages to the associated Ingress Queue + * notifying new Packet Placement in the Free Lists Buffers will be + * send without the Relaxed Ordering Attribute thus guaranteeing that + * all preceding PCIe Transaction Layer Packets will be processed + * first.) But some Root Complexes have various issues with Upstream + * Transaction Layer Packets with the Relaxed Ordering Attribute set. + * The PCIe devices which under the Root Complexes will be cleared the + * Relaxed Ordering bit in the configuration space, So we check our + * PCIe configuration space to see if it's flagged with advice against + * using Relaxed Ordering. + */ + if (!pcie_relaxed_ordering_supported(pdev)) + adapter->flags |= ROOT_NO_RELAXED_ORDERING; + spin_lock_init(&adapter->stats_lock); spin_lock_init(&adapter->tid_release_lock); spin_lock_init(&adapter->win0_lock); diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c index ede1220..4ef68f6 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c @@ -2719,6 +2719,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, struct fw_iq_cmd c; struct sge *s = &adap->sge; struct port_info *pi = netdev_priv(dev); + int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING); /* Size needs to be multiple of 16, including status entry. */ iq->size = roundup(iq->size, 16); @@ -2772,8 +2773,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc); c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F | - FW_IQ_CMD_FL0FETCHRO_F | - FW_IQ_CMD_FL0DATARO_F | + FW_IQ_CMD_FL0FETCHRO_V(relaxed) | + FW_IQ_CMD_FL0DATARO_V(relaxed) | FW_IQ_CMD_FL0PADEN_F); if (cong >= 0) c.iqns_to_fl0congen |= -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-13 14:21 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-13 14:21 UTC (permalink / raw) To: linux-arm-kernel From: Casey Leedom <leedom@chelsio.com> cxgb4 Ethernet driver now queries PCIe configuration space to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability Device Control[Relaxed Ordering Enable] at probe routine, to make sure the driver will not send the Relaxed Ordering TLPs to the Root Complex which could not deal the Relaxed Ordering TLPs. Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> --- drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 + drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 23 +++++++++++++++++------ drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +++-- 3 files changed, 21 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h index ef4be78..09ea62e 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h @@ -529,6 +529,7 @@ enum { /* adapter flags */ USING_SOFT_PARAMS = (1 << 6), MASTER_PF = (1 << 7), FW_OFLD_CONN = (1 << 9), + ROOT_NO_RELAXED_ORDERING = (1 << 10), }; enum { diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c index e403fa1..391e484 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c @@ -4654,11 +4654,6 @@ static void print_port_info(const struct net_device *dev) dev->name, adap->params.vpd.id, adap->name, buf); } -static void enable_pcie_relaxed_ordering(struct pci_dev *dev) -{ - pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN); -} - /* * Free the following resources: * - memory used for tables @@ -4908,7 +4903,6 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) } pci_enable_pcie_error_reporting(pdev); - enable_pcie_relaxed_ordering(pdev); pci_set_master(pdev); pci_save_state(pdev); @@ -4947,6 +4941,23 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) adapter->msg_enable = DFLT_MSG_ENABLE; memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map)); + /* If possible, we use PCIe Relaxed Ordering Attribute to deliver + * Ingress Packet Data to Free List Buffers in order to allow for + * chipset performance optimizations between the Root Complex and + * Memory Controllers. (Messages to the associated Ingress Queue + * notifying new Packet Placement in the Free Lists Buffers will be + * send without the Relaxed Ordering Attribute thus guaranteeing that + * all preceding PCIe Transaction Layer Packets will be processed + * first.) But some Root Complexes have various issues with Upstream + * Transaction Layer Packets with the Relaxed Ordering Attribute set. + * The PCIe devices which under the Root Complexes will be cleared the + * Relaxed Ordering bit in the configuration space, So we check our + * PCIe configuration space to see if it's flagged with advice against + * using Relaxed Ordering. + */ + if (!pcie_relaxed_ordering_supported(pdev)) + adapter->flags |= ROOT_NO_RELAXED_ORDERING; + spin_lock_init(&adapter->stats_lock); spin_lock_init(&adapter->tid_release_lock); spin_lock_init(&adapter->win0_lock); diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c index ede1220..4ef68f6 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c @@ -2719,6 +2719,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, struct fw_iq_cmd c; struct sge *s = &adap->sge; struct port_info *pi = netdev_priv(dev); + int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING); /* Size needs to be multiple of 16, including status entry. */ iq->size = roundup(iq->size, 16); @@ -2772,8 +2773,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc); c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F | - FW_IQ_CMD_FL0FETCHRO_F | - FW_IQ_CMD_FL0DATARO_F | + FW_IQ_CMD_FL0FETCHRO_V(relaxed) | + FW_IQ_CMD_FL0DATARO_V(relaxed) | FW_IQ_CMD_FL0PADEN_F); if (cong >= 0) c.iqns_to_fl0congen |= -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 114+ messages in thread
* [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-13 14:21 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-13 14:21 UTC (permalink / raw) To: leedom, ashok.raj, bhelgaas, helgaas, werner, ganeshgr, asit.k.mallick, patrick.j.cramer, Suravee.Suthikulpanit, Bob.Shaw, l.stach, amira, gabriele.paoloni, David.Laight, jeffrey.t.kirsher, catalin.marinas, will.deacon, mark.rutland, robin.murphy, davem, alexander.duyck, linux-arm-kernel, netdev, linux-pci, linux-kernel, linuxarm Cc: Ding Tianhong From: Casey Leedom <leedom@chelsio.com> cxgb4 Ethernet driver now queries PCIe configuration space to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability Device Control[Relaxed Ordering Enable] at probe routine, to make sure the driver will not send the Relaxed Ordering TLPs to the Root Complex which could not deal the Relaxed Ordering TLPs. Signed-off-by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> --- drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 + drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 23 +++++++++++++++++------ drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +++-- 3 files changed, 21 insertions(+), 8 deletions(-) diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h index ef4be78..09ea62e 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h @@ -529,6 +529,7 @@ enum { /* adapter flags */ USING_SOFT_PARAMS = (1 << 6), MASTER_PF = (1 << 7), FW_OFLD_CONN = (1 << 9), + ROOT_NO_RELAXED_ORDERING = (1 << 10), }; enum { diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c index e403fa1..391e484 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c @@ -4654,11 +4654,6 @@ static void print_port_info(const struct net_device *dev) dev->name, adap->params.vpd.id, adap->name, buf); } -static void enable_pcie_relaxed_ordering(struct pci_dev *dev) -{ - pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN); -} - /* * Free the following resources: * - memory used for tables @@ -4908,7 +4903,6 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) } pci_enable_pcie_error_reporting(pdev); - enable_pcie_relaxed_ordering(pdev); pci_set_master(pdev); pci_save_state(pdev); @@ -4947,6 +4941,23 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) adapter->msg_enable = DFLT_MSG_ENABLE; memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map)); + /* If possible, we use PCIe Relaxed Ordering Attribute to deliver + * Ingress Packet Data to Free List Buffers in order to allow for + * chipset performance optimizations between the Root Complex and + * Memory Controllers. (Messages to the associated Ingress Queue + * notifying new Packet Placement in the Free Lists Buffers will be + * send without the Relaxed Ordering Attribute thus guaranteeing that + * all preceding PCIe Transaction Layer Packets will be processed + * first.) But some Root Complexes have various issues with Upstream + * Transaction Layer Packets with the Relaxed Ordering Attribute set. + * The PCIe devices which under the Root Complexes will be cleared the + * Relaxed Ordering bit in the configuration space, So we check our + * PCIe configuration space to see if it's flagged with advice against + * using Relaxed Ordering. + */ + if (!pcie_relaxed_ordering_supported(pdev)) + adapter->flags |= ROOT_NO_RELAXED_ORDERING; + spin_lock_init(&adapter->stats_lock); spin_lock_init(&adapter->tid_release_lock); spin_lock_init(&adapter->win0_lock); diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c index ede1220..4ef68f6 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c @@ -2719,6 +2719,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, struct fw_iq_cmd c; struct sge *s = &adap->sge; struct port_info *pi = netdev_priv(dev); + int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING); /* Size needs to be multiple of 16, including status entry. */ iq->size = roundup(iq->size, 16); @@ -2772,8 +2773,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc); c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F | - FW_IQ_CMD_FL0FETCHRO_F | - FW_IQ_CMD_FL0DATARO_F | + FW_IQ_CMD_FL0FETCHRO_V(relaxed) | + FW_IQ_CMD_FL0DATARO_V(relaxed) | FW_IQ_CMD_FL0PADEN_F); if (cong >= 0) c.iqns_to_fl0congen |= -- 1.8.3.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag 2017-07-13 14:21 ` Ding Tianhong (?) (?) @ 2017-07-13 18:14 ` Alexander Duyck -1 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-13 18:14 UTC (permalink / raw) To: Ding Tianhong Cc: Casey Leedom, Ashok Raj, Bjorn Helgaas, Bjorn Helgaas, Michael Werner, Ganesh Goudar, Asit K Mallick, Patrick J Cramer, Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni, David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy, David Miller, linux-arm-kernel, Netdev, linux-pci, linux-kernel, LinuxArm On Thu, Jul 13, 2017 at 7:21 AM, Ding Tianhong <dingtianhong@huawei.com> wrote: > From: Casey Leedom <leedom@chelsio.com> > > cxgb4 Ethernet driver now queries PCIe configuration space to determine > if it can send TLPs to it with the Relaxed Ordering Attribute set. > > Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability > Device Control[Relaxed Ordering Enable] at probe routine, to make sure > the driver will not send the Relaxed Ordering TLPs to the Root Complex which > could not deal the Relaxed Ordering TLPs. > > Signed-off-by: Casey Leedom <leedom@chelsio.com> > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Ding, You can probably just drop this patch. If I am understanding Casey correctly just the fact that the relaxed ordering enable bit is cleared in the configuration should be enough to do this for the device automatically. - Alex > --- > drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 + > drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 23 +++++++++++++++++------ > drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +++-- > 3 files changed, 21 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > index ef4be78..09ea62e 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > @@ -529,6 +529,7 @@ enum { /* adapter flags */ > USING_SOFT_PARAMS = (1 << 6), > MASTER_PF = (1 << 7), > FW_OFLD_CONN = (1 << 9), > + ROOT_NO_RELAXED_ORDERING = (1 << 10), > }; > > enum { > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > index e403fa1..391e484 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > @@ -4654,11 +4654,6 @@ static void print_port_info(const struct net_device *dev) > dev->name, adap->params.vpd.id, adap->name, buf); > } > > -static void enable_pcie_relaxed_ordering(struct pci_dev *dev) > -{ > - pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN); > -} > - > /* > * Free the following resources: > * - memory used for tables > @@ -4908,7 +4903,6 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > } > > pci_enable_pcie_error_reporting(pdev); > - enable_pcie_relaxed_ordering(pdev); > pci_set_master(pdev); > pci_save_state(pdev); > > @@ -4947,6 +4941,23 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > adapter->msg_enable = DFLT_MSG_ENABLE; > memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map)); > > + /* If possible, we use PCIe Relaxed Ordering Attribute to deliver > + * Ingress Packet Data to Free List Buffers in order to allow for > + * chipset performance optimizations between the Root Complex and > + * Memory Controllers. (Messages to the associated Ingress Queue > + * notifying new Packet Placement in the Free Lists Buffers will be > + * send without the Relaxed Ordering Attribute thus guaranteeing that > + * all preceding PCIe Transaction Layer Packets will be processed > + * first.) But some Root Complexes have various issues with Upstream > + * Transaction Layer Packets with the Relaxed Ordering Attribute set. > + * The PCIe devices which under the Root Complexes will be cleared the > + * Relaxed Ordering bit in the configuration space, So we check our > + * PCIe configuration space to see if it's flagged with advice against > + * using Relaxed Ordering. > + */ > + if (!pcie_relaxed_ordering_supported(pdev)) > + adapter->flags |= ROOT_NO_RELAXED_ORDERING; > + > spin_lock_init(&adapter->stats_lock); > spin_lock_init(&adapter->tid_release_lock); > spin_lock_init(&adapter->win0_lock); > diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c > index ede1220..4ef68f6 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c > +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c > @@ -2719,6 +2719,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, > struct fw_iq_cmd c; > struct sge *s = &adap->sge; > struct port_info *pi = netdev_priv(dev); > + int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING); > > /* Size needs to be multiple of 16, including status entry. */ > iq->size = roundup(iq->size, 16); > @@ -2772,8 +2773,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, > > flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc); > c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F | > - FW_IQ_CMD_FL0FETCHRO_F | > - FW_IQ_CMD_FL0DATARO_F | > + FW_IQ_CMD_FL0FETCHRO_V(relaxed) | > + FW_IQ_CMD_FL0DATARO_V(relaxed) | > FW_IQ_CMD_FL0PADEN_F); > if (cong >= 0) > c.iqns_to_fl0congen |= > -- > 1.8.3.1 > > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-13 18:14 ` Alexander Duyck 0 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-13 18:14 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 13, 2017 at 7:21 AM, Ding Tianhong <dingtianhong@huawei.com> wrote: > From: Casey Leedom <leedom@chelsio.com> > > cxgb4 Ethernet driver now queries PCIe configuration space to determine > if it can send TLPs to it with the Relaxed Ordering Attribute set. > > Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability > Device Control[Relaxed Ordering Enable] at probe routine, to make sure > the driver will not send the Relaxed Ordering TLPs to the Root Complex which > could not deal the Relaxed Ordering TLPs. > > Signed-off-by: Casey Leedom <leedom@chelsio.com> > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Ding, You can probably just drop this patch. If I am understanding Casey correctly just the fact that the relaxed ordering enable bit is cleared in the configuration should be enough to do this for the device automatically. - Alex > --- > drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 + > drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 23 +++++++++++++++++------ > drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +++-- > 3 files changed, 21 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > index ef4be78..09ea62e 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > @@ -529,6 +529,7 @@ enum { /* adapter flags */ > USING_SOFT_PARAMS = (1 << 6), > MASTER_PF = (1 << 7), > FW_OFLD_CONN = (1 << 9), > + ROOT_NO_RELAXED_ORDERING = (1 << 10), > }; > > enum { > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > index e403fa1..391e484 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > @@ -4654,11 +4654,6 @@ static void print_port_info(const struct net_device *dev) > dev->name, adap->params.vpd.id, adap->name, buf); > } > > -static void enable_pcie_relaxed_ordering(struct pci_dev *dev) > -{ > - pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN); > -} > - > /* > * Free the following resources: > * - memory used for tables > @@ -4908,7 +4903,6 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > } > > pci_enable_pcie_error_reporting(pdev); > - enable_pcie_relaxed_ordering(pdev); > pci_set_master(pdev); > pci_save_state(pdev); > > @@ -4947,6 +4941,23 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > adapter->msg_enable = DFLT_MSG_ENABLE; > memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map)); > > + /* If possible, we use PCIe Relaxed Ordering Attribute to deliver > + * Ingress Packet Data to Free List Buffers in order to allow for > + * chipset performance optimizations between the Root Complex and > + * Memory Controllers. (Messages to the associated Ingress Queue > + * notifying new Packet Placement in the Free Lists Buffers will be > + * send without the Relaxed Ordering Attribute thus guaranteeing that > + * all preceding PCIe Transaction Layer Packets will be processed > + * first.) But some Root Complexes have various issues with Upstream > + * Transaction Layer Packets with the Relaxed Ordering Attribute set. > + * The PCIe devices which under the Root Complexes will be cleared the > + * Relaxed Ordering bit in the configuration space, So we check our > + * PCIe configuration space to see if it's flagged with advice against > + * using Relaxed Ordering. > + */ > + if (!pcie_relaxed_ordering_supported(pdev)) > + adapter->flags |= ROOT_NO_RELAXED_ORDERING; > + > spin_lock_init(&adapter->stats_lock); > spin_lock_init(&adapter->tid_release_lock); > spin_lock_init(&adapter->win0_lock); > diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c > index ede1220..4ef68f6 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c > +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c > @@ -2719,6 +2719,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, > struct fw_iq_cmd c; > struct sge *s = &adap->sge; > struct port_info *pi = netdev_priv(dev); > + int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING); > > /* Size needs to be multiple of 16, including status entry. */ > iq->size = roundup(iq->size, 16); > @@ -2772,8 +2773,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, > > flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc); > c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F | > - FW_IQ_CMD_FL0FETCHRO_F | > - FW_IQ_CMD_FL0DATARO_F | > + FW_IQ_CMD_FL0FETCHRO_V(relaxed) | > + FW_IQ_CMD_FL0DATARO_V(relaxed) | > FW_IQ_CMD_FL0PADEN_F); > if (cong >= 0) > c.iqns_to_fl0congen |= > -- > 1.8.3.1 > > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-13 18:14 ` Alexander Duyck 0 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-13 18:14 UTC (permalink / raw) To: Ding Tianhong Cc: Mark Rutland, Gabriele Paoloni, Asit K Mallick, Catalin Marinas, Will Deacon, LinuxArm, Ashok Raj, Bjorn Helgaas, Jeff Kirsher, linux-pci, Ganesh Goudar, Bob Shaw, Casey Leedom, Patrick J Cramer, Bjorn Helgaas, Michael Werner, linux-arm-kernel, Amir Ancel, Netdev, linux-kernel, David Laight, Suravee Suthikulpanit, Robin Murphy, David Miller, h On Thu, Jul 13, 2017 at 7:21 AM, Ding Tianhong <dingtianhong@huawei.com> wrote: > From: Casey Leedom <leedom@chelsio.com> > > cxgb4 Ethernet driver now queries PCIe configuration space to determine > if it can send TLPs to it with the Relaxed Ordering Attribute set. > > Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability > Device Control[Relaxed Ordering Enable] at probe routine, to make sure > the driver will not send the Relaxed Ordering TLPs to the Root Complex which > could not deal the Relaxed Ordering TLPs. > > Signed-off-by: Casey Leedom <leedom@chelsio.com> > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Ding, You can probably just drop this patch. If I am understanding Casey correctly just the fact that the relaxed ordering enable bit is cleared in the configuration should be enough to do this for the device automatically. - Alex > --- > drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 + > drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 23 +++++++++++++++++------ > drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +++-- > 3 files changed, 21 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > index ef4be78..09ea62e 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > @@ -529,6 +529,7 @@ enum { /* adapter flags */ > USING_SOFT_PARAMS = (1 << 6), > MASTER_PF = (1 << 7), > FW_OFLD_CONN = (1 << 9), > + ROOT_NO_RELAXED_ORDERING = (1 << 10), > }; > > enum { > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > index e403fa1..391e484 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > @@ -4654,11 +4654,6 @@ static void print_port_info(const struct net_device *dev) > dev->name, adap->params.vpd.id, adap->name, buf); > } > > -static void enable_pcie_relaxed_ordering(struct pci_dev *dev) > -{ > - pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN); > -} > - > /* > * Free the following resources: > * - memory used for tables > @@ -4908,7 +4903,6 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > } > > pci_enable_pcie_error_reporting(pdev); > - enable_pcie_relaxed_ordering(pdev); > pci_set_master(pdev); > pci_save_state(pdev); > > @@ -4947,6 +4941,23 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > adapter->msg_enable = DFLT_MSG_ENABLE; > memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map)); > > + /* If possible, we use PCIe Relaxed Ordering Attribute to deliver > + * Ingress Packet Data to Free List Buffers in order to allow for > + * chipset performance optimizations between the Root Complex and > + * Memory Controllers. (Messages to the associated Ingress Queue > + * notifying new Packet Placement in the Free Lists Buffers will be > + * send without the Relaxed Ordering Attribute thus guaranteeing that > + * all preceding PCIe Transaction Layer Packets will be processed > + * first.) But some Root Complexes have various issues with Upstream > + * Transaction Layer Packets with the Relaxed Ordering Attribute set. > + * The PCIe devices which under the Root Complexes will be cleared the > + * Relaxed Ordering bit in the configuration space, So we check our > + * PCIe configuration space to see if it's flagged with advice against > + * using Relaxed Ordering. > + */ > + if (!pcie_relaxed_ordering_supported(pdev)) > + adapter->flags |= ROOT_NO_RELAXED_ORDERING; > + > spin_lock_init(&adapter->stats_lock); > spin_lock_init(&adapter->tid_release_lock); > spin_lock_init(&adapter->win0_lock); > diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c > index ede1220..4ef68f6 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c > +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c > @@ -2719,6 +2719,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, > struct fw_iq_cmd c; > struct sge *s = &adap->sge; > struct port_info *pi = netdev_priv(dev); > + int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING); > > /* Size needs to be multiple of 16, including status entry. */ > iq->size = roundup(iq->size, 16); > @@ -2772,8 +2773,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, > > flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc); > c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F | > - FW_IQ_CMD_FL0FETCHRO_F | > - FW_IQ_CMD_FL0DATARO_F | > + FW_IQ_CMD_FL0FETCHRO_V(relaxed) | > + FW_IQ_CMD_FL0DATARO_V(relaxed) | > FW_IQ_CMD_FL0PADEN_F); > if (cong >= 0) > c.iqns_to_fl0congen |= > -- > 1.8.3.1 > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-13 18:14 ` Alexander Duyck 0 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-13 18:14 UTC (permalink / raw) To: Ding Tianhong Cc: Casey Leedom, Ashok Raj, Bjorn Helgaas, Bjorn Helgaas, Michael Werner, Ganesh Goudar, Asit K Mallick, Patrick J Cramer, Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni, David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy, David Miller On Thu, Jul 13, 2017 at 7:21 AM, Ding Tianhong <dingtianhong@huawei.com> wrote: > From: Casey Leedom <leedom@chelsio.com> > > cxgb4 Ethernet driver now queries PCIe configuration space to determine > if it can send TLPs to it with the Relaxed Ordering Attribute set. > > Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability > Device Control[Relaxed Ordering Enable] at probe routine, to make sure > the driver will not send the Relaxed Ordering TLPs to the Root Complex which > could not deal the Relaxed Ordering TLPs. > > Signed-off-by: Casey Leedom <leedom@chelsio.com> > Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Ding, You can probably just drop this patch. If I am understanding Casey correctly just the fact that the relaxed ordering enable bit is cleared in the configuration should be enough to do this for the device automatically. - Alex > --- > drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 + > drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 23 +++++++++++++++++------ > drivers/net/ethernet/chelsio/cxgb4/sge.c | 5 +++-- > 3 files changed, 21 insertions(+), 8 deletions(-) > > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > index ef4be78..09ea62e 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h > @@ -529,6 +529,7 @@ enum { /* adapter flags */ > USING_SOFT_PARAMS = (1 << 6), > MASTER_PF = (1 << 7), > FW_OFLD_CONN = (1 << 9), > + ROOT_NO_RELAXED_ORDERING = (1 << 10), > }; > > enum { > diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > index e403fa1..391e484 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c > @@ -4654,11 +4654,6 @@ static void print_port_info(const struct net_device *dev) > dev->name, adap->params.vpd.id, adap->name, buf); > } > > -static void enable_pcie_relaxed_ordering(struct pci_dev *dev) > -{ > - pcie_capability_set_word(dev, PCI_EXP_DEVCTL, PCI_EXP_DEVCTL_RELAX_EN); > -} > - > /* > * Free the following resources: > * - memory used for tables > @@ -4908,7 +4903,6 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > } > > pci_enable_pcie_error_reporting(pdev); > - enable_pcie_relaxed_ordering(pdev); > pci_set_master(pdev); > pci_save_state(pdev); > > @@ -4947,6 +4941,23 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) > adapter->msg_enable = DFLT_MSG_ENABLE; > memset(adapter->chan_map, 0xff, sizeof(adapter->chan_map)); > > + /* If possible, we use PCIe Relaxed Ordering Attribute to deliver > + * Ingress Packet Data to Free List Buffers in order to allow for > + * chipset performance optimizations between the Root Complex and > + * Memory Controllers. (Messages to the associated Ingress Queue > + * notifying new Packet Placement in the Free Lists Buffers will be > + * send without the Relaxed Ordering Attribute thus guaranteeing that > + * all preceding PCIe Transaction Layer Packets will be processed > + * first.) But some Root Complexes have various issues with Upstream > + * Transaction Layer Packets with the Relaxed Ordering Attribute set. > + * The PCIe devices which under the Root Complexes will be cleared the > + * Relaxed Ordering bit in the configuration space, So we check our > + * PCIe configuration space to see if it's flagged with advice against > + * using Relaxed Ordering. > + */ > + if (!pcie_relaxed_ordering_supported(pdev)) > + adapter->flags |= ROOT_NO_RELAXED_ORDERING; > + > spin_lock_init(&adapter->stats_lock); > spin_lock_init(&adapter->tid_release_lock); > spin_lock_init(&adapter->win0_lock); > diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c > index ede1220..4ef68f6 100644 > --- a/drivers/net/ethernet/chelsio/cxgb4/sge.c > +++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c > @@ -2719,6 +2719,7 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, > struct fw_iq_cmd c; > struct sge *s = &adap->sge; > struct port_info *pi = netdev_priv(dev); > + int relaxed = !(adap->flags & ROOT_NO_RELAXED_ORDERING); > > /* Size needs to be multiple of 16, including status entry. */ > iq->size = roundup(iq->size, 16); > @@ -2772,8 +2773,8 @@ int t4_sge_alloc_rxq(struct adapter *adap, struct sge_rspq *iq, bool fwevtq, > > flsz = fl->size / 8 + s->stat_len / sizeof(struct tx_desc); > c.iqns_to_fl0congen |= htonl(FW_IQ_CMD_FL0PACKEN_F | > - FW_IQ_CMD_FL0FETCHRO_F | > - FW_IQ_CMD_FL0DATARO_F | > + FW_IQ_CMD_FL0FETCHRO_V(relaxed) | > + FW_IQ_CMD_FL0DATARO_V(relaxed) | > FW_IQ_CMD_FL0PADEN_F); > if (cong >= 0) > c.iqns_to_fl0congen |= > -- > 1.8.3.1 > > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag 2017-07-13 18:14 ` Alexander Duyck (?) (?) @ 2017-07-13 18:17 ` Alexander Duyck -1 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-13 18:17 UTC (permalink / raw) To: Ding Tianhong Cc: Casey Leedom, Ashok Raj, Bjorn Helgaas, Bjorn Helgaas, Michael Werner, Ganesh Goudar, Asit K Mallick, Patrick J Cramer, Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni, David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy, David Miller, linux-arm-kernel, Netdev, linux-pci, linux-kernel, LinuxArm On Thu, Jul 13, 2017 at 11:14 AM, Alexander Duyck <alexander.duyck@gmail.com> wrote: > On Thu, Jul 13, 2017 at 7:21 AM, Ding Tianhong <dingtianhong@huawei.com> wrote: >> From: Casey Leedom <leedom@chelsio.com> >> >> cxgb4 Ethernet driver now queries PCIe configuration space to determine >> if it can send TLPs to it with the Relaxed Ordering Attribute set. >> >> Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability >> Device Control[Relaxed Ordering Enable] at probe routine, to make sure >> the driver will not send the Relaxed Ordering TLPs to the Root Complex which >> could not deal the Relaxed Ordering TLPs. >> >> Signed-off-by: Casey Leedom <leedom@chelsio.com> >> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> > > Ding, > > You can probably just drop this patch. If I am understanding Casey > correctly just the fact that the relaxed ordering enable bit is > cleared in the configuration should be enough to do this for the > device automatically. > > - Alex Actually I take that back. I hadn't caught the most recent parts of the thread. If this is good for Casey then this works for me. - Alex ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-13 18:17 ` Alexander Duyck 0 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-13 18:17 UTC (permalink / raw) To: linux-arm-kernel On Thu, Jul 13, 2017 at 11:14 AM, Alexander Duyck <alexander.duyck@gmail.com> wrote: > On Thu, Jul 13, 2017 at 7:21 AM, Ding Tianhong <dingtianhong@huawei.com> wrote: >> From: Casey Leedom <leedom@chelsio.com> >> >> cxgb4 Ethernet driver now queries PCIe configuration space to determine >> if it can send TLPs to it with the Relaxed Ordering Attribute set. >> >> Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability >> Device Control[Relaxed Ordering Enable] at probe routine, to make sure >> the driver will not send the Relaxed Ordering TLPs to the Root Complex which >> could not deal the Relaxed Ordering TLPs. >> >> Signed-off-by: Casey Leedom <leedom@chelsio.com> >> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> > > Ding, > > You can probably just drop this patch. If I am understanding Casey > correctly just the fact that the relaxed ordering enable bit is > cleared in the configuration should be enough to do this for the > device automatically. > > - Alex Actually I take that back. I hadn't caught the most recent parts of the thread. If this is good for Casey then this works for me. - Alex ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-13 18:17 ` Alexander Duyck 0 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-13 18:17 UTC (permalink / raw) To: Ding Tianhong Cc: Mark Rutland, Gabriele Paoloni, Asit K Mallick, Catalin Marinas, Will Deacon, LinuxArm, Ashok Raj, Bjorn Helgaas, Jeff Kirsher, linux-pci, Ganesh Goudar, Bob Shaw, Casey Leedom, Patrick J Cramer, Bjorn Helgaas, Michael Werner, linux-arm-kernel, Amir Ancel, Netdev, linux-kernel, David Laight, Suravee Suthikulpanit, Robin Murphy, David Miller, h On Thu, Jul 13, 2017 at 11:14 AM, Alexander Duyck <alexander.duyck@gmail.com> wrote: > On Thu, Jul 13, 2017 at 7:21 AM, Ding Tianhong <dingtianhong@huawei.com> wrote: >> From: Casey Leedom <leedom@chelsio.com> >> >> cxgb4 Ethernet driver now queries PCIe configuration space to determine >> if it can send TLPs to it with the Relaxed Ordering Attribute set. >> >> Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability >> Device Control[Relaxed Ordering Enable] at probe routine, to make sure >> the driver will not send the Relaxed Ordering TLPs to the Root Complex which >> could not deal the Relaxed Ordering TLPs. >> >> Signed-off-by: Casey Leedom <leedom@chelsio.com> >> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> > > Ding, > > You can probably just drop this patch. If I am understanding Casey > correctly just the fact that the relaxed ordering enable bit is > cleared in the configuration should be enough to do this for the > device automatically. > > - Alex Actually I take that back. I hadn't caught the most recent parts of the thread. If this is good for Casey then this works for me. - Alex _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-13 18:17 ` Alexander Duyck 0 siblings, 0 replies; 114+ messages in thread From: Alexander Duyck @ 2017-07-13 18:17 UTC (permalink / raw) To: Ding Tianhong Cc: Casey Leedom, Ashok Raj, Bjorn Helgaas, Bjorn Helgaas, Michael Werner, Ganesh Goudar, Asit K Mallick, Patrick J Cramer, Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni, David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy, David Miller On Thu, Jul 13, 2017 at 11:14 AM, Alexander Duyck <alexander.duyck@gmail.com> wrote: > On Thu, Jul 13, 2017 at 7:21 AM, Ding Tianhong <dingtianhong@huawei.com> wrote: >> From: Casey Leedom <leedom@chelsio.com> >> >> cxgb4 Ethernet driver now queries PCIe configuration space to determine >> if it can send TLPs to it with the Relaxed Ordering Attribute set. >> >> Remove the enable_pcie_relaxed_ordering() to avoid enable PCIe Capability >> Device Control[Relaxed Ordering Enable] at probe routine, to make sure >> the driver will not send the Relaxed Ordering TLPs to the Root Complex which >> could not deal the Relaxed Ordering TLPs. >> >> Signed-off-by: Casey Leedom <leedom@chelsio.com> >> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> > > Ding, > > You can probably just drop this patch. If I am understanding Casey > correctly just the fact that the relaxed ordering enable bit is > cleared in the configuration should be enough to do this for the > device automatically. > > - Alex Actually I take that back. I hadn't caught the most recent parts of the thread. If this is good for Casey then this works for me. - Alex ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag 2017-07-13 18:17 ` Alexander Duyck ` (2 preceding siblings ...) (?) @ 2017-07-13 18:44 ` Casey Leedom 2017-07-14 10:23 ` Ding Tianhong -1 siblings, 1 reply; 114+ messages in thread From: Casey Leedom @ 2017-07-13 18:44 UTC (permalink / raw) To: Alexander Duyck, Ding Tianhong Cc: Ashok Raj, Bjorn Helgaas, Bjorn Helgaas, Michael Werner, Ganesh GR, Asit K Mallick, Patrick J Cramer, Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni, David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy, David Miller, linux-arm-kernel, Netdev, linux-pci, linux-kernel, LinuxArm [-- Attachment #1: Type: text/plain, Size: 368 bytes --] Yeah, I think this works for now. We'll stumble over what to do when we want to mix upstream TLPs without Relaxed Ordering Attributes directed at problematic Root Complexes, and Peer-to-Peer TLPs with Relaxed Ordering Attributes ... or vice versa depending on which target PCIe Device has issues with Relaxed Ordering. Thanks for all the work! Casey [-- Attachment #2: Type: text/html, Size: 965 bytes --] ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag 2017-07-13 18:44 ` Casey Leedom 2017-07-14 10:23 ` Ding Tianhong (?) @ 2017-07-14 10:23 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-14 10:23 UTC (permalink / raw) To: Casey Leedom, Alexander Duyck Cc: Ashok Raj, Bjorn Helgaas, Bjorn Helgaas, Michael Werner, Ganesh GR, Asit K Mallick, Patrick J Cramer, Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni, David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy, David Miller, linux-arm-kernel, Netdev, linux-pci, linux-kernel, LinuxArm Hi Casey, Alexander: Thanks for the great efforts from both of you, It looks like we have reached a consensus finally, could you please add a confirmation message just like Reviewed-by or something else, thanks. :) Ding On 2017/7/14 2:44, Casey Leedom wrote: > Yeah, I think this works for now. We'll stumble over what to do when we want to mix upstream TLPs without Relaxed Ordering Attributes directed at problematic Root Complexes, and Peer-to-Peer TLPs with Relaxed Ordering Attributes ... or vice versa depending on which target PCIe Device has issues with Relaxed Ordering. > > > Thanks for all the work! > > > Casey > > ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-14 10:23 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-14 10:23 UTC (permalink / raw) To: linux-arm-kernel Hi Casey, Alexander: Thanks for the great efforts from both of you, It looks like we have reached a consensus finally, could you please add a confirmation message just like Reviewed-by or something else, thanks. :) Ding On 2017/7/14 2:44, Casey Leedom wrote: > Yeah, I think this works for now. We'll stumble over what to do when we want to mix upstream TLPs without Relaxed Ordering Attributes directed at problematic Root Complexes, and Peer-to-Peer TLPs with Relaxed Ordering Attributes ... or vice versa depending on which target PCIe Device has issues with Relaxed Ordering. > > > Thanks for all the work! > > > Casey > > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-14 10:23 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-14 10:23 UTC (permalink / raw) To: Casey Leedom, Alexander Duyck Cc: Ashok Raj, Bjorn Helgaas, Bjorn Helgaas, Michael Werner, Ganesh GR, Asit K Mallick, Patrick J Cramer, Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni, David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy, David Miller, linux-arm-kernel, Netdev, linux-pci, linux-kernel, LinuxArm Hi Casey, Alexander: Thanks for the great efforts from both of you, It looks like we have reached a consensus finally, could you please add a confirmation message just like Reviewed-by or something else, thanks. :) Ding On 2017/7/14 2:44, Casey Leedom wrote: > Yeah, I think this works for now. We'll stumble over what to do when we want to mix upstream TLPs without Relaxed Ordering Attributes directed at problematic Root Complexes, and Peer-to-Peer TLPs with Relaxed Ordering Attributes ... or vice versa depending on which target PCIe Device has issues with Relaxed Ordering. > > > Thanks for all the work! > > > Casey > > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-14 10:23 ` Ding Tianhong 0 siblings, 0 replies; 114+ messages in thread From: Ding Tianhong @ 2017-07-14 10:23 UTC (permalink / raw) To: Casey Leedom, Alexander Duyck Cc: Mark Rutland, Gabriele Paoloni, Asit K Mallick, Catalin Marinas, Will Deacon, LinuxArm, Ashok Raj, Bjorn Helgaas, Jeff Kirsher, linux-pci, Ganesh GR, Bob Shaw, Patrick J Cramer, Bjorn Helgaas, Michael Werner, linux-arm-kernel, Amir Ancel, Netdev, linux-kernel, David Laight, Suravee Suthikulpanit Hi Casey, Alexander: Thanks for the great efforts from both of you, It looks like we have reached a consensus finally, could you please add a confirmation message just like Reviewed-by or something else, thanks. :) Ding On 2017/7/14 2:44, Casey Leedom wrote: > Yeah, I think this works for now. We'll stumble over what to do when we want to mix upstream TLPs without Relaxed Ordering Attributes directed at problematic Root Complexes, and Peer-to-Peer TLPs with Relaxed Ordering Attributes ... or vice versa depending on which target PCIe Device has issues with Relaxed Ordering. > > > Thanks for all the work! > > > Casey > > ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag 2017-07-14 10:23 ` Ding Tianhong (?) (?) @ 2017-07-14 17:50 ` Casey Leedom -1 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-14 17:50 UTC (permalink / raw) To: Ding Tianhong, Alexander Duyck Cc: Ashok Raj, Bjorn Helgaas, Bjorn Helgaas, Michael Werner, Ganesh GR, Asit K Mallick, Patrick J Cramer, Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni, David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy, David Miller, linux-arm-kernel, Netdev, linux-pci, linux-kernel, LinuxArm Reviewed-by: Casey Leedom <leedom@chelsio.com> ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-14 17:50 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-14 17:50 UTC (permalink / raw) To: linux-arm-kernel Reviewed-by: Casey Leedom <leedom@chelsio.com> ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-14 17:50 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-14 17:50 UTC (permalink / raw) To: Ding Tianhong, Alexander Duyck Cc: Mark Rutland, Gabriele Paoloni, Asit K Mallick, Catalin Marinas, Will Deacon, LinuxArm, Ashok Raj, Bjorn Helgaas, Jeff Kirsher, linux-pci, Ganesh GR, Bob Shaw, Patrick J Cramer, Bjorn Helgaas, Michael Werner, linux-arm-kernel, Amir Ancel, Netdev, linux-kernel, David Laight, Suravee Suthikulpanit, Robin Murphy, David Miller, h Reviewed-by: Casey Leedom <leedom@chelsio.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-14 17:50 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-14 17:50 UTC (permalink / raw) To: Ding Tianhong, Alexander Duyck Cc: Ashok Raj, Bjorn Helgaas, Bjorn Helgaas, Michael Werner, Ganesh GR, Asit K Mallick, Patrick J Cramer, Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni, David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy, David Miller, Reviewed-by: Casey Leedom <leedom@chelsio.com> ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag 2017-07-13 18:17 ` Alexander Duyck (?) (?) @ 2017-07-14 0:00 ` Casey Leedom -1 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-14 0:00 UTC (permalink / raw) To: Alexander Duyck, Ding Tianhong Cc: Ashok Raj, Bjorn Helgaas, Bjorn Helgaas, Michael Werner, Ganesh GR, Asit K Mallick, Patrick J Cramer, Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni, David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy, David Miller, linux-arm-kernel, Netdev, linux-pci, linux-kernel, LinuxArm [[ Sorry for the Double Send: I forgot to switch to Plain Text. Have I mentioned how much I hate modern Web-based email agents? :-) -- Casey ]] Yeah, I think this works for now. We'll stumble over what to do when we want to mix upstream TLPs without Relaxed Ordering Attributes directed at problematic Root Complexes, and Peer-to-Peer TLPs with Relaxed Ordering Attributes ... or vice versa depending on which target PCIe Device has issues with Relaxed Ordering. Thanks for all the work! Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-14 0:00 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-14 0:00 UTC (permalink / raw) To: linux-arm-kernel [[ Sorry for the Double Send: I forgot to switch to Plain Text. Have I mentioned how much I hate modern Web-based email agents? :-) -- Casey ]] ? Yeah, I think this works for now.? We'll stumble over what to do when we want to mix upstream TLPs without Relaxed Ordering Attributes directed at problematic Root Complexes, and Peer-to-Peer TLPs with Relaxed Ordering Attributes ... or vice versa depending on which target PCIe Device has issues with Relaxed Ordering. ? Thanks for all the work! Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-14 0:00 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-14 0:00 UTC (permalink / raw) To: Alexander Duyck, Ding Tianhong Cc: Mark Rutland, Gabriele Paoloni, Asit K Mallick, Catalin Marinas, Will Deacon, LinuxArm, Ashok Raj, Bjorn Helgaas, Jeff Kirsher, linux-pci, Ganesh GR, Bob Shaw, Patrick J Cramer, Bjorn Helgaas, Michael Werner, linux-arm-kernel, Amir Ancel, Netdev, linux-kernel, David Laight, Suravee Suthikulpanit, Robin Murphy, David Miller, h [[ Sorry for the Double Send: I forgot to switch to Plain Text. Have I men= tioned how much I hate modern Web-based email agents? :-) -- Casey ]] =A0 Yeah, I think this works for now.=A0 We'll stumble over what to do whe= n we want to mix upstream TLPs without Relaxed Ordering Attributes directe= d at problematic Root Complexes, and Peer-to-Peer TLPs with Relaxed Orderi= ng Attributes ... or vice versa depending on which target PCIe Device has = issues with Relaxed Ordering. =A0 Thanks for all the work! Casey = _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 114+ messages in thread
* Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag @ 2017-07-14 0:00 ` Casey Leedom 0 siblings, 0 replies; 114+ messages in thread From: Casey Leedom @ 2017-07-14 0:00 UTC (permalink / raw) To: Alexander Duyck, Ding Tianhong Cc: Ashok Raj, Bjorn Helgaas, Bjorn Helgaas, Michael Werner, Ganesh GR, Asit K Mallick, Patrick J Cramer, Suravee Suthikulpanit, Bob Shaw, h, Amir Ancel, Gabriele Paoloni, David Laight, Jeff Kirsher, Catalin Marinas, Will Deacon, Mark Rutland, Robin Murphy, David Miller, [[ Sorry for the Double Send: I forgot to switch to Plain Text. Have I mentioned how much I hate modern Web-based email agents? :-) -- Casey ]] Yeah, I think this works for now. We'll stumble over what to do when we want to mix upstream TLPs without Relaxed Ordering Attributes directed at problematic Root Complexes, and Peer-to-Peer TLPs with Relaxed Ordering Attributes ... or vice versa depending on which target PCIe Device has issues with Relaxed Ordering. Thanks for all the work! Casey ^ permalink raw reply [flat|nested] 114+ messages in thread
end of thread, other threads:[~2017-08-07 9:04 UTC | newest] Thread overview: 114+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-07-13 14:21 [PATCH v7 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Ding Tianhong 2017-07-13 14:21 ` Ding Tianhong 2017-07-13 14:21 ` [PATCH v7 1/3] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING Ding Tianhong 2017-07-13 14:21 ` Ding Tianhong 2017-08-03 8:55 ` Raj, Ashok 2017-08-03 8:55 ` Raj, Ashok 2017-08-03 10:20 ` Ding Tianhong 2017-08-03 10:20 ` Ding Tianhong 2017-07-13 14:21 ` [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported Ding Tianhong 2017-07-13 14:21 ` Ding Tianhong 2017-07-13 14:21 ` Ding Tianhong 2017-07-13 21:09 ` Sinan Kaya 2017-07-13 21:09 ` Sinan Kaya 2017-07-14 1:26 ` Ding Tianhong 2017-07-14 1:26 ` Ding Tianhong 2017-07-14 13:54 ` Sinan Kaya 2017-07-14 13:54 ` Sinan Kaya 2017-07-22 4:19 ` Ding Tianhong 2017-07-22 4:19 ` Ding Tianhong 2017-07-24 15:05 ` Alex Williamson 2017-07-24 15:05 ` Alex Williamson 2017-07-26 18:26 ` Casey Leedom 2017-07-26 18:26 ` Casey Leedom 2017-07-26 18:26 ` Casey Leedom 2017-07-26 18:26 ` Casey Leedom [not found] ` <CAKgT0UeAad6WArvrE71MFJywDs1wOnCF-iJRnbNLrL+knqhXeA@mail.gmail.com> [not found] ` <CAKgT0Uf5hdXUXja_jUB6_kBg6pyX8zXuOMOGzCVNgeBFMUsWqQ@mail.gmail.com> 2017-07-26 18:44 ` Alexander Duyck 2017-07-26 19:05 ` Casey Leedom 2017-07-26 19:05 ` Casey Leedom 2017-07-26 19:05 ` Casey Leedom 2017-07-26 19:05 ` Casey Leedom 2017-07-27 1:01 ` Ding Tianhong 2017-07-27 1:01 ` Ding Tianhong 2017-07-27 1:01 ` Ding Tianhong 2017-07-27 1:01 ` Ding Tianhong 2017-07-27 17:44 ` Casey Leedom 2017-07-27 17:44 ` Casey Leedom 2017-07-27 17:44 ` Casey Leedom 2017-07-27 17:44 ` Casey Leedom 2017-07-27 18:42 ` Raj, Ashok 2017-07-27 18:42 ` Raj, Ashok 2017-07-27 18:42 ` Raj, Ashok 2017-07-27 18:42 ` Raj, Ashok 2017-07-28 2:57 ` Ding Tianhong 2017-07-28 2:57 ` Ding Tianhong 2017-07-28 2:57 ` Ding Tianhong 2017-07-28 2:57 ` Ding Tianhong 2017-07-28 2:48 ` Ding Tianhong 2017-07-28 2:48 ` Ding Tianhong 2017-07-28 2:48 ` Ding Tianhong 2017-07-28 2:48 ` Ding Tianhong 2017-07-27 1:08 ` Ding Tianhong 2017-07-27 1:08 ` Ding Tianhong 2017-07-27 1:08 ` Ding Tianhong 2017-07-27 1:08 ` Ding Tianhong 2017-07-27 17:49 ` Alexander Duyck 2017-07-27 17:49 ` Alexander Duyck 2017-07-27 17:49 ` Alexander Duyck 2017-07-27 17:49 ` Alexander Duyck 2017-07-28 3:00 ` Ding Tianhong 2017-07-28 3:00 ` Ding Tianhong 2017-07-28 3:00 ` Ding Tianhong 2017-07-28 3:00 ` Ding Tianhong 2017-08-02 17:53 ` Casey Leedom 2017-08-02 17:53 ` Casey Leedom 2017-08-02 17:53 ` Casey Leedom 2017-08-02 17:53 ` Casey Leedom 2017-08-03 8:31 ` Raj, Ashok 2017-08-03 8:31 ` Raj, Ashok 2017-08-03 8:31 ` Raj, Ashok 2017-08-03 8:31 ` Raj, Ashok 2017-08-04 20:20 ` Casey Leedom 2017-08-04 20:20 ` Casey Leedom 2017-08-04 20:20 ` Casey Leedom 2017-08-04 20:20 ` Casey Leedom 2017-08-04 20:21 ` Raj, Ashok 2017-08-04 20:21 ` Raj, Ashok 2017-08-04 20:21 ` Raj, Ashok 2017-08-04 20:21 ` Raj, Ashok 2017-08-04 20:48 ` Casey Leedom 2017-08-04 20:48 ` Casey Leedom 2017-08-04 20:48 ` Casey Leedom 2017-08-04 20:48 ` Casey Leedom 2017-08-07 9:04 ` David Laight 2017-08-07 9:04 ` David Laight 2017-08-07 9:04 ` David Laight 2017-08-07 9:04 ` David Laight 2017-08-03 9:13 ` Raj, Ashok 2017-08-03 9:13 ` Raj, Ashok 2017-08-03 10:22 ` Ding Tianhong 2017-08-03 10:22 ` Ding Tianhong 2017-07-13 14:21 ` [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag Ding Tianhong 2017-07-13 14:21 ` Ding Tianhong 2017-07-13 14:21 ` Ding Tianhong 2017-07-13 18:14 ` Alexander Duyck 2017-07-13 18:14 ` Alexander Duyck 2017-07-13 18:14 ` Alexander Duyck 2017-07-13 18:14 ` Alexander Duyck 2017-07-13 18:17 ` Alexander Duyck 2017-07-13 18:17 ` Alexander Duyck 2017-07-13 18:17 ` Alexander Duyck 2017-07-13 18:17 ` Alexander Duyck 2017-07-13 18:44 ` Casey Leedom 2017-07-14 10:23 ` Ding Tianhong 2017-07-14 10:23 ` Ding Tianhong 2017-07-14 10:23 ` Ding Tianhong 2017-07-14 10:23 ` Ding Tianhong 2017-07-14 17:50 ` Casey Leedom 2017-07-14 17:50 ` Casey Leedom 2017-07-14 17:50 ` Casey Leedom 2017-07-14 17:50 ` Casey Leedom 2017-07-14 0:00 ` Casey Leedom 2017-07-14 0:00 ` Casey Leedom 2017-07-14 0:00 ` Casey Leedom 2017-07-14 0:00 ` Casey Leedom
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.