| 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 'netdev_tx_t' in this driver
ra.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 includes wmb(
| 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 words here:
| ...
Than
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
| > Signed-off-by: Ding Tianhong
|
| From: Raj, Ashok
| Sent: Wednesday, August 9, 2017 11:00 AM
|
| On Wed, Aug 09, 2017 at 04:46:07PM +, Casey Leedom wrote:
| > | From: Raj, Ashok
| > | Sent: Wednesday, August 9, 2017 8:58 AM
| > | ...
| > | As Casey pointed out in an earlier thread, we choose the
| 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, there is no Data Corruptio
| From: Ding Tianhong
| 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
| >> | Sent: Tuesday, August 8, 2017 4:22 PM
| >> | ...
| 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 the issue is, and it'
| 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 comment? Regardless, I
| 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 quirk_tw686x_class(struct pci_dev *pdev)
|
| From: Raj, Ashok
| Sent: Friday, August 4, 2017 1:21 PM
|
| On Fri, Aug 04, 2017 at 08:20:37PM +, Casey Leedom wrote:
| > ...
| > As I've noted a number of times, it would be great if the Intel Hardware
| > Engineers who attempted to implement the Relaxed Ordering se
| From: Raj, Ashok
| Sent: Thursday, August 3, 2017 1:31 AM
|
| I don't understand this completely.. So your driver would know not to send
| RO TLP's to root complex. But you want to send RO to the NVMe device? This
| is the peer-2-peer case correct?
Yes, this is the "heavy hammer" issue which yo
Okay, here you go. As you can tell, it's almost a trivial copy of the
cxgb4 patch.
By the way, I realized that we have yet another hole which is likely not
to be fixable. If we're dealing with a problematic Root Complex, and we
instantiate Virtual Functions and attach them to a Virtual Mach
| From: Ding Tianhong
| Sent: Wednesday, July 26, 2017 6:01 PM
|
| On 2017/7/27 3:05, Casey Leedom wrote:
| >
| > Ding, send me a note if you'd like me to work that [cxgb4vf patch] up
| > for you.
|
| Ok, you could send the change log and I could put it in the v8 version
| together,
| From: Alexander Duyck
| Sent: Wednesday, July 26, 2017 11:44 AM
|
| On Jul 26, 2017 11:26 AM, "Casey Leedom" wrote:
| |
| | I think that the patch will need to be extended to modify
| | drivers/pci.c/iov.c:sriov_enable() to explicitly turn off
| | Relaxed Ordering Ena
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
Reviewed-by: Casey Leedom
[[ 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
| 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 working with web-based emai
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 o
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 Compl
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 wi
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 Control[Rela
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 the
| 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 a look around at
| From: Jakub Kicinski
| 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 Link Parameters and Vendor Products
| From: Andrew Lunn
| 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 Parameters and Vendor
| 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+ RJ45 1Gb/s
Transceiver Modu
| 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
| so userspace ca
| 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 as automatic rat
| 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 up, I'd be happy to help
| 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 a start.
Yes, something tells me that this is goin
| 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 understanding
| is that relax
| 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 to default
| it to off via th
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
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
Performanc
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 +
drivers/net/ethernet/chelsio/cxgb4
| 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?
|
| Yes, at least the Tegra
| 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 RO, but where the
|
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
be
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
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
Of
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 Auto-Negotiations
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 d
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 single "Queue Set" and
uot;PCI: Determine actual VPD size on first
| >> access")
| >>
| >> Signed-off-by: Casey Leedom
| >> Signed-off-by: Hariprasad Shenai
| > Looks good!
|
| Hey Bjorn,
|
| Will this make the next 4.6-rc?
Without a fix of some sort, cxgb4 is completely dead in the w
> 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)
>> {
>> -return e->vlan >> 13;
>> +return (e->vlan & VL
: Wednesday, 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
prove 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: R
| 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
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 wrote:
>
> From: Casey Leedom
> Date: Fri, 22 May 2015 16:49:03 +
>
>> Oh I definitel
| 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
inheri
| From: David Miller [da...@davemloft.net]
| Sent: Sunday, May 17, 2015 8:46 PM
|
| > From: Hariprasad Shenai
| > 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 Machine" versio
53 matches
Mail list logo
