linux-kernel - Re: [PATCH net-next v5 1/2] dt-bindings: net: snps,dwmac: Tx queues with coe

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: <l7yajzhpuotn62pjkxk43qtcn3u4zltpyqcvo224737bjg3eab@bzu6pirxbvh2>
Date:   Wed, 23 Aug 2023 13:00:09 +0300
From:   Serge Semin <fancer.lancer@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Rohan G Thomas <rohan.g.thomas@...el.com>,
        "David S . Miller" <davem@...emloft.net>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Conor Dooley <conor.dooley@...rochip.com>
Subject: Re: [PATCH net-next v5 1/2] dt-bindings: net: snps,dwmac: Tx queues
 with coe

On Tue, Aug 22, 2023 at 05:15:25PM -0700, Jakub Kicinski wrote:
> On Sat, 19 Aug 2023 10:31:31 +0800 Rohan G Thomas wrote:
> > +      snps,tx-queues-with-coe:
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +        description: number of TX queues that support TX checksum offloading
> 

> Is it going to be obvious that if not present all queues support
> checksum offload? I think we should document the default.

This question is debatable:
1. By default the DW xGMAC and DW QoS Eth IP-cores are
synthesized with only the very first Tx queue having Tx COE enabled.
2. If TSO is disabled then the Tx COE can be individually enabled
for each queue available on DW QoS Eth controller and for the very
first N queues on DW xGMAC controller.
3. If TSO is enabled then the Tx COE will be automatically and always
enabled for as many first queues as there are TSO-capable
DMA-channels.
4. At the current state the STMMAC driver assumes that all Tx Queues
support Tx COE.

The entry 4 can't be changed since we'll risk to catch regressions on
the platforms with no property specified. On the other hand it partly
contradicts to the rest of the entries. I don't know what would be a
correct way to specify the default value in this case. Most likely
just keep the entry 4 and be done with it.

BTW I just noticed that but the suggested "snps,tx-queues-with-coe"
property semantic will only cover a DW XGMAC-part of the case 2. DW
QoS Eth can be synthesized with Tx COE individually enabled for a
particular queue if TSO is unavailable.

-Serge(y)

> -- 
> pw-bot: cr