> Ah, you already have it here. I still think this can be optimized. Fair — the helper still memcmp's five bytes for every multicast frame, even plain IPv6 ND or IPv4 mcast. I'll fold the check into the caller with unlikely(), and gate the inner test on the 01:80:c2:00:00 OUI so ordinary multicast falls through with a single compare.
> This seems to assume that tpmr->ports[0] is filled first. You're right, that's broken — after a detach, ports[0].slot is stale. I'll iterate ports[] to find the surviving member instead of trusting positional order. The del path is already slot-agnostic. > Maybe you also want to act on NETDEV_PRECHANGEMTU and reject it? Good catch, nothing stops a member MTU change from desyncing the pair today. I'll reject in NETDEV_PRECHANGEMTU. > Driver version is meaningless Will drop. > I also wounder if this is the correct home I went back and forth on that. Landed on drivers/net/ because TPMR is structurally closer to veth/macvlan/bonding than to bridge or openvswitch — no FDB, no port state, ~400 LOC. Happy to move it if you'd prefer net/tpmr/, but my preference is to keep it here. Thanks for the review. Cheers.
