| 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
