diff mbox series

[1/1] DSA Add callback to traffic control information

Message ID 20220411131148.532520-2-erez.geva.ext@siemens.com (mailing list archive)
State Changes Requested
Delegated to: Netdev Maintainers
Headers show
Series Add DSA callback to traffic control information | expand

Checks

Context Check Description
netdev/fixes_present success Fixes tag not required for -next series
netdev/subject_prefix warning Target tree name not specified in the subject
netdev/cover_letter success Series has a cover letter
netdev/patch_count success Link
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 19 this patch: 19
netdev/cc_maintainers warning 3 maintainers not CCed: davem@davemloft.net kuba@kernel.org pabeni@redhat.com
netdev/build_clang success Errors and warnings before: 17 this patch: 17
netdev/module_param success Was 0 now: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 19 this patch: 19
netdev/checkpatch warning WARNING: line length of 88 exceeds 80 columns WARNING: line length of 89 exceeds 80 columns
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
netdev/tree_selection success Guessing tree name failed - patch did not apply

Commit Message

Geva, Erez April 11, 2022, 1:11 p.m. UTC
Provide a callback for the DSA tag driver
 to fetch information regarding a traffic control.

Signed-off-by: Erez Geva <erez.geva.ext@siemens.com>
---
 include/net/dsa.h  |  2 ++
 net/dsa/dsa_priv.h |  1 +
 net/dsa/slave.c    | 17 +++++++++++++++++
 3 files changed, 20 insertions(+)

Comments

Andrew Lunn April 11, 2022, 1:29 p.m. UTC | #1
On Mon, Apr 11, 2022 at 03:11:48PM +0200, Erez Geva wrote:
> Provide a callback for the DSA tag driver
>  to fetch information regarding a traffic control.

Hi Erez

When you add a new API you also need to add a user of it. Please
include your tag driver change in the patchset.

	Andrew
Vladimir Oltean April 11, 2022, 1:29 p.m. UTC | #2
On Mon, Apr 11, 2022 at 03:11:48PM +0200, Erez Geva wrote:
> Provide a callback for the DSA tag driver
>  to fetch information regarding a traffic control.
> 
> Signed-off-by: Erez Geva <erez.geva.ext@siemens.com>
> ---

This is all? Can you show us some users?
Geva, Erez April 11, 2022, 2:17 p.m. UTC | #3
The Tag driver code in not by me.
So I can not publish it, only the owner may.

Erez

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch> 
Sent: Monday, 11 April 2022 15:29
To: Geva, Erez (ext) (DI PA DCP R&D 3) <erez.geva.ext@siemens.com>
Cc: netdev@vger.kernel.org; Vivien Didelot <vivien.didelot@gmail.com>; Florian Fainelli <f.fainelli@gmail.com>; Vladimir Oltean <olteanv@gmail.com>; Sudler, Simon (DI PA DCP TI) <simon.sudler@siemens.com>; Meisinger, Andreas (DI PA DCP TI) <andreas.meisinger@siemens.com>; Schild, Henning (T CED SES-DE) <henning.schild@siemens.com>; Kiszka, Jan (T CED) <jan.kiszka@siemens.com>
Subject: Re: [PATCH 1/1] DSA Add callback to traffic control information

On Mon, Apr 11, 2022 at 03:11:48PM +0200, Erez Geva wrote:
> Provide a callback for the DSA tag driver  to fetch information 
> regarding a traffic control.

Hi Erez

When you add a new API you also need to add a user of it. Please include your tag driver change in the patchset.

	Andrew
Geva, Erez April 11, 2022, 2:23 p.m. UTC | #4
As I mention, I do not own the tag driver code.

But for example for ETF, is like:

... tag_xmit(struct sk_buff *skb, struct net_device *dev)
+       struct tc_etf_qopt_offload etf;
...
+       etf.queue = skb_get_queue_mapping(skb);
+       if (dsa_slave_fetch_tc(dev, TC_SETUP_QDISC_ETF, &etf) == 0 && etf.enable) {
...

The port_fetch_tc callback is similar to port_setup_tc, only it reads the configuration instead of setting it.

I think it is easier to add a generic call back, so we do not need to add a new callback each time we support a new TC.

Erez



-----Original Message-----
From: Vladimir Oltean <olteanv@gmail.com> 
Sent: Monday, 11 April 2022 15:30
To: Geva, Erez (ext) (DI PA DCP R&D 3) <erez.geva.ext@siemens.com>
Cc: netdev@vger.kernel.org; Andrew Lunn <andrew@lunn.ch>; Vivien Didelot <vivien.didelot@gmail.com>; Florian Fainelli <f.fainelli@gmail.com>; Sudler, Simon (DI PA DCP TI) <simon.sudler@siemens.com>; Meisinger, Andreas (DI PA DCP TI) <andreas.meisinger@siemens.com>; Schild, Henning (T CED SES-DE) <henning.schild@siemens.com>; Kiszka, Jan (T CED) <jan.kiszka@siemens.com>
Subject: Re: [PATCH 1/1] DSA Add callback to traffic control information

On Mon, Apr 11, 2022 at 03:11:48PM +0200, Erez Geva wrote:
> Provide a callback for the DSA tag driver  to fetch information 
> regarding a traffic control.
> 
> Signed-off-by: Erez Geva <erez.geva.ext@siemens.com>
> ---

This is all? Can you show us some users?
Andrew Lunn April 11, 2022, 2:25 p.m. UTC | #5
On Mon, Apr 11, 2022 at 02:17:44PM +0000, Geva, Erez wrote:
> The Tag driver code in not by me.
> So I can not publish it, only the owner may.

If the code is licensed GPL, and you can fulfil the requirements of
adding a Signed-off-by: you can submit it.

However until there is a user of this, sorry, this patch will not be
accepted.

     Andrew
Geva, Erez April 11, 2022, 2:29 p.m. UTC | #6
Although the code is GPL, as the code comes with Hardware,
And the Hardware belong to a third party ...

I understand the reason for users. But like ant rule. It should be used properly.

This patch is really small and could solve many future TC issues.

The current state of many TC callbacks does not make sense.
May be it is time to do some cleaning?

Just hope a light the way.

Erez

-----Original Message-----
From: Andrew Lunn <andrew@lunn.ch> 
Sent: Monday, 11 April 2022 16:26
To: Geva, Erez (ext) (DI PA DCP R&D 3) <erez.geva.ext@siemens.com>
Cc: netdev@vger.kernel.org; Vivien Didelot <vivien.didelot@gmail.com>; Florian Fainelli <f.fainelli@gmail.com>; Vladimir Oltean <olteanv@gmail.com>; Sudler, Simon (DI PA DCP TI) <simon.sudler@siemens.com>; Meisinger, Andreas (DI PA DCP TI) <andreas.meisinger@siemens.com>; Schild, Henning (T CED SES-DE) <henning.schild@siemens.com>; Kiszka, Jan (T CED) <jan.kiszka@siemens.com>
Subject: Re: [PATCH 1/1] DSA Add callback to traffic control information

On Mon, Apr 11, 2022 at 02:17:44PM +0000, Geva, Erez wrote:
> The Tag driver code in not by me.
> So I can not publish it, only the owner may.

If the code is licensed GPL, and you can fulfil the requirements of adding a Signed-off-by: you can submit it.

However until there is a user of this, sorry, this patch will not be accepted.

     Andrew
Vladimir Oltean April 11, 2022, 2:43 p.m. UTC | #7
On Mon, Apr 11, 2022 at 02:23:59PM +0000, Geva, Erez wrote:
> As I mention, I do not own the tag driver code.
> 
> But for example for ETF, is like:
> 
> ... tag_xmit(struct sk_buff *skb, struct net_device *dev)
> +       struct tc_etf_qopt_offload etf;
> ...
> +       etf.queue = skb_get_queue_mapping(skb);
> +       if (dsa_slave_fetch_tc(dev, TC_SETUP_QDISC_ETF, &etf) == 0 && etf.enable) {
> ...
> 
> The port_fetch_tc callback is similar to port_setup_tc, only it reads the configuration instead of setting it.
> 
> I think it is easier to add a generic call back, so we do not need to add a new callback each time we support a new TC.
> 
> Erez

Since kernel v5.17 there exists struct dsa_device_ops :: connect() which
allows tagging protocol drivers to store persistent data for each switch.
Switch drivers also have a struct dsa_switch_ops :: connect_tag_protocol()
through which they can fix up or populate stuff in the tagging protocol
driver's private storage.
What you could do is set up something lockless, or even a function
pointer, to denote whether TX queue X is set up for ETF or not.

In any case, demanding that code with no in-kernel user gets accepted
will get a hard no, no matter how small it is.
Andrew Lunn April 11, 2022, 2:48 p.m. UTC | #8
> The current state of many TC callbacks does not make sense.
> May be it is time to do some cleaning?

Feel free, and if that makes your new call useful, you can get it
merged that way.

Historically, we have tried to keep the taggers independent of the
switch driver. That is not always possible. But developers do combine
the loop DSA driver with any random tag drivers at times, so please be
careful with any cleanup to ensure you check for unexpected
combinations and -EOPNOTSUPP etc.

	Andrew
Geva, Erez April 11, 2022, 2:49 p.m. UTC | #9
-----Original Message-----
From: Vladimir Oltean <olteanv@gmail.com> 
Sent: Monday, 11 April 2022 16:43
To: Geva, Erez (ext) (DI PA DCP R&D 3) <erez.geva.ext@siemens.com>
Cc: netdev@vger.kernel.org; Andrew Lunn <andrew@lunn.ch>; Vivien Didelot <vivien.didelot@gmail.com>; Florian Fainelli <f.fainelli@gmail.com>; Sudler, Simon (DI PA DCP TI) <simon.sudler@siemens.com>; Meisinger, Andreas (DI PA DCP TI) <andreas.meisinger@siemens.com>; Schild, Henning (T CED SES-DE) <henning.schild@siemens.com>; Kiszka, Jan (T CED) <jan.kiszka@siemens.com>
Subject: Re: [PATCH 1/1] DSA Add callback to traffic control information

On Mon, Apr 11, 2022 at 02:23:59PM +0000, Geva, Erez wrote:
> As I mention, I do not own the tag driver code.
> 
> But for example for ETF, is like:
> 
> ... tag_xmit(struct sk_buff *skb, struct net_device *dev)
> +       struct tc_etf_qopt_offload etf;
> ...
> +       etf.queue = skb_get_queue_mapping(skb);
> +       if (dsa_slave_fetch_tc(dev, TC_SETUP_QDISC_ETF, &etf) == 0 && 
> + etf.enable) {
> ...
> 
> The port_fetch_tc callback is similar to port_setup_tc, only it reads the configuration instead of setting it.
> 
> I think it is easier to add a generic call back, so we do not need to add a new callback each time we support a new TC.
> 
> Erez

Since kernel v5.17 there exists struct dsa_device_ops :: connect() which allows tagging protocol drivers to store persistent data for each switch.
Switch drivers also have a struct dsa_switch_ops :: connect_tag_protocol() through which they can fix up or populate stuff in the tagging protocol driver's private storage.
What you could do is set up something lockless, or even a function pointer, to denote whether TX queue X is set up for ETF or not.

In any case, demanding that code with no in-kernel user gets accepted will get a hard no, no matter how small it is.
Geva, Erez April 11, 2022, 2:57 p.m. UTC | #10
Thanks for the tip.

Thanks
  Erez

-----Original Message-----
From: Vladimir Oltean <olteanv@gmail.com> 
Sent: Monday, 11 April 2022 16:43
To: Geva, Erez (ext) (DI PA DCP R&D 3) <erez.geva.ext@siemens.com>
Cc: netdev@vger.kernel.org; Andrew Lunn <andrew@lunn.ch>; Vivien Didelot <vivien.didelot@gmail.com>; Florian Fainelli <f.fainelli@gmail.com>; Sudler, Simon (DI PA DCP TI) <simon.sudler@siemens.com>; Meisinger, Andreas (DI PA DCP TI) <andreas.meisinger@siemens.com>; Schild, Henning (T CED SES-DE) <henning.schild@siemens.com>; Kiszka, Jan (T CED) <jan.kiszka@siemens.com>
Subject: Re: [PATCH 1/1] DSA Add callback to traffic control information

On Mon, Apr 11, 2022 at 02:23:59PM +0000, Geva, Erez wrote:
> As I mention, I do not own the tag driver code.
> 
> But for example for ETF, is like:
> 
> ... tag_xmit(struct sk_buff *skb, struct net_device *dev)
> +       struct tc_etf_qopt_offload etf;
> ...
> +       etf.queue = skb_get_queue_mapping(skb);
> +       if (dsa_slave_fetch_tc(dev, TC_SETUP_QDISC_ETF, &etf) == 0 && 
> + etf.enable) {
> ...
> 
> The port_fetch_tc callback is similar to port_setup_tc, only it reads the configuration instead of setting it.
> 
> I think it is easier to add a generic call back, so we do not need to add a new callback each time we support a new TC.
> 
> Erez

Since kernel v5.17 there exists struct dsa_device_ops :: connect() which allows tagging protocol drivers to store persistent data for each switch.
Switch drivers also have a struct dsa_switch_ops :: connect_tag_protocol() through which they can fix up or populate stuff in the tagging protocol driver's private storage.
What you could do is set up something lockless, or even a function pointer, to denote whether TX queue X is set up for ETF or not.

In any case, demanding that code with no in-kernel user gets accepted will get a hard no, no matter how small it is.
diff mbox series

Patch

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 934958fda962..ab8f0988bcfc 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -1036,6 +1036,8 @@  struct dsa_switch_ops {
 	void	(*port_policer_del)(struct dsa_switch *ds, int port);
 	int	(*port_setup_tc)(struct dsa_switch *ds, int port,
 				 enum tc_setup_type type, void *type_data);
+	int	(*port_fetch_tc)(struct dsa_switch *ds, int port,
+				 enum tc_setup_type type, void *type_data);
 
 	/*
 	 * Cross-chip operations
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 5d3f4a67dce1..d03c23680a50 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -320,6 +320,7 @@  void dsa_slave_setup_tagger(struct net_device *slave);
 int dsa_slave_change_mtu(struct net_device *dev, int new_mtu);
 int dsa_slave_manage_vlan_filtering(struct net_device *dev,
 				    bool vlan_filtering);
+int dsa_slave_fetch_tc(struct net_device *dev, enum tc_setup_type type, void *type_data);
 
 static inline struct dsa_port *dsa_slave_to_port(const struct net_device *dev)
 {
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 41c69a6e7854..0db7b99b06f9 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -1535,6 +1535,23 @@  static int dsa_slave_setup_tc(struct net_device *dev, enum tc_setup_type type,
 	return ds->ops->port_setup_tc(ds, dp->index, type, type_data);
 }
 
+/* Allow TAG driver to retrieve TC information from a DSA switch driver.
+ * Some TC require the TAG driver to pass information from the SKB into the TAG
+ * depending on the TC configuratin set used with port_setup_tc() callback.
+ * Though only the driver can know the proper value.
+ */
+int dsa_slave_fetch_tc(struct net_device *dev, enum tc_setup_type type, void *type_data)
+{
+	struct dsa_port *dp = dsa_slave_to_port(dev);
+	struct dsa_switch *ds = dp->ds;
+
+	if (!ds->ops->port_fetch_tc)
+		return -EOPNOTSUPP;
+
+	return ds->ops->port_fetch_tc(ds, dp->index, type, type_data);
+}
+EXPORT_SYMBOL_GPL(dsa_slave_fetch_tc);
+
 static int dsa_slave_get_rxnfc(struct net_device *dev,
 			       struct ethtool_rxnfc *nfc, u32 *rule_locs)
 {