netdev - Re: dsa traffic priorization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e3047ee8-64b1-a65b-5c0d-8b3b0ce81085@gmail.com>
Date:   Mon, 23 Sep 2019 08:32:34 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Jan Lübbe <jlu@...gutronix.de>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>
Cc:     netdev <netdev@...r.kernel.org>,
        Vladimir Oltean <olteanv@...il.com>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        kernel@...gutronix.de, Andrew Lunn <andrew@...n.ch>
Subject: Re: dsa traffic priorization



On 9/23/2019 5:56 AM, Jan Lübbe wrote:
> 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@...gutronix.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?

There are two simple cases:

- the switch provides a ndo_setup_tc() implementation (not just
dsa_slave_setup_tc, the callbacks behind are also provided), but the DSA
master does not, you can use the DSA switch implementation

- the DSA master provides a ndo_setup_tc() implementation, but the DSA
switch does not, then you can use the DSA master implementation

If both are provided then you must make a choice of either using one, or
the other, typically the using the most capable for the specific use
case, or using both.

If your interest is in doing egress configuration on the CPU port, then
maybe using the bridge master device and somehow linking it to the DSA
switch's CPU port might be a better approach. See [1] for how this is
done for instance.

[1]:
https://lists.linuxfoundation.org/pipermail/bridge/2016-November/010112.html

> 
> 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...

bridge ports are net_device instances, so as long as this paradigm is
maintained, it should work.
-- 
Florian