From: Jakub Kicinski <kuba@kernel•org>
To: Vladimir Oltean <vladimir.oltean@nxp•com>
Cc: Vladimir Oltean <olteanv@gmail•com>,
"netdev@vger•kernel.org" <netdev@vger•kernel.org>,
"David S. Miller" <davem@davemloft•net>,
Eric Dumazet <edumazet@google•com>,
Paolo Abeni <pabeni@redhat•com>,
Xiaoliang Yang <xiaoliang.yang_1@nxp•com>,
Rui Sousa <rui.sousa@nxp•com>,
Claudiu Manoil <claudiu.manoil@nxp•com>,
Alexandre Belloni <alexandre.belloni@bootlin•com>,
"UNGLinuxDriver@microchip•com" <UNGLinuxDriver@microchip•com>,
Horatiu Vultur <horatiu.vultur@microchip•com>,
Andrew Lunn <andrew@lunn•ch>,
Vivien Didelot <vivien.didelot@gmail•com>,
Florian Fainelli <f.fainelli@gmail•com>,
Michael Walle <michael@walle•cc>,
Vinicius Costa Gomes <vinicius.gomes@intel•com>,
Maxim Kochetkov <fido_max@inbox•ru>,
Colin Foster <colin.foster@in-advantage•com>,
Richie Pearn <richard.pearn@nxp•com>,
Kurt Kanzenbach <kurt@linutronix•de>,
Jesse Brandeburg <jesse.brandeburg@intel•com>,
Tony Nguyen <anthony.l.nguyen@intel•com>,
Giuseppe Cavallaro <peppe.cavallaro@st•com>,
Alexandre Torgue <alexandre.torgue@foss•st.com>,
Jose Abreu <joabreu@synopsys•com>,
Jamal Hadi Salim <jhs@mojatatu•com>,
Cong Wang <xiyou.wangcong@gmail•com>,
Jiri Pirko <jiri@resnulli•us>,
Gerhard Engleder <gerhard@engleder-embedded•com>
Subject: Re: [PATCH v2 net-next 02/12] tsnep: deny tc-taprio changes to per-tc max SDU
Date: Mon, 26 Sep 2022 17:43:33 -0700 [thread overview]
Message-ID: <20220926174333.15dbca47@kernel.org> (raw)
In-Reply-To: <20220927002252.mwrxp3wicew3vz6p@skbuf>
On Tue, 27 Sep 2022 00:22:53 +0000 Vladimir Oltean wrote:
> On Mon, Sep 26, 2022 at 04:29:34PM -0700, Jakub Kicinski wrote:
> > I usually put a capability field into the ops themselves.
>
> Do you also have an example for the 'usual' manner?
struct devlink_ops {
/**
* @supported_flash_update_params:
* mask of parameters supported by the driver's .flash_update
* implemementation.
*/
u32 supported_flash_update_params;
unsigned long reload_actions;
unsigned long reload_limits;
struct ethtool_ops {
u32 cap_link_lanes_supported:1;
u32 supported_coalesce_params;
u32 supported_ring_params;
> > Right, but that's what's in the tree _now_. Experience teaches that
> > people may have out of tree code which implements TAPRIO and may send
> > it for upstream review without as much as testing it against net-next :(
> > As time passes and our memories fade the chances we'd catch such code
> > when posted upstream go down, perhaps from high to medium but still,
> > the explicit opt-in is more foolproof.
>
> You also need to see the flip side. You're making code more self-maintainable
> by adding bureaucracy to the run time itself. Whereas things could have
> been sorted out between the qdisc and the driver in just one ndo_setup_tc()
> call via the straightforward approach (every driver rejects what it
> doesn't like), now you need two calls for the normal case when the
> driver will accept a valid configuration.
Right, the lack of a structure we can put it in is quite unfortunate :(
But I do not dare suggesting we add a structure with qdisc and cls
specific callbacks instead of the mux-y ndo_setup_tc :)
I guess we could take a shortcut and put a pointer in netdev_ops for
just the caps for now, hm.
> I get the point and I think this won't probably make a big difference
> for a slow path like qdisc offload (at least it won't for me), but from
> an API perspective, once the mechanism will go in, it will become quite
> ossified, so it's best to ask some questions about it now.
>
> Like for example you're funneling the caps through ndo_setup_tc(), which
> has these comments in its description:
>
> * int (*ndo_setup_tc)(struct net_device *dev, enum tc_setup_type type,
> * void *type_data);
> * Called to setup any 'tc' scheduler, classifier or action on @dev.
> * This is always called from the stack with the rtnl lock held and netif
> * tx queues stopped. This allows the netdevice to perform queue
> * management safely.
>
> Do we need to offer guarantees of rtnl lock and stopped TX queues to a
> function which just queries capabilities (and likely doesn't need them),
> or would it be better to devise a new ndo?
The queues stopped part is not true already for classifier offloads :(
> Generally, when you have a
> separate method to query caps vs to actually do the work, different
> calling contexts is generally the justification to do that, as opposed
> to piggy-backing the caps that the driver acted upon through the same
> struct tc_taprio_qopt_offload.
If we add a new pointer for netdev_ops I'd go with a struct pointer
rather than an op, for consistency if nothing else. But if you feel
strongly either way will work.
next prev parent reply other threads:[~2022-09-27 0:43 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-23 16:32 [PATCH v2 net-next 00/12] Add tc-taprio support for queueMaxSDU Vladimir Oltean
2022-09-23 16:32 ` [PATCH v2 net-next 01/12] net/sched: taprio: allow user input of per-tc max SDU Vladimir Oltean
2022-09-26 20:38 ` Jakub Kicinski
2022-09-27 15:09 ` Vladimir Oltean
2022-09-27 18:27 ` Jakub Kicinski
2022-09-27 21:23 ` Vladimir Oltean
2022-09-27 21:32 ` Jakub Kicinski
2022-09-23 16:33 ` [PATCH v2 net-next 02/12] tsnep: deny tc-taprio changes to " Vladimir Oltean
2022-09-26 20:40 ` Jakub Kicinski
2022-09-26 21:50 ` Vladimir Oltean
2022-09-26 23:29 ` Jakub Kicinski
2022-09-27 0:22 ` Vladimir Oltean
2022-09-27 0:43 ` Jakub Kicinski [this message]
2022-09-23 16:33 ` [PATCH v2 net-next 03/12] igc: " Vladimir Oltean
2022-09-23 16:33 ` [PATCH v2 net-next 04/12] net: stmmac: " Vladimir Oltean
2022-09-23 16:33 ` [PATCH v2 net-next 05/12] net: am65-cpsw: " Vladimir Oltean
2022-09-23 16:33 ` [PATCH v2 net-next 06/12] net: lan966x: " Vladimir Oltean
2022-09-23 16:33 ` [PATCH v2 net-next 07/12] net: dsa: sja1105: " Vladimir Oltean
2022-09-23 16:33 ` [PATCH v2 net-next 08/12] net: dsa: felix: offload per-tc max SDU from tc-taprio Vladimir Oltean
2022-09-23 16:33 ` [PATCH v2 net-next 09/12] net: dsa: hellcreek: Offload " Vladimir Oltean
2022-09-23 16:33 ` [PATCH v2 net-next 10/12] net: enetc: cache accesses to &priv->si->hw Vladimir Oltean
2022-09-23 16:33 ` [PATCH v2 net-next 11/12] net: enetc: use common naming scheme for PTGCR and PTGCAPR registers Vladimir Oltean
2022-09-23 16:33 ` [PATCH v2 net-next 12/12] net: enetc: offload per-tc max SDU from tc-taprio Vladimir Oltean
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=20220926174333.15dbca47@kernel.org \
--to=kuba@kernel$(echo .)org \
--cc=UNGLinuxDriver@microchip$(echo .)com \
--cc=alexandre.belloni@bootlin$(echo .)com \
--cc=alexandre.torgue@foss$(echo .)st.com \
--cc=andrew@lunn$(echo .)ch \
--cc=anthony.l.nguyen@intel$(echo .)com \
--cc=claudiu.manoil@nxp$(echo .)com \
--cc=colin.foster@in-advantage$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=f.fainelli@gmail$(echo .)com \
--cc=fido_max@inbox$(echo .)ru \
--cc=gerhard@engleder-embedded$(echo .)com \
--cc=horatiu.vultur@microchip$(echo .)com \
--cc=jesse.brandeburg@intel$(echo .)com \
--cc=jhs@mojatatu$(echo .)com \
--cc=jiri@resnulli$(echo .)us \
--cc=joabreu@synopsys$(echo .)com \
--cc=kurt@linutronix$(echo .)de \
--cc=michael@walle$(echo .)cc \
--cc=netdev@vger$(echo .)kernel.org \
--cc=olteanv@gmail$(echo .)com \
--cc=pabeni@redhat$(echo .)com \
--cc=peppe.cavallaro@st$(echo .)com \
--cc=richard.pearn@nxp$(echo .)com \
--cc=rui.sousa@nxp$(echo .)com \
--cc=vinicius.gomes@intel$(echo .)com \
--cc=vivien.didelot@gmail$(echo .)com \
--cc=vladimir.oltean@nxp$(echo .)com \
--cc=xiaoliang.yang_1@nxp$(echo .)com \
--cc=xiyou.wangcong@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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