Re: dsa traffic priorization

["Jan Lübbe" <jlu@pengutronix.de>]

Adding TC maintainers... (we're trying to find a mainline-acceptable
way to configure and offload strict port-based priorities in the
context of DSA/switchdev).

On Thu, 2019-09-19 at 10:12 -0700, Florian Fainelli wrote:
> On 9/19/19 1:44 AM, Sascha Hauer wrote:
> > On Wed, Sep 18, 2019 at 10:41:58AM -0700, Florian Fainelli wrote:
> > > On 9/18/19 7:36 AM, Vladimir Oltean wrote:
> > > > On Wed, 18 Sep 2019 at 17:03, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > > > The other part of the problem seems to be that the CPU port
> > > > > has no network device representation in Linux, so there's no
> > > > > interface to configure the egress limits via tc.
> > > > > This has been discussed before, but it seems there hasn't
> > > > > been any consensous regarding how we want to proceed?
> > > 
> > > You have the DSA master network device which is on the other side of the
> > > switch,
> > 
> > You mean the (in my case) i.MX FEC? Everything I do on this device ends
> > up in the FEC itself and not on the switch, right?
> 
> Yes, we have a way to overload specific netdevice_ops and ethtool_ops
> operations in order to use the i.MX FEC network device as configuration
> entry point, say eth0, but have it operate on the switch, because when
> the DSA switch got attached to the DSA master, we replaced some of that
> network device's operations with ones that piggy back into the switch.
> See net/dsa/master.c for details.

Currently, it overrides
for ethtool:
        ops->get_sset_count = dsa_master_get_sset_count;
        ops->get_ethtool_stats = dsa_master_get_ethtool_stats;
        ops->get_strings = dsa_master_get_strings;
        ops->get_ethtool_phy_stats = dsa_master_get_ethtool_phy_stats;
for ndo:
        ops->ndo_get_phys_port_name = dsa_master_get_phys_port_name;

In dsa/slave.c we have for ndo:
        .ndo_setup_tc           = dsa_slave_setup_tc,

So we would override ndo_setup_tc from dsa as well, maybe falling back
to the original ndo_setup_tc provided by the ethernet driver if we the
switch HW cannot handle a TC configuration?

That would allow us to configure and offload a CPU-port-specific TC
policy under the control of DSA. Is this interface reasonable?

Im not sure if the existing TC filters and qdiscs can match on bridge-
specific information (like the ingress port) yet, so this might require
extensions to TC filters as well...

Regards,
Jan
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |