On 5/21/19 11:39 PM, Ajit Khaparde wrote:
From: Lance Richardson <lance.richard...@broadcom.com> When determining whether scattered receive mode is needed, the size of a QinQ header is being added to rxmode.max_rx_pkt_len before comparing to the receive buffer size, however max_rx_pkt_len already accounts for the QinQ header size. Fix by simply comparing rxmode.max_rx_pkt_len against the buffer size. Fixes: daef48efe5e5 ("net/bnxt: support set MTU") Signed-off-by: Lance Richardson <lance.richard...@broadcom.com> Signed-off-by: Ajit Khaparde <ajit.khapa...@broadcom.com> --- drivers/net/bnxt/bnxt_ethdev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c index 064a153ec..52a6b94e0 100644 --- a/drivers/net/bnxt/bnxt_ethdev.c +++ b/drivers/net/bnxt/bnxt_ethdev.c @@ -638,8 +638,7 @@ static int bnxt_scattered_rx(struct rte_eth_dev *eth_dev)buf_size = (uint16_t)(rte_pktmbuf_data_room_size(rxq->mb_pool) -RTE_PKTMBUF_HEADROOM); - if (eth_dev->data->dev_conf.rxmode.max_rx_pkt_len + - VLAN_TAG_SIZE * BNXT_NUM_VLANS > buf_size) + if (eth_dev->data->dev_conf.rxmode.max_rx_pkt_len > buf_size) return 1; } return 0;
Isn't it fixing patch 2? If so, Fixes line is wrong, and it should be squashed directly into patch 2.
