RE: Request for advice on where to put Root Complex fix up code for downstream device

| From: Casey Leedom [lee...@chelsio.com] | Sent: Thursday, May 07, 2015 4:31 PM | | | From: Bjorn Helgaas [bhelg...@google.com] | | Sent: Thursday, May 07, 2015 4:04 PM | | | | There are a lot of fixups in drivers/pci/quirks.c. For things that have to | | be worked around either before a driver

RE: Request for advice on where to put Root Complex fix up code for downstream device

useful in the future. Otherwise I'll just incorporate that loop in my PCI Quirk. Casey From: Bjorn Helgaas [bhelg...@google.com] Sent: Friday, May 29, 2015 9:20 AM To: Casey Leedom Cc: netdev@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: Request

Re: [PATCH net-next 1/3] cxgb4: Add support for loopback between VI of same port

for being so dense. We really are trying to live within the rules but we’re struggling to figure out what patch we should submit. Casey On May 22, 2015, at 11:01 AM, David Miller da...@davemloft.net wrote: From: Casey Leedom lee...@chelsio.com Date: Fri, 22 May 2015 16:49:03 + Oh I

RE: [PATCH net-next 1/3] cxgb4: Add support for loopback between VI of same port

| From: David Miller [da...@davemloft.net] | Sent: Thursday, May 21, 2015 12:30 PM | | The prevailing assumption is that it's OK to have configuration | settings that can't be undone. | | And that's bogus from the beginning. Oh I definitely understand that and agree. Unfortunately I've

RE: [PATCH net-next 1/3] cxgb4: Add support for loopback between VI of same port

| From: David Miller [da...@davemloft.net] | Sent: Sunday, May 17, 2015 8:46 PM | | From: Hariprasad Shenai haripra...@chelsio.com | Date: Sun, 17 May 2015 16:15:21 +0530 | | We now have a new cxgb4 module parameter tx_vf that when set | to a non-zero value, causes cxgb4 to use the Virtual

RE: [PATCHv2 net-next 2/4] cxgb4: For T4, don't read the Firmware Mailbox Control register

nesday, September 30, 2015 8:03 AM To: netdev@vger.kernel.org Cc: da...@davemloft.net; Casey Leedom; Nirranjan Kirubaharan; Hariprasad S Subject: [PATCHv2 net-next 2/4] cxgb4: For T4, don't read the Firmware Mailbox Control register T4 doesn't have the Shadow copy of the register which we can read wit

Re: [PATCH net-next 1/4] cxgb4: Use mask & shift while returning vlan_prio

> On Dec 16, 2015, at 4:07 PM, David Miller wrote: > > From: Hariprasad Shenai > Date: Wed, 16 Dec 2015 13:16:25 +0530 > >> @@ -66,7 +66,7 @@ struct l2t_data { >> >> static inline unsigned int vlan_prio(const struct l2t_entry *e) >> { >> -

Re: [PATCH net-next] cxgb4: Reduce resource allocation in kdump kernel

: Friday, June 3, 2016 10:35:45 AM To: da...@davemloft.net Cc: netdev@vger.kernel.org; Casey Leedom; Nirranjan Kirubaharan; Hariprasad S Subject: [PATCH net-next] cxgb4: Reduce resource allocation in kdump kernel When is_kdump_kernel() is true, reduce our memory footprint by only using a s

Re: [PATCH pci] pci: Add helper function to set VPD size

> Fixes commit 104daa71b396 ("PCI: Determine actual VPD size on first | >> access") | >> | >> Signed-off-by: Casey Leedom <lee...@chelsio.com> | >> Signed-off-by: Hariprasad Shenai <haripra...@chelsio.com> | > Looks good! | | Hey Bjorn, | | Will thi

Re: [RFC PATCH v2] net: ethtool: add support for forward error correction modes

Vidya and I have been in communication on how to support Forward Error Correction Management on Links. My own thoughts are that we should consider using the new Get/Set Link Ksettiongs API because FEC is a low-level Link parameter which is either negotiated at the same time as Link Speed if

Re: [RFC PATCH net-next] net: ethtool: add support for forward error correction modes

I'm attempting to start the work necessary to implement Vidya's proposed new ethtool interface to manage Forward Error Correction settings on a link. I'm confused by the ethtool FEC API and the degree/type of control it offers. At the top of the patch we have: Encoding: Types of encoding

Re: [RFC PATCH net-next] net: ethtool: add support for forward error correction modes

And by the way, we currently have two ethtool APIs which pump in an Auto-Negotiation indication -- set_link_ksettings() and set_pauseparam(). Now we're talking about adding a third, set_fecparam(). Are all of the calls to these three APIs supposed to agree on the concept of

[RFC PATCH net-next] net: ethtool: add support for forward error correction modes

N.B. Sorry I'm not able to respond to the original message since I wasn't subscribed to netdev when it was sent a couple of weeks ago. This feature is something that Chelsio's cxgb4 driver needs. As we've tested our adapters against a number of switches, we've discovered a few which use varying

Re: [PATCH v10 3/5] PCI: Disable Relaxed Ordering Attributes for AMD A1100

the Relaxed | > Ordering Attribute clear are allowed to bypass earlier TLPs with | > Relaxed Ordering set, it would cause Data Corruption, so we need | > to disable Relaxed Ordering Attribute when Upstream TLPs to the | > Root Port. | > | > Signed-off-by: Casey Leedom <lee...@che

Re: [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

| From: Ding Tianhong <dingtianh...@huawei.com> | Sent: Wednesday, August 9, 2017 5:17 AM | | On 2017/8/9 11:02, Bjorn Helgaas wrote: | > | > On Wed, Aug 09, 2017 at 01:40:01AM +, Casey Leedom wrote: | > > | >> | From: Bjorn Helgaas <helg...@kernel.org> | >&g

Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

[[ 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

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Hey Ding, Bjorn, Alexander, et.al., Sorry for the insane delay in getting to this and thanks especially to Ding for picking up the ball on this feature. I got side=-tracked into a multi-week rewrite of our Firmware/Host Driver Port Capabilities code, then to the recent Ethernet Plug-Fest at

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

By the way, it ~seems~ like the patch set confuses the idea of the PCIe Capability Device Control[Relaxed Ordering Enable] with the device's ability to handle incoming TLPs with the Relaxed Ordering Attribute set. These are completely different things. The PCIe Capability Device

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Hey Alexander, Okay, I understand your point regarding the "most likely scenario" being TLPs directed upstream to the Root Complex. But I'd still like to make sure that we have an agreed upon API/methodology for doing Peer-to-Peer with Relaxed Ordering and no Relaxed Ordering to the Root

Re: [PATCH net-next 1/3] net: ethtool: add support for forward error correction modes

| From: Jakub Kicinski | Sent: Wednesday, June 28, 2017 6:00 PM |   | On Wed, 28 Jun 2017 14:47:51 -0700, Dustin Byford wrote: | > | > You're not the first, or the second to ask that question.  I agree it | > could use clarification. | > | > I always read auto in this context

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Okay, thanks for the note Alexander. I'll have to look more closely at the patch on Monday and try it out on one of the targeted systems to verify the semantics you describe. However, that said, there is no way to tell a priori where a device will send TLPs. To simply assume that all TLPs

Re: [PATCH net-next 1/3] net: ethtool: add support for forward error correction modes

| From: Jakub Kicinski | Sent: Thursday, July 6, 2017 12:02 PM | | IMHO if something gets replugged all the settings should be reset. | I feel that it's not entirely unlike replugging a USB adapter. Perhaps | we should introduce some (devlink) notifications for SFP module events

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

  Sorry again for the delay.  This time at least partially caused by a Chelsio-internal Customer Support request to simply disable Relaxed Ordering entirely due to the performance issues with our 100Gb/s product and relatively recent Intel Root Complexes. Our Customer Support people are tired

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

| From: Ding Tianhong | Sent: Wednesday, July 12, 2017 6:18 PM | | If no other more suggestion, I will send a new version and remove the | enable_pcie_relaxed_ordering(), thanks.  :) Sounds good to me. (And sorry for forgetting to justify that last message. I hate

Re: [PATCH v7 3/3] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

Reviewed-by: Casey Leedom <lee...@chelsio.com>

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

| From: Ding Tianhong <dingtianh...@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

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

| From: Alexander Duyck <alexander.du...@gmail.com> | Sent: Wednesday, July 26, 2017 11:44 AM | | On Jul 26, 2017 11:26 AM, "Casey Leedom" <lee...@chelsio.com> wrote: | | | |     I think that the patch will need to be extended to modify | |     drivers/pci.c/iov.c:sriov_

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

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

Re: [PATCH net-next 1/3] net: ethtool: add support for forward error correction modes

| From: Wyborny, Carolyn | Sent: Thursday, July 6, 2017 3:16 PM | | Agree with your points generally, but other networking hw vendors have | dealt with this since SFP variant and other modules arrived on the scene.  The only case of this of which I'm aware is the SFP+

Re: [PATCH net-next 1/3] net: ethtool: add support for forward error correction modes

| From: Andrew Lunn | Sent: Thursday, July 6, 2017 4:15 PM |   | > Even this feels too extreme for me.  I think users would hate it.  They | > did an ifup and swapped cables.  They expect the OS/Driver/Firmware | > to continue trying to honor their ifup request. | | Lets take

Re: [PATCH net-next 1/3] net: ethtool: add support for forward error correction modes

| From: Andrew Lunn <and...@lunn.ch> | Sent: Thursday, July 6, 2017 3:33 PM |   | On Thu, Jul 06, 2017 at 09:53:46PM +, Casey Leedom wrote: | > | > But, and far more importantly, ideally _*ANY*_ such decision is made at an | > architectural level to apply to all Link Parame

Re: [PATCH net-next 1/3] net: ethtool: add support for forward error correction modes

| From: Jakub Kicinski <jakub.kicin...@netronome.com> | Sent: Thursday, July 6, 2017 3:43 PM |   | On Thu, 6 Jul 2017 21:53:46 +, Casey Leedom wrote: | > | > But, and far more importantly, ideally _*ANY*_ such decision is made at an | > architectural level to apply to all

Re: [PATCH net-next 1/4] ixgbe: sparc: rename the ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER

| From: Lucas Stach | Sent: Friday, April 28, 2017 1:51 AM | | Am Donnerstag, den 27.04.2017, 12:19 -0500 schrieb Bjorn Helgaas: | > | > | > I thought Relaxed Ordering was an optimization. Are there cases where | > it is actually required for correct behavior? | |

Re: [PATCH net-next 1/4] ixgbe: sparc: rename the ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER

Thanks for adding me to the Cc list Bjorn. Hopefully my message will make it out to the netdev and linux-pci lists -- I'm not currently subscribed to them. I've explicitly marked this message to be sent in plain text but modern email agents suck with respect to this. (sigh) I have officially

Re: [PATCH net-next 1/4] ixgbe: sparc: rename the ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER

| From: Bjorn Helgaas | Sent: Thursday, April 27, 2017 10:19 AM | | Are you hinting that the PCI core or arch code could actually *enable* | Relaxed Ordering without the driver doing anything? Is it safe to do that? | Is there such a thing as a device that is capable of using

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

| From: Raj, Ashok | Sent: Thursday, August 3, 2017 1:31 AM | | I don't understand this completely.. So your driver would know not to send | RO TLP's to root complex. But you want to send RO to the NVMe device? This | is the peer-2-peer case correct? Yes, this is the "heavy

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

| From: Raj, Ashok <ashok@intel.com> | Sent: Friday, August 4, 2017 1:21 PM | | On Fri, Aug 04, 2017 at 08:20:37PM +, Casey Leedom wrote: | > ... | > As I've noted a number of times, it would be great if the Intel Hardware | > Engineers who attempted to implement the R

Re: [PATCH v8 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

| From: Ding Tianhong | Sent: Thursday, August 3, 2017 6:44 AM | | 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

Re: [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

| From: Bjorn Helgaas | Sent: Tuesday, August 8, 2017 4:22 PM | | This needs to include a link to the Intel spec | (https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf, | sec 3.9.1). In the commit message or as a

Re: [PATCH v9 2/4] PCI: Disable PCIe Relaxed Ordering if unsupported

| From: Bjorn Helgaas | Sent: Tuesday, August 8, 2017 7:22 PM | ... | and the caller should do something like this: | | if (pcie_relaxed_ordering_broken(pci_find_pcie_root_port(pdev))) | adapter->flags |= ROOT_NO_RELAXED_ORDERING; | | That way it's obvious where

Re: [PATCH v7 2/3] PCI: Enable PCIe Relaxed Ordering if supported

  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

Re: [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

| From: Raj, Ashok <ashok@intel.com> | Sent: Wednesday, August 9, 2017 11:00 AM | | On Wed, Aug 09, 2017 at 04:46:07PM +, Casey Leedom wrote: | > | From: Raj, Ashok <ashok@intel.com> | > | Sent: Wednesday, August 9, 2017 8:58 AM | > | ... | > | As Casey pointed

Re: [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

| From: Raj, Ashok | Sent: Wednesday, August 9, 2017 8:58 AM | ... | As Casey pointed out in an earlier thread, we choose the heavy hammer | approach because there are some that can lead to data-corruption as opposed | to perf degradation. Careful. As far as I'm aware,

[PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

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

[PATCH 2/2] net/cxgb4: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

cxgb4 Ethernet driver now queries Root Complex Port to determine if it can send TLPs to it with the Relaxed Ordering Attribute set. --- drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 + drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 17 +

[PATCH 0/2] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

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. Casey Leedom (2): PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING net/cxgb4

Re: [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

| From: Ding Tianhong | Sent: Wednesday, May 10, 2017 6:15 PM | | Hi Casey: | | Will you continue to work on this solution or send a new version patches? I won't be able to work on this any time soon given several other urgent issues. If you've got a desire to pick this

Re: [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

| From: Alexander Duyck | Date: Tuesday, May 2, 2017 11:10 AM | ... | So for example, in the case of x86 it seems like there are multiple | root complexes that have issues, and the gains for enabling it with | standard DMA to host memory are small. As such we may want

Re: [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

| From: Alexander Duyck | Sent: Wednesday, May 3, 2017 9:02 AM | ... | It sounds like we are more or less in agreement. My only concern is | really what we default this to. On x86 I would say we could probably | default this to disabled for existing platforms since my

Re: [PATCH 1/2] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

| From: Alexander Duyck | Date: Saturday, May 6, 2017 11:07 AM | | | From: Ding Tianhong | | Date: Fri, May 5, 2017 at 8:08 PM | | | | According the suggestion, I could only think of this code: | | .. | | This is a bit simplistic but it is

Re: [PATCH net] cxgb4: Fix stack out-of-bounds read due to wrong size to t4_record_mbox()

| From: Stefano Brivio | Sent: Friday, August 25, 2017 1:48 PM |   | Passing commands for logging to t4_record_mbox() with size | MBOX_LEN, when the actual command size is actually smaller, | causes out-of-bounds stack accesses in t4_record_mbox() while | copying command

Re: [PATCH] cxgb4vf: fix t4vf_eth_xmit()'s return type

| From: Luc Van Oostenryck | Sent: Tuesday, April 24, 2018 6:19:02 AM | | The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', | which is a typedef for an enum type, but the implementation in this | driver returns an 'int'. | | Fix this by returning

Re: [PATCH v4 12/17] net: cxgb4/cxgb4vf: Eliminate duplicate barriers on weakly-ordered archs

.@codeaurora.org; sulr...@codeaurora.org Cc: linux-arm-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Sinan Kaya; Ganesh GR; Casey Leedom; linux-ker...@vger.kernel.org Subject: [PATCH v4 12/17] net: cxgb4/cxgb4vf: Eliminate duplicate barriers on weakly-ordered archs   Code include