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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 20 Nov 2022 22:02:17 +0100
From:   Michal Kubecek <>
To:     "Mogilappagari, Sudheer" <>
Cc:     Francois Romieu <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "Samudrala, Sridhar" <>,
        "Nguyen, Anthony L" <>
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 <>
> > Subject: Re: [PATCH net-next v3] ethtool: add netlink based get rss
> > support
> > 
> > Sudheer Mogilappagari <> :
> > > 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
> >                                                    ^^^^^^^^^^^^^
> > 
> 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 ?
> 		rc = ethtool_get_rxnfc(dev, ethcmd, useraddr);
> 		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

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).


Powered by blists - more mailing lists