qlnxe: Overhaul setting the multicast MAC filters

[zlei]

Summary

For the operation of multicast MAC filters, the usage of filter op ADD
is rather misleading, given it removes any existing filters for the
vport. Use REPLACE ( ECORE_FILTER_REPLACE ) instead.

Current implementation pass only one MAC address to
ecore_sp_eth_filter_mcast() and hence any previously installed filters
are removed and breaks the multicast function. This can be observed via
assigning new IPv6 addresses to the interface, or putting the interface
as a member of lagg(4) interface with LACP aggregation protocol. Fix
that by calculating the multicast filter bins directly from all multicast
MAC addresses and replace the filters every time the bins changes.

As a nice effect, the soft limit of the maximum number of supported
multicast MAC address ( ECORE_MAX_MC_ADDRS 64 ) is removed. Due to the
nature of filter, which is hash based, a full 1's multicast filter bins
means all mutlicast packets are accepted and then there's no need to
make the vport into allmulti mode.

Given the VF port is set to promiscuous mode unconditionally, the
setting of the multicast MAC filters for VF ports is shortcuted and not
well tested.

PR: 265857
PR: 290973
MFC after: 1 week

Test Plan

Assign multiple IPv6 addresses to ql0. Ping from the peer ( cxl0 ) to those addresses. Checking the ndp entries.

[kbowling]

Seems fine, assuming you have check the hw filter table size(s)

[zlei]

In D54892#1260605, @kbowling wrote:

Seems fine, assuming you have check the hw filter table size(s)

I struggled with that for quite a long time. I did not find any useful information about the hw filter table size. I checked both Linux driver and DPDK driver, if I read them right, they both set the soft limit to 64 ( i.e. ECORE_MAX_MC_ADDRS in FreeBSD driver ). I have no clue how that was chosen, so I wrote scripts to assign more than 64 ( up to 1024 ) IPv6 addresses to the interface, and no error occurs.

So I sit down and re-think about the design multicast filter. If I were the vendor, to be efficient, I would also choose hash based multicast filter. So the next question is how many bits? QLogic choose 256 bits but not 64 bits ( apparently the latter is not sufficient for a modern high speed NIC ). So why not use them (256 bits) all but only (64 bits) ? I see no reason.

If some low end NICs have only 64 bits hw filter table, then the firmware can convert an 256 bits hash table to 64 bits one, so still no bothering the driver side.

Probably I should revise the commit message to mention the hardware I have tested. Then if someone encounter failed multicast setup, I'd realize there might have real limitation on low end NICs.