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

[Maxime Chevallier]

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.

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

On a simple setup, between the IPv4 and IPv6 multicast, we very easily have at
least 3 multicast addresses assigned to our interface when it's brought up :

# ip maddr show eth0
2:      eth0
        link  33:33:00:00:00:01
        link  01:00:5e:00:00:01
        link  33:33:ff:00:af:d7
[...]

So on STM32MP1 this is already enough to fill the perfect fitler, any addition
trips either the promisc logic, or a more complex logic to re-split UC and MC into
Hash and Perfect filters separately

On YT8601, 1 PF entry, all MC to Hash, and any additional UC trips the UC-promisc mode.

I think in a typical setup, the UC table has more chance of getting filled than the hash
table, so a simpler option could be :

 - Always use hash for MC
 - Use perfect match for UC when possible
 - If perfect filter is full, use Hash for UC and MC matching, with
the idea that hash is still better than going UC-promisc ?

Maxime