Re: [PATCH net-next 1/3] cxgb4: Add support for loopback between VI of same port
Okay, really: I’m not arguing for module parameters. I’m agreeing with you
100%.
I’m not trying to be snarky or back you into admitting that there are some times
when a module parameter is needed. I’m not being sneaky, etc. I’m really just
asking a mechanism question. It is, on the other hand, quite likely that I’m
being dumb. I’ll absolutely grant you that.
So let me turn this around and ask:
What command would you envision that I use in order to tell a driver
to use a different TX routine for an interface?
ethtool —tx-routine eth{n} loopback
Or?
Sorry 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 definitely understand that and agree. Unfortunately I've
inherited a driver architecture that makes that ... difficult
for many operations ... And I have an internal bug filed
against me to fix those particular issues.
However, that doesn't answer at least one of my questions
which was how do I pass information into the driver _before_
it does the device probe?
I did answer the question, I said that if you fix the real actual
core problem then you won't have this need to begin with.
I thought I made that perfectly clear.
I really am not going to entertain arguments of the form it's
too hard to implement this correctly so I'm going to try
and slam a module parameter into the driver to fix things.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 inherited a driver architecture that makes that ... difficult for many operations ... And I have an internal bug filed against me to fix those particular issues. However, that doesn't answer at least one of my questions which was how do I pass information into the driver _before_ it does the device probe? In this case, telling it to _not_ attempt to attached to the chip firmware in order to debug, load firmware, etc.? And, I still need to know what mechanism we need to use to tell the driver to use one kind of transmit functionality or another. [[And in this case, we _can_ switch back and forth at will.]] Casey-- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 1/3] cxgb4: Add support for loopback between VI of same port
From: Casey Leedom lee...@chelsio.com Date: Fri, 22 May 2015 16:49:03 + Oh I definitely understand that and agree. Unfortunately I've inherited a driver architecture that makes that ... difficult for many operations ... And I have an internal bug filed against me to fix those particular issues. However, that doesn't answer at least one of my questions which was how do I pass information into the driver _before_ it does the device probe? I did answer the question, I said that if you fix the real actual core problem then you won't have this need to begin with. I thought I made that perfectly clear. I really am not going to entertain arguments of the form it's too hard to implement this correctly so I'm going to try and slam a module parameter into the driver to fix things. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 1/3] cxgb4: Add support for loopback between VI of same port
From: Casey Leedom lee...@chelsio.com Date: Thu, 21 May 2015 16:36:00 + I definitely understand the issue of wanting to avoid randomly different module parameters in various drivers which do similar things. What we're looking for is a list of the acceptable ways for doing things ― especially when they don't fit current ethtool/ioctl() mechanisms. The prevailing assumption is that it's OK to have configuration settings that can't be undone. And that's bogus from the beginning. Drivers that have such situations are extremely painful for large scale organizations, and I think you probably have no idea how much of a huge hassle is created by features that can't be undone or disabled at run time. It is not feasible to reboot every machine in one's datacenter to turn off a feature that's causing problems. Yet that's what some large scale organizations end up having to do, and it's COMPLETELY NOT ACCEPTABLT that they have to do this. So instead of trying to figure out ways to use things other than ethtool, work instead to eliminate all situations where a feature cannot be disabled/undone after probe time. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 Machine version | of the firmware Ethernet TX Packet Work Request (FW_ETH_TX_PKT_VM_WR) | instead of the normal default non-VM Work Request (FW_ETH_TX_PKT_WR). | | Sorry, module parameters are veboten. | | Especially for settings like this which are guaranteed to be | interesting for other NIC drivers, not just your's. | | I'm really tired of explaining this to driver authors. Just | don't even try to push a module parameter past me. I definitely understand the issue of wanting to avoid randomly different module parameters in various drivers which do similar things. What we're looking for is a list of the acceptable ways for doing things — especially when they don't fit current ethtool/ioctl() mechanisms. A couple of specific examples: 1. We need to load the driver and tell it _not_ to attempt to contact firmware on the adapter. This is typically used to load firmware on a brand new adapter or debug a problem with the adapter without changing its existing state. This need presents an awkward problem because we need to have the driver know from the very start that it shouldn't try to communicate with the firmware, while our normal PCI probe() does in fact contact the firmware as part of the probe ... 2. This patch: We have the ability to use two fundamentally different TX Work Requests — one which causes the adapter firmware to check for local loopback delivery targets and one which doesn't. Unlike the first example, this can be specified long after the adapter probe operation but it's unclear if there's any current ethtool/ioctl() which can be used for this. Should we suggest a new ethtool operation like TX Method? More generally, is there a document somewhere which already covers the suggested mechanisms for passing parameter information into network drivers for different cases so we don't send in patch requests which waste people's time? Casey-- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 1/3] cxgb4: Add support for loopback between VI of same port
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 Machine version of the firmware Ethernet TX Packet Work Request (FW_ETH_TX_PKT_VM_WR) instead of the normal default non-VM Work Request (FW_ETH_TX_PKT_WR). This allows TX Packets sent by the cxgb4 PF Driver to be subject to the firmware's MPS TCAM Lookup and therefore elligable for loop back to other Virtual interfaces on the same port. This is useful for communicating with Virtual machines running the VF Driver (cxgb4vf) and also for interesting layered service applications. Enabling it by default lowers the performance, so maybe module parameter is the right way to this. Based on original work by Casey Leedom lee...@chelsio.com Signed-off-by: Hariprasad Shenai haripra...@chelsio.com Sorry, module parameters are veboten. Especially for settings like this which are guaranteed to be interesting for other NIC drivers, not just your's. I'm really tired of explaining this to driver authors. Just don't even try to push a module parameter past me. Thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
