netdev - Re: [PATCH net-next v3] ethtool: add netlink based get rss support

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]

Message-ID: <20221120210217.zcdmr47r6ck33cf4@lion.mk-sys.cz>
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