From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Wei Fang <wei.fang@nxp.com>
Cc: Claudiu Manoil <claudiu.manoil@nxp.com>,
Clark Wang <xiaoning.wang@nxp.com>,
"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"imx@lists.linux.dev" <imx@lists.linux.dev>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 net-next 02/14] net: enetc: add command BD ring support for i.MX95 ENETC
Date: Fri, 14 Mar 2025 13:18:01 +0200 [thread overview]
Message-ID: <20250314111801.2oela3qoi5qrl6el@skbuf> (raw)
In-Reply-To: <PAXPR04MB8510D3A2F2A792A89941A7FD88D22@PAXPR04MB8510.eurprd04.prod.outlook.com>
On Fri, Mar 14, 2025 at 06:51:06AM +0200, Wei Fang wrote:
> > I don't understand the need for si->ops->setup_cbdr() and
> > si->ops->teardown_cbdr()?
> > Doesn't every call site know which kind of SI it is dealing with, and thus it can
> > appropriately call the direct symbol?
> > - the v1 PSI and the VSI call enetc_setup_cbdr() and enetc_teardown_cbdr()
> > - the v4 PSI calls enetc4_setup_cbdr() and enetc4_teardown_cbdr()
>
> Yes, for PSI we can use directly call these functions because they are different
> drivers, but for VSI, v1 and v4 will use the same driver. I just want the PSI and
> VSI to be consistent. If you don't like this, I can remove these interfaces from
> the patch set, and add vf_setup_cbdr and vf_teardown_cbdr in the future when
> I add the VF support for ENETC v4.
It's not that I don't like them, the point is rather simple: as far as
this patch set is concerned, converting direct function calls to
indirect ones is an unfinished idea. It needs to be evaluated in full
context, which is not present here - as you say, v4 VSIs need to be
further modified to call a different set of operations - but right now,
they call a single set of CBDR functions. Changes which require
subsequent patch sets in order to make any sense at all are discouraged.
Given the fact that the PSI code paths still don't benefit from an
indirect function call in any way, I would in principle recommend to
keep calling their CBDR methods directly. For VSIs I don't know which is
preferable (if-else vs function pointer), I need to see that code first.
next prev parent reply other threads:[~2025-03-14 11:20 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-11 5:38 [PATCH v4 net-next 00/14] Add more feautues for ENETC v4 - round 2 Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 01/14] net: enetc: add initial netc-lib driver to support NTMP Wei Fang
2025-03-11 12:17 ` Michal Kubiak
2025-03-13 16:35 ` Vladimir Oltean
2025-03-14 3:38 ` Wei Fang
2025-03-14 12:37 ` Vladimir Oltean
2025-03-14 13:48 ` Wei Fang
2025-03-17 9:28 ` Vladimir Oltean
2025-03-17 9:55 ` Wei Fang
2025-03-17 10:00 ` Vladimir Oltean
2025-03-17 11:39 ` Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 02/14] net: enetc: add command BD ring support for i.MX95 ENETC Wei Fang
2025-03-11 12:22 ` Michal Kubiak
2025-03-13 16:49 ` Vladimir Oltean
2025-03-14 4:51 ` Wei Fang
2025-03-14 11:18 ` Vladimir Oltean [this message]
2025-03-14 13:56 ` Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 03/14] net: enetc: move generic MAC filterng interfaces to enetc-core Wei Fang
2025-03-17 9:42 ` Vladimir Oltean
2025-03-17 10:00 ` Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 04/14] net: enetc: add MAC filter for i.MX95 ENETC PF Wei Fang
2025-03-17 14:18 ` Vladimir Oltean
2025-03-18 3:19 ` Wei Fang
2025-03-18 9:29 ` Vladimir Oltean
2025-03-18 9:48 ` Wei Fang
2025-03-18 8:08 ` Claudiu Manoil
2025-03-18 8:47 ` Vladimir Oltean
2025-03-11 5:38 ` [PATCH v4 net-next 05/14] net: enetc: add debugfs interface to dump MAC filter Wei Fang
2025-03-17 14:48 ` Vladimir Oltean
2025-03-18 3:28 ` Wei Fang
2025-03-18 14:54 ` Vladimir Oltean
2025-03-11 5:38 ` [PATCH v4 net-next 06/14] net: enetc: add set/get_rss_table() to enetc_si_ops Wei Fang
2025-03-17 16:42 ` Vladimir Oltean
2025-03-18 5:06 ` Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 07/14] net: enetc: make enetc_set_rss_key() reusable Wei Fang
2025-03-17 16:26 ` Vladimir Oltean
2025-03-18 4:54 ` Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 08/14] net: enetc: add RSS support for i.MX95 ENETC PF Wei Fang
2025-03-17 15:55 ` Vladimir Oltean
2025-03-18 4:47 ` Wei Fang
2025-03-18 11:43 ` Vladimir Oltean
2025-03-18 14:00 ` Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 09/14] net: enetc: enable RSS feature by default Wei Fang
2025-03-17 16:33 ` Vladimir Oltean
2025-03-18 5:00 ` Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 10/14] net: enetc: move generic VLAN filter interfaces to enetc-core Wei Fang
2025-03-17 17:05 ` Vladimir Oltean
2025-03-18 5:12 ` Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 11/14] net: enetc: move generic VLAN hash filter functions to enetc_pf_common.c Wei Fang
2025-03-18 10:21 ` Vladimir Oltean
2025-03-18 13:57 ` Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 12/14] net: enetc: add VLAN filtering support for i.MX95 ENETC PF Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 13/14] net: enetc: add loopback " Wei Fang
2025-03-11 5:38 ` [PATCH v4 net-next 14/14] MAINTAINERS: add new file ntmp.h to ENETC driver Wei Fang
2025-03-17 17:06 ` Vladimir Oltean
2025-03-18 5:13 ` Wei Fang
2025-03-13 13:50 ` [PATCH v4 net-next 00/14] Add more feautues for ENETC v4 - round 2 Vladimir Oltean
2025-03-14 1:28 ` Wei Fang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250314111801.2oela3qoi5qrl6el@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=andrew+netdev@lunn.ch \
--cc=christophe.leroy@csgroup.eu \
--cc=claudiu.manoil@nxp.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=imx@lists.linux.dev \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=wei.fang@nxp.com \
--cc=xiaoning.wang@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox