Re: [PATCH net-next 1/2] net: stmmac: dwmac4: Read the UC filter size from hardware capabilities

[Andrew Lunn <andrew@lunn.ch>]

On Tue, Sep 01, 2026 at 09:04:28AM +0200, Maxime Chevallier wrote:
> 
> 
> On 9/1/26 02:26, Andrew Lunn wrote:
> >> Yeah but dwmac4 has a hash filter, but same as the UC filter it's just not plumbed
> >> in :/
> >>
> >> Let's leave this flag here, hash filter addition for MC filtering is coming-up, so let's not
> >> drop it now only to re-enable it after, one of the other wonderful discoveries found by
> >> running the selftests...
> > 
> > I assume you can put a MC address in a perfect match filter? You can
> > perfectly match a multicast address just as well as a unicast address.
> > 
> > The hash filter is less accurate, but again can be used to match a
> > unicast or multicast address, and then you need additional filtering
> > in software, which Linux will do.
> > 
> > So it seems to me, you should use a perfect match filters if you have
> > one available, independent of unicast or multicast, and only use a
> > hash filter if you have run out of perfect match filters.
> 
> That's an interesting point. The HW supports that, we have 3 control knobs
> for that in the MAC_PACKET_FILTER register :
> 
>  - HPF (bit 10) : Use Hash or Perfect Match for filtering.
>                   0 : Match UC and MC against hash filter
>                   1 : Match UC and MC according to HMC and HUC
> 
>  - HMC (bit 2) : Use Hash or Perfect Match for MC filtering
>                  0 : Match MC against perfect filter
>                  1 : Match MC against Hash table
> 
>  - HUC (bit 1) : Use Hash of PF for UC filtering
>                  0 : Match UC against PF
>                  1 : Match UC against Hash table
> 
> I don't know though how this all interacts with the primary MAC address. We
> always have one entry in PF for the device's own MAC address, we should
> probably always perfect match that one.

Yes, i agree, the primary should be a perfect match.

> But as the UC Perfect Filter toggle is global for All UC addresses it means
> we're stuck with perfect filter for all UC then ?

> For MC, this is a good point, but I'm worried about the complexity vs gain.
> 
> If we consider the 4 dwmac boards I have (may not be a very representative sample),
> we have :
> 
>  - imx8mp   : 64 PF (Perfect Fitler) entries
>  - jh7110   : 9 PF entries
>  - stm32mp1 : 4 PF entries
>  - yt6801   : 1 PF entry

I assume the imx8mp is using bank 1 and back 2? The designers of this
device seem to think the use cases for the device include lots of UC
and MC addresses.

Maybe, reserve bank 0 for UC, but allow both UC and MC in bank 1 and
2? That would allow imx8mp to make use of its hardware in an efficient
way, but it also keeps things simple and efficient for the more
restricted devices like the yt6801 and stm32mp1.

This discussion should however not effect this patchset. This sort of
optimisations can come later.

	Andrew