Message ID | 20221109163426.76164-1-nbd@nbd.name (mailing list archive) |
---|---|
Headers | show |
Series | Multiqueue + DSA untag support + fixes for mtk_eth_soc | expand |
On Wed, Nov 09, 2022 at 05:34:14PM +0100, Felix Fietkau wrote: > This series contains multiple improvements for mtk_eth_soc: > > On devices with QDMA (MT7621 and newer), multiqueue support is implemented > by using the SoC's traffic shaper function, which sits on the DMA engine. > The driver exposes traffic shaper queues as network stack queues and configures > them to the link speed limit. This fixes an issue where traffic to slower ports > would drown out traffic to faster ports. It also fixes packet drops and jitter > when running hardware offloaded traffic alongside traffic from the CPU. > > On MT7622, the DSA tag for MT753x switches can be untagged by the DMA engine, > which removes the need for header mangling in the DSA tag driver. > > This is implemented by letting DSA skip the tag receive function, if the port > is passed via metadata dst type METADATA_HW_PORT_MUX > > Also part of this series are a number of fixes to TSO/SG support > > Changes in v2: > - drop the use of skb vlan tags to pass the port information to the tag driver, > use metadata_dst instead > - fix a small issue in enabling untag Please split the work and let's concentrate on one thing at a time without extra noise, for example DSA RX tag processing offload first, since that needs the most attention. Also please use ./scripts/get_maintainer.pl when sending patches ;)
On 10.11.22 15:28, Vladimir Oltean wrote: > On Wed, Nov 09, 2022 at 05:34:14PM +0100, Felix Fietkau wrote: >> This series contains multiple improvements for mtk_eth_soc: >> >> On devices with QDMA (MT7621 and newer), multiqueue support is implemented >> by using the SoC's traffic shaper function, which sits on the DMA engine. >> The driver exposes traffic shaper queues as network stack queues and configures >> them to the link speed limit. This fixes an issue where traffic to slower ports >> would drown out traffic to faster ports. It also fixes packet drops and jitter >> when running hardware offloaded traffic alongside traffic from the CPU. >> >> On MT7622, the DSA tag for MT753x switches can be untagged by the DMA engine, >> which removes the need for header mangling in the DSA tag driver. >> >> This is implemented by letting DSA skip the tag receive function, if the port >> is passed via metadata dst type METADATA_HW_PORT_MUX >> >> Also part of this series are a number of fixes to TSO/SG support >> >> Changes in v2: >> - drop the use of skb vlan tags to pass the port information to the tag driver, >> use metadata_dst instead >> - fix a small issue in enabling untag > > Please split the work and let's concentrate on one thing at a time > without extra noise, for example DSA RX tag processing offload first, > since that needs the most attention. > > Also please use ./scripts/get_maintainer.pl when sending patches ;) I did that. That's where most of the To/Cc's came from. - Felix
Hi Felix, Not directly related to your patch series, but as you seem to be tinkering with the driver, it seems appropriate to ask. Are you using hardware that uses RGMII? If not, do you know anyone who is? It would be good to fix mtk_mac_config(), specifically the use of state->speed therein - see the FIXME that I placed in that function. Honestly, I think this code is broken, since if the RGMII interface speed changes, the outer if() won't allow this code path to be re-executed (since mac->interface will be the same as state->interface for speed changes.) It would be nice to get rid of that, because this is the very last pre-March 2020 legacy ethernet driver, and it's marked as such for this very reason. Thanks.
Hi Russell, On 10.11.22 19:50, Russell King (Oracle) wrote: > Hi Felix, > > Not directly related to your patch series, but as you seem to be > tinkering with the driver, it seems appropriate to ask. Are you > using hardware that uses RGMII? If not, do you know anyone who is? > > It would be good to fix mtk_mac_config(), specifically the use > of state->speed therein - see the FIXME that I placed in that > function. Honestly, I think this code is broken, since if the > RGMII interface speed changes, the outer if() won't allow this > code path to be re-executed (since mac->interface will be the > same as state->interface for speed changes.) The only device I'm aware of which uses RGMII has the RGMII port connected to a switch with no proper upstream driver support - no speed changes expected there. - Felix