[dpdk-dev] [Bug 405] mlx5: the guest driver doesn't enforce the MTU set by rte_eth_dev_set_mtu()

bugzilla at dpdk.org bugzilla at dpdk.org
Fri Feb 21 17:26:53 CET 2020


https://bugs.dpdk.org/show_bug.cgi?id=405

            Bug ID: 405
           Summary: mlx5: the guest driver doesn't enforce the MTU set by
                    rte_eth_dev_set_mtu()
           Product: DPDK
           Version: 19.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: ethdev
          Assignee: dev at dpdk.org
          Reporter: scott_wasson at affirmednetworks.com
  Target Milestone: ---

On our guest VM, we are seeing packets that exceed the configured MTU are not
dropped by the mlx5 driver, and the packet scribbles past the end of the buffer
and overwrites the next struct rte_mbuf in memory.

The Openstack host’s MTU is 9000 on the PF.  Any large value will do.

The guest has buffers that are all 2250 bytes in payload size.

The guest calls rte_eth_dev_set_mtu() with a value of 2250 on a given VF.

We send an ICMP echo packet of size 3000 bytes, and it is not dropped by the
driver.  Instead, the 3000-byte packet is written into a 2250-byte buffer,
having ignored the setting from rte_eth_dev_set_mtu (which had returned
“success”), and causes corruption of the next struct rte_mbuf in memory, and a
crash very soon thereafter.

When we reduce the host’s MTU on the PF to a value <= 2250, then the problem
goes away. But we see this is a work-around, not a fix.

If the guest is in fact unable to change the MTU due to hardware architectural
limitations, it would be prudent to return the error (-ENOTSUP) to indicate
that the guest is unable to perform the request.  Also generate a log message
describing the reason for the error, to provide the community with sufficient
information to understand the problem.  But this is speculation, we don't know
for certain that the mlx5 guest driver is architecturally unable to enforce
MTU.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the dev mailing list