The former logic of set MAC source/destination address flow action don't consider the mask filed of control message passed to the firmware. This caused the firmware skip the set action logic, and the offloaded packets don't have the right MAC address as expected.
Fixes: 4f6983154570 ("net/nfp: support MAC source flow action") Fixes: eecc7ca3088a ("net/nfp: support MAC destination flow action") Cc: sta...@dpdk.org Signed-off-by: Chaoyong He <chaoyong...@corigine.com> Reviewed-by: Niklas Söderlund <niklas.soderl...@corigine.com> --- drivers/net/nfp/nfp_flow.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/nfp/nfp_flow.c b/drivers/net/nfp/nfp_flow.c index 0c38925701..f373171d7e 100644 --- a/drivers/net/nfp/nfp_flow.c +++ b/drivers/net/nfp/nfp_flow.c @@ -2066,6 +2066,7 @@ nfp_flow_action_set_mac(char *act_data, bool mac_src_flag, bool mac_set_flag) { + uint8_t i; size_t act_size; struct nfp_fl_act_set_eth *set_eth; const struct rte_flow_action_set_mac *set_mac; @@ -2084,9 +2085,13 @@ nfp_flow_action_set_mac(char *act_data, if (mac_src_flag) { rte_memcpy(&set_eth->eth_addr[RTE_ETHER_ADDR_LEN], set_mac->mac_addr, RTE_ETHER_ADDR_LEN); + for (i = 0; i < RTE_ETHER_ADDR_LEN; i++) + set_eth->eth_addr_mask[RTE_ETHER_ADDR_LEN + i] = 0xff; } else { rte_memcpy(&set_eth->eth_addr[0], set_mac->mac_addr, RTE_ETHER_ADDR_LEN); + for (i = 0; i < RTE_ETHER_ADDR_LEN; i++) + set_eth->eth_addr_mask[i] = 0xff; } } -- 2.29.3