On Thu, Aug 24, 2023 at 01:10:04AM +0800, Rohan G Thomas wrote: > >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. > > Hi Serge, > > Didn't know about a different IP configuration supported by DW QoS Eth IP. If > this is the case, I think we can have a flag 'coe-unsupported' for any TX > queue subnode as below. > > + snps,coe-unsupported: > + $ref: /schemas/types.yaml#/definitions/flag AFAIR tKrzysztof preferred to use type: boolean for the flags. > + description: > + TX checksum offload is unsupported by the TX queue. > + If TX checksum > + offload is requested for a packet to be transmitted through this > + TX queue then have a software fallback in the driver for checksum > + calculation. This is redundant in the HW description. > > If this is okay, I can rework the patch based on this. Covers both DW QoS Eth IP > and DW XGMAC IP cases. I guess that's the only choice we have seeing the driver already expects all the Tx queues having the COE supported. -Serge(y) > > > > >-Serge(y) > > > >> -- > >> pw-bot: cr > > BR, > Rohan
