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
| ||
|
Date: Sat, 12 Dec 2009 18:33:19 -0800 From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@...el.com> To: David Miller <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org> Cc: Eric Dumazet <eric.dumazet@...il.com>, mchan@...adcom.com, "bhutchings@...arflare.com" <bhutchings@...arflare.com>, linville@...driver.com, shemminger@...ux-foundation.org, "Brandeburg, Jesse" <jesse.brandeburg@...el.com>, "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com> Subject: RFC: ethtool: add device-specific feature support in a generic fashion This is a follow-up to my first RFC, getting opinions where the best place to put device-specific feature toggling would be. The feedback I received was to look at doing this in ethtool. Below is a high-level design of what I'd like to do, and wanted to vet this with the community to see if this is aligned with what people would like to see. The general idea is to have a generic framework in ethtool to enumerate device-specific commands. A sample structure that would represent each of these commands is: enum oem_cmds { OEM_CMD_0 = 0, OEM_CMD_1, OEM_CMD_2, ... etc. ... }; struct oem_feature_cmd { /* Description of the feature */ char *description; /* Does the feature toggling requires a device reset */ u8 require_reset; /* The command-line name for the command */ char *oem_cmd_name; /* The command number assigned to this */ u32 oem_cmd; /* value for the command */ u32 oem_cmd_val; }; Now underlying drivers would implement as many of these commands as needed, and assign strings to each. These strings, in oem_cmd_name, would be used by ethtool in userspace to parse the command line properly. The reason I included a field that indicates whether a reset is required or not is to support features that require multiple commands to be synchronously programmed. An example is ixgbe's Flow Director. FDIR has a number of knobs, specifically what filtering mode to use (hash or perfect match), number of filters to use, and how often to sample Tx packets (assumes hash mode). This way a user could set all three options, then issue "ethtool -r ethX" to apply them. An example of features ixgbe could implement, using the above framework, would be: - oem_cmd = OEM_CMD1 - oem_cmd_name = "fdir_filter_mode" - require_reset = 1 - description = "Set filtering mode for Flow Director. 0 = off, 1 = hash (default), 2 = perfect" - oem_cmd = OEM_CMD2 - oem_cmd_name = "fdir_num_filters" - require_reset = 1 - description = "How many filters to support: 0 = 2k perfect/8k hash (default), 1 = 4k perfect/16k hash, 2 = 8k perfect/32k hash" - oem_cmd = OEM_CMD3 - oem_cmd_name = "num_vfs" - require_reset = 1 - description = "Number of Virtual Functions to enable. This only takes effect when SR-IOV is enabled." - oem_cmd = OEM_CMD4 - oem_cmd_name = "enable_sriov" - require_reset = 0 - description = "Enables SR-IOV in the device." The general flow would be ethtool would read all commands the underlying device supports, then would use that to parse the command line. Assuming the command parses correctly, the configuration would then be sent through the ioctl() to the driver. This framework is a basic substitute for module parameters, which our upstream drivers do not include. The advantage here is any commands that a driver wishes to add, to enable a new feature in hardware, would not require ethtool to change. The command is simply added to the driver, and this framework will pick up the new command. Any comments, questions, or suggestions are much appreciated. Cheers, -PJ Waskiewicz -- 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
Powered by blists - more mailing lists