Re: [PATCH net] bnxt_en: avoid redundant RX mask updates in UC overflow state

[Pavan Chebbi]

On Thu, Aug 27, 2026 at 12:42 PM Johnathan Browall via B4 Relay
<devnull+johnathan.browall.topgolf.com@xxxxxxxxxx> wrote:
>
> From: Johnathan Browall <johnathan.browall@xxxxxxxxxxx>
>
> bnxt_cfg_rx_mode() stops programming individual L2 filters and turns
> on the promiscuous bit in the VNIC rx mask when the interface has more
> unicast addresses than the hardware has filter slots
> (BNXT_MAX_UC_ADDRS).  The driver state never becomes consistent after
> that: vnic->uc_filter_count stays at 1, so bnxt_uc_list_updated()
> keeps reporting the UC list as changed on every rx-mode callback, and
> bnxt_set_rx_mode() removes the promiscuous bit from the mask it
> computes (it only re-adds it for IFF_PROMISC), so the mask comparison
> also fails every time.
>
> As a consequence, every rx-mode callback resends the same
> HWRM_CFA_L2_SET_RX_MASK to the firmware, including for requests that
> change nothing, such as setting a link flag to the value it already
> has, or a macvlan going up or down.  That would only cost an
> unnecessary firmware call if SET_RX_MASK processing did not affect
> traffic, but on BCM57416 and BCM57504 (firmware 23.3 and 23.6) it
> does: each invocation causes a short interval in which incoming
> unicast traffic is dropped.  We observed this in production as
> sequence gaps in GigE Vision camera streams on a PF carrying 19
> secondary unicast addresses, with HWRM tracing showing a SET_RX_MASK
> (and no filter alloc/free) for every repeated "ip link set ... arp on"
> that changed nothing.

Regardless of why/whether firmware behaves that way, to me, your patch
looks like the right thing to do.
LGTM except that you may want to fix the checkpatch complaint of 82 chars..
Reviewed-by: Pavan Chebbi <pavan.chebbi@xxxxxxxxxxxx>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature