Re: [PATCH net] octeontx2-af: npc: Fix CPT channel mask in npc_install_flow

[Ratheesh Kannoth <rkannoth@marvell.com>]

On 2026-06-01 at 08:02:21, Ratheesh Kannoth (rkannoth@marvell.com) wrote:
> From: Nithin Dabilpuram <ndabilpuram@marvell.com>

>> -	/* For cn10k the upper two bits of the channel number are
>> -	 * cpt channel number. with masking out these bits in the
>> -	 * mcam entry, same entry used for NIX will allow packets
>> -	 * received from cpt for parsing.
>> -	 */
>> -	if (!is_rvu_otx2(rvu))
>> -		req.chan_mask = NIX_CHAN_CPT_X2P_MASK;
>> -	else
>> -		req.chan_mask = 0xFFFU;
>> -
>> +	req.chan_mask = rvu_get_cpt_chan_mask(rvu);
>This is a pre-existing issue, but while this update correctly applies the
>CPT-aware NIX channel mask here, is it possible that other default NIX RX
>MCAM steering rules were missed?
>For example, in drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c,
>rvu_npc_install_ucast_entry() still hardcodes the channel mask to 0xFFFU:
>rvu_npc_install_ucast_entry() {
>    ...
>    req.channel = chan;
>    req.chan_mask = 0xFFFU;
>    req.intf = pfvf->nix_rx_intf;
>    ...
>}
>Since these are internal requests (req.hdr.pcifunc = 0), they bypass the
>override in rvu_mbox_handler_npc_install_flow(). Does this mean inline
>IPsec packets returning from CPT could fail to match these default L2
>steering rules and get dropped?
>Similar hardcoded 0xFFF(U) values appear to still exist in
>rvu_npc_install_bcast_match_entry() and rvu_switch_disable() in
>drivers/net/ethernet/marvell/octeontx2/af/rvu_switch.c.
>>  	req.channel = chan;
>>  	req.intf = pfvf->nix_rx_intf;
>>  	req.entry = index;
>

ACK.
pw-bot: changes-requested