[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211025185040.xj27ujo5wubirz6u@pengutronix.de>
Date: Mon, 25 Oct 2021 20:50:40 +0200
From: Marc Kleine-Budde <mkl@...gutronix.de>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Guangbin Huang <huangguangbin2@...wei.com>, davem@...emloft.net,
mkubecek@...e.cz, andrew@...n.ch, amitc@...lanox.com,
idosch@...sch.org, danieller@...dia.com,
jesse.brandeburg@...el.com, anthony.l.nguyen@...el.com,
jdike@...toit.com, richard@....at, anton.ivanov@...bridgegreys.com,
netanel@...zon.com, akiyano@...zon.com, saeedb@...zon.com,
chris.snook@...il.com, ulli.kroll@...glemail.com,
linus.walleij@...aro.org, jeroendb@...gle.com, csully@...gle.com,
awogbemila@...gle.com, jdmason@...zu.us, rain.1986.08.12@...il.com,
zyjzyj2000@...il.com, kys@...rosoft.com, haiyangz@...rosoft.com,
mst@...hat.com, jasowang@...hat.com, doshir@...are.com,
pv-drivers@...are.com, jwi@...ux.ibm.com, kgraul@...ux.ibm.com,
hca@...ux.ibm.com, gor@...ux.ibm.com, johannes@...solutions.net,
netdev@...r.kernel.org, lipeng321@...wei.com,
chenhao288@...ilicon.com, linux-s390@...r.kernel.org
Subject: Re: [PATCH V4 net-next 4/6] ethtool: extend ringparam setting uAPI
with rx_buf_len
On 25.10.2021 10:45:05, Jakub Kicinski wrote:
> On Mon, 25 Oct 2021 15:27:18 +0200 Marc Kleine-Budde wrote:
> > On 25.10.2021 15:11:49, Marc Kleine-Budde wrote:
> > > On 14.10.2021 19:39:41, Guangbin Huang wrote:
> > > > From: Hao Chen <chenhao288@...ilicon.com>
> > > >
> > > > Add two new parameters ringparam_ext and extack for
> > > > .get_ringparam and .set_ringparam to extend more ring params
> > > > through netlink.
> > > >
> > > > Signed-off-by: Hao Chen <chenhao288@...ilicon.com>
> > > > Signed-off-by: Guangbin Huang <huangguangbin2@...wei.com>
> > >
> > > While discussing a different ethtool ring param extension,
> >
> > Let me explain my requirements:
> >
> > There is a not Ethernet based bus system, called CAN (mainly used in the
> > automotive and industrial world). It comes in 2 different generations or
> > modes (CAN-2.0 and CAN-FD) and the 3rd one CAN-XL has already been
> > specified.
> >
> > Due to different frame sizes used in these CAN modes and HW limitations,
> > we need the possibility to set a RX/TX ring configuration for each of
> > these modes.
> >
> > The approach Andrew suggested is two-fold. First introduce a "struct
> > ethtool_kringparam" that's only used inside the kernel, as "struct
> > ethtool_ringparam" is ABI. Then extend "struct ethtool_kringparam" as
> > needed.
>
> Indeed, there are different ways to extend the API for drivers,
> I think it comes down to personal taste. I find the "inheritance"
> models in C (kstruct usually contains the old struct as some "base")
> awkward.
>
> I don't think we have agreed-on best practice in the area.
The set/get_coalesce as just extended, using a 3rd parameter for the new
values:
| int (*set_coalesce)(struct net_device *,
| struct ethtool_coalesce *,
| struct kernel_ethtool_coalesce *,
| struct netlink_ext_ack *);
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=f3ccfda19319
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists