netdev - RE: [PATCH 1/1] DSA Add callback to traffic control information

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <VI1PR10MB2446DB6CD7B54411232E0CCAABEA9@VI1PR10MB2446.EURPRD10.PROD.OUTLOOK.COM>
Date:   Mon, 11 Apr 2022 14:49:40 +0000
From:   "Geva, Erez" <erez.geva.ext@...mens.com>
To:     Vladimir Oltean <olteanv@...il.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "Sudler, Simon" <simon.sudler@...mens.com>,
        "Meisinger, Andreas" <andreas.meisinger@...mens.com>,
        "Schild, Henning" <henning.schild@...mens.com>,
        "jan.kiszka@...mens.com" <jan.kiszka@...mens.com>
Subject: RE: [PATCH 1/1] DSA Add callback to traffic control information



-----Original Message-----
From: Vladimir Oltean <olteanv@...il.com> 
Sent: Monday, 11 April 2022 16:43
To: Geva, Erez (ext) (DI PA DCP R&D 3) <erez.geva.ext@...mens.com>
Cc: netdev@...r.kernel.org; Andrew Lunn <andrew@...n.ch>; Vivien Didelot <vivien.didelot@...il.com>; Florian Fainelli <f.fainelli@...il.com>; Sudler, Simon (DI PA DCP TI) <simon.sudler@...mens.com>; Meisinger, Andreas (DI PA DCP TI) <andreas.meisinger@...mens.com>; Schild, Henning (T CED SES-DE) <henning.schild@...mens.com>; Kiszka, Jan (T CED) <jan.kiszka@...mens.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.