linux-kernel - Re: [PATCH net-next 4/6] net: ethernet: mtk_eth_soc: implement multi-queue support for per-port queues

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: <8EC28201-A848-4078-812A-AFE08ED12F7B@nbd.name>
Date:   Fri, 18 Nov 2022 17:30:46 +0100
From:   Felix Fietkau <nbd@....name>
To:     Alexander 'lynxis' Couzens <lynxis@...0.eu>
Cc:     netdev@...r.kernel.org, John Crispin <john@...ozen.org>,
        Sean Wang <sean.wang@...iatek.com>,
        Mark Lee <Mark-MC.Lee@...iatek.com>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Russell King <linux@...linux.org.uk>,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 4/6] net: ethernet: mtk_eth_soc: implement multi-queue support for per-port queues


> On 18. Nov 2022, at 16:13, Alexander 'lynxis' Couzens <lynxis@...0.eu> wrote:
> 
> Hi Felix,
> 
>> On Wed, 16 Nov 2022 09:07:32 +0100
>> Felix Fietkau <nbd@....name> wrote:
>> 
>> @@ -614,6 +618,75 @@ static void mtk_mac_link_down(struct phylink_config *config, unsigned int mode,
>>    mtk_w32(mac->hw, mcr, MTK_MAC_MCR(mac->id));
>> }
>> 
>> +static void mtk_set_queue_speed(struct mtk_eth *eth, unsigned int idx,
>> +                int speed)
>> +{
>> +    const struct mtk_soc_data *soc = eth->soc;
>> +    u32 ofs, val;
>> +
>> +    if (!MTK_HAS_CAPS(soc->caps, MTK_QDMA))
>> +        return;
>> +
>> +    val = MTK_QTX_SCH_MIN_RATE_EN |
>> +          /* minimum: 10 Mbps */
>> +          FIELD_PREP(MTK_QTX_SCH_MIN_RATE_MAN, 1) |
>> +          FIELD_PREP(MTK_QTX_SCH_MIN_RATE_EXP, 4) |
>> +          MTK_QTX_SCH_LEAKY_BUCKET_SIZE;
>> +    if (!MTK_HAS_CAPS(eth->soc->caps, MTK_NETSYS_V2))
>> +        val |= MTK_QTX_SCH_LEAKY_BUCKET_EN;
>> +
>> +    if (IS_ENABLED(CONFIG_SOC_MT7621)) {
>> +        switch (speed) {
>> +        case SPEED_10:
>> +            val |= MTK_QTX_SCH_MAX_RATE_EN |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_MAN, 103) |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_EXP, 2) |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_WEIGHT, 1);
>> +            break;
>> +        case SPEED_100:
>> +            val |= MTK_QTX_SCH_MAX_RATE_EN |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_MAN, 103) |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_EXP, 3);
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_WEIGHT, 1);
>> +            break;
>> +        case SPEED_1000:
>> +            val |= MTK_QTX_SCH_MAX_RATE_EN |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_MAN, 105) |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_EXP, 4) |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_WEIGHT, 10);
>> +            break;
>> +        default:
>> +            break;
>> +        }
>> +    } else {
>> +        switch (speed) {
>> +        case SPEED_10:
>> +            val |= MTK_QTX_SCH_MAX_RATE_EN |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_MAN, 1) |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_EXP, 4) |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_WEIGHT, 1);
>> +            break;
>> +        case SPEED_100:
>> +            val |= MTK_QTX_SCH_MAX_RATE_EN |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_MAN, 1) |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_EXP, 5);
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_WEIGHT, 1);
>> +            break;
>> +        case SPEED_1000:
>> +            val |= MTK_QTX_SCH_MAX_RATE_EN |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_MAN, 10) |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_EXP, 5) |
>> +                   FIELD_PREP(MTK_QTX_SCH_MAX_RATE_WEIGHT, 10);
>> +            break;
>> +        default:
>> +            break;
>> +        }
>> +    }
>> +
>> +    ofs = MTK_QTX_OFFSET * idx;
>> +    mtk_w32(eth, val, soc->reg_map->qdma.qtx_sch + ofs);
>> +}
>> +
>> static void mtk_mac_link_up(struct phylink_config *config,
>>                struct phy_device *phy,
>>                unsigned int mode, phy_interface_t interface,
>> @@ -639,6 +712,8 @@ static void mtk_mac_link_up(struct phylink_config *config,
> 
> 
> What's happening to 2.5Gbit ports (e.g. on mt7622)? Should be SPEED_2500 also in the switch/case?
> E.g. a direct connected 2.5Gbit phy to GMAC0.
> Or a mt7622 GMAC0 to mt7531 port 6 and a 2.5Gbit phy to port 5.

On 2.5 Gbit/s, the code disables rate limiting, since it’s not needed. That’s why it’s not handled here

- Felix