| Message ID | 20180619213058.12273-29-ajit.khaparde@broadcom.com (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | Ferruh Yigit |
| Headers | show |
| Series | bnxt patchset | expand |
| Context | Check | Description |
|---|---|---|
| ci/checkpatch | success | coding style OK |
| ci/Intel-compilation | success | Compilation OK |
On 6/19/2018 10:30 PM, Ajit Khaparde wrote: > There is no need to update hardware configuration if new MTU is > not greater than the max data the mbuf can accommodate. If app sets a smaller MTU won't it expect that HW will drop received packets bigger than provided size? Will this logic work if HW is not updated? > > Fixes: daef48efe5e5 ("net/bnxt: support set MTU") > Cc: stable@dpdk.org > > Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com> > --- > drivers/net/bnxt/bnxt_ethdev.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c > index 9cfa43778..1145bc195 100644 > --- a/drivers/net/bnxt/bnxt_ethdev.c > +++ b/drivers/net/bnxt/bnxt_ethdev.c > @@ -1597,6 +1597,7 @@ static int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu) > > for (i = 0; i < bp->nr_vnics; i++) { > struct bnxt_vnic_info *vnic = &bp->vnic_info[i]; > + uint16_t size = 0; > > vnic->mru = bp->eth_dev->data->mtu + ETHER_HDR_LEN + > ETHER_CRC_LEN + VLAN_TAG_SIZE * 2; > @@ -1604,9 +1605,14 @@ static int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu) > if (rc) > break; > > - rc = bnxt_hwrm_vnic_plcmode_cfg(bp, vnic); > - if (rc) > - return rc; > + size = rte_pktmbuf_data_room_size(bp->rx_queues[0]->mb_pool); > + size -= RTE_PKTMBUF_HEADROOM; > + > + if (size < new_mtu) { > + rc = bnxt_hwrm_vnic_plcmode_cfg(bp, vnic); > + if (rc) > + return rc; > + } > } > > return rc; >
On Tue, Jun 26, 2018 at 8:30 AM, Ferruh Yigit <ferruh.yigit@intel.com> wrote: > On 6/19/2018 10:30 PM, Ajit Khaparde wrote: > > There is no need to update hardware configuration if new MTU is > > not greater than the max data the mbuf can accommodate. > > If app sets a smaller MTU won't it expect that HW will drop received > packets > bigger than provided size? Will this logic work if HW is not updated? > Actually, the commit message needs rephrased. The behavior you mentioned will not be impacted. The hardware will honor the MTU configured.
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c index 9cfa43778..1145bc195 100644 --- a/drivers/net/bnxt/bnxt_ethdev.c +++ b/drivers/net/bnxt/bnxt_ethdev.c @@ -1597,6 +1597,7 @@ static int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu) for (i = 0; i < bp->nr_vnics; i++) { struct bnxt_vnic_info *vnic = &bp->vnic_info[i]; + uint16_t size = 0; vnic->mru = bp->eth_dev->data->mtu + ETHER_HDR_LEN + ETHER_CRC_LEN + VLAN_TAG_SIZE * 2; @@ -1604,9 +1605,14 @@ static int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu) if (rc) break; - rc = bnxt_hwrm_vnic_plcmode_cfg(bp, vnic); - if (rc) - return rc; + size = rte_pktmbuf_data_room_size(bp->rx_queues[0]->mb_pool); + size -= RTE_PKTMBUF_HEADROOM; + + if (size < new_mtu) { + rc = bnxt_hwrm_vnic_plcmode_cfg(bp, vnic); + if (rc) + return rc; + } } return rc;
There is no need to update hardware configuration if new MTU is not greater than the max data the mbuf can accommodate. Fixes: daef48efe5e5 ("net/bnxt: support set MTU") Cc: stable@dpdk.org Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com> --- drivers/net/bnxt/bnxt_ethdev.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)