[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <F568DE45-3140-4636-BCA6-24BB7140C6CE@aol.com>
Date: Fri, 22 Dec 2023 14:08:38 -0500
From: Household Cang <canghousehold@....com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Romain Gantois <romain.gantois@...tlin.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Jose Abreu <joabreu@...opsys.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Maxime Chevallier <maxime.chevallier@...tlin.com>,
Sylvain Girard <sylvain.girard@...com>,
Pascal EBERHARD <pascal.eberhard@...com>,
Richard Tresidder <rtresidd@...ctromag.com.au>,
netdev@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net 0/1] Prevent DSA tags from breaking COE
> On Dec 22, 2023, at 7:30 AM, Vladimir Oltean <olteanv@...il.com> wrote:
>
> Is "rx off" actually required, or just "tx off”?
Before adjusted the ethtool -K, the client upload speed is 880Mbps (download speed 0.6Mbps). RK3568 is acting as a router, so client is sending to eth1 via DSA user port, rx used here, and then tx on eth0. So this might suggest only tx needs to be turned off on eth1.
>
> The MT7531BE switch requires transmitted packets to have an additional
> header which indicates what switch port is targeted. So the packet
> structure is not the same as what eth0 transmits.
>
I understand. How many bytes are the DSA header for MT, 8 bytes?
> Your GMAC datasheet should explain what packets it is able to offload
> L4 checksumming for, quite plainly. Probably MAC + IP + TCP yes, but
> MAC + MTK DSA + IP + TCP no.
I hardly could find this in the data sheet for RK3568. From the DMA mapping, it insinuates a correct ether type needs to be detected after the MAC header, besides an inner and an outer VLAN tag, if there are any.
> The driver still declares
> the NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM features because it is able to
> offload checksumming for _some_ packets, but it falls back to the
> software checksum helper for the rest. This includes your MTK DSA tagged
> packets.
I guess the end verdict regarding whether the hardware supports checksum offloading on DSA frames is a NO. So this is going to use some precious CPU power I am looking to fully dedicate to ipsec. Though I am pursuing crypto hw offloading at the same time with baylibre.
Lucas.
Powered by blists - more mailing lists