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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 May 2015 16:36:00 +0000
From:	Casey Leedom <leedom@...lsio.com>
To:	David Miller <davem@...emloft.net>,
	Hariprasad S <hariprasad@...lsio.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Nirranjan Kirubaharan <nirranjan@...lsio.com>
Subject: RE: [PATCH net-next 1/3] cxgb4: Add support for loopback between VI
 of same port

| From: David Miller [davem@...emloft.net]
| Sent: Sunday, May 17, 2015 8:46 PM
| 
| > From: Hariprasad Shenai <hariprasad@...lsio.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html