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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 20 Nov 2022 22:02:17 +0100 From: Michal Kubecek <mkubecek@...e.cz> To: "Mogilappagari, Sudheer" <sudheer.mogilappagari@...el.com> Cc: Francois Romieu <romieu@...zoreil.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "kuba@...nel.org" <kuba@...nel.org>, "andrew@...n.ch" <andrew@...n.ch>, "corbet@....net" <corbet@....net>, "Samudrala, Sridhar" <sridhar.samudrala@...el.com>, "Nguyen, Anthony L" <anthony.l.nguyen@...el.com> Subject: Re: [PATCH net-next v3] ethtool: add netlink based get rss support On Sun, Nov 20, 2022 at 08:40:19AM +0000, Mogilappagari, Sudheer wrote: > > -----Original Message----- > > From: Francois Romieu <romieu@...zoreil.com> > > Subject: Re: [PATCH net-next v3] ethtool: add netlink based get rss > > support > > > > Sudheer Mogilappagari <sudheer.mogilappagari@...el.com> : > > > Add netlink based support for "ethtool -x <dev> [context x]" > > > command by implementing ETHTOOL_MSG_RSS_GET netlink message. > > > This is equivalent to functionality provided via ETHTOOL_GRSSH > > ^^^^^^^^^^^^^ > > Nit: s/ETHTOOL_GRSSH/ETHTOOL_GRXFH/ > > > > Hi Ueimor, > My observation is there is mix-up of names in current ioctl implementation where ethtool_get_rxfh() is called for ETHTOOL_GRSSH command. Since this implementation is for ETHTOOL_GRSSH ioctl, we are using RSS instead of RXFH as Jakub suggested earlier. Why do you think it should be ETHOOL_GRXFH ? > > https://elixir.bootlin.com/linux/latest/source/net/ethtool/ioctl.c#L2916 > > case ETHTOOL_GRXFH: > rc = ethtool_get_rxnfc(dev, ethcmd, useraddr); > > case ETHTOOL_GRSSH: > rc = ethtool_get_rxfh(dev, useraddr); > > -Sudheer The mapping between ioctl subcommand and netlink message types does not have to be 1:1, new ioctl subcommands were often added just because the structures passed via ioctl could not be extended. In this case, ETHTOOL_MSG_RSS_GET would reimplement ETHTOOL_GRSSH as well as ETHTOOL_GRXFHINDIR, and ETHTOOL_MSG_RSS_SET would reimplement ETHTOOL_SRSSH as well as ETHTOOL_SRXFHINDIR. It's IMHO clear that there should be a GET/SET pair of messages for RSS hash configuration (ethtool -n rx-flow-hash) and one for RSS rule configuration (ethtool -n rule). That would leave us with two questions: 1. What to do with ETHTOOL_GRXRING? Can we use ETHTOOL_MSG_RINGS_GET as it is? (I.e. should the count be always equal to rx + combined?) If not, should we extend it or put the count into ETHTOOL_MSG_RSS_GET? 2. What would be the best way to handle creation and deletion of RSS contexts? I guess either a separate message type or combining the functionality into ETHTOOL_MSG_RSS_SET somehow (but surely not via some magic values like it's done in ioctl). Michal
Powered by blists - more mailing lists