Messages in this thread | | | Subject | Re: [PATCH net-next 5/5] net: mscc: ocelot: support L2 multicast entries | From | Florian Fainelli <> | Date | Wed, 28 Oct 2020 19:41:36 -0700 |
| |
On 10/28/2020 7:27 PM, Vladimir Oltean wrote: > There is one main difference in mscc_ocelot between IP multicast and L2 > multicast. With IP multicast, destination ports are encoded into the > upper bytes of the multicast MAC address. Example: to deliver the > address 01:00:5E:11:22:33 to ports 3, 8, and 9, one would need to > program the address of 00:03:08:11:22:33 into hardware. Whereas for L2 > multicast, the MAC table entry points to a Port Group ID (PGID), and > that PGID contains the port mask that the packet will be forwarded to. > As to why it is this way, no clue. My guess is that not all port > combinations can be supported simultaneously with the limited number of > PGIDs, and this was somehow an issue for IP multicast but not for L2 > multicast. Anyway. > > Prior to this change, the raw L2 multicast code was bogus, due to the > fact that there wasn't really any way to test it using the bridge code. > There were 2 issues: > - A multicast PGID was allocated for each MDB entry, but it wasn't in > fact programmed to hardware. It was dummy. > - In fact we don't want to reserve a multicast PGID for every single MDB > entry. That would be odd because we can only have ~60 PGIDs, but > thousands of MDB entries. So instead, we want to reserve a multicast > PGID for every single port combination for multicast traffic. And > since we can have 2 (or more) MDB entries delivered to the same port > group (and therefore PGID), we need to reference-count the PGIDs. > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
I believe you have the same gfp_t comment applicable here as in patch #4. -- Florian
| |