[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211025104505.43461b53@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Mon, 25 Oct 2021 10:45:05 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Marc Kleine-Budde <mkl@...gutronix.de>
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 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.
Powered by blists - more mailing lists