Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Setting of MTU over virtual function of sr-iov device may fail if MTU of the physical function is lower. It would be beneficial if the PF would be configured also with the max of the VFs MTUs
Version-Release number of selected component (if applicable):
nmstate-0.2.10
How reproducible:
100%
Steps to Reproduce:
1. Enable VF
2. Configure MTU of the VF to be higher than PF
3.
Actual results:
Fails with nmstate verification error
Expected results:
It should pass and configure the MTU also for PF
Additional info:
Where is this relation coming from exactly?
I did not expect the PF and its VF/s to have such an MTU dependency between each others.
Is there a reference to such a dependency/limitation?
(In reply to Edward Haas from comment #1)
> Where is this relation coming from exactly?
> I did not expect the PF and its VF/s to have such an MTU dependency between
> each others.
>
> Is there a reference to such a dependency/limitation?
It was reported by oVirt user see https://bugzilla.redhat.com/show_bug.cgi?id=1854851#c10
(In reply to Ales Musil from comment #2)
> (In reply to Edward Haas from comment #1)
> > Where is this relation coming from exactly?
> > I did not expect the PF and its VF/s to have such an MTU dependency between
> > each others.
> >
> > Is there a reference to such a dependency/limitation?
>
> It was reported by oVirt user see
> https://bugzilla.redhat.com/show_bug.cgi?id=1854851#c10
Thank you for the info.
I could not detect if there was an error of the kernel/driver to set the mtu, just that it was reported with the low value.
So is this a kernel, NM or HW vendor specific issue? Is there a reference anywhere that this is the expected behavior?
Comment 4Fernando F. Mancera
2020-07-22 10:05:33 UTC
According to an intel employee at https://community.intel.com/t5/Ethernet-Products/L2-Unicast-not-sent-on-ixgbevf/m-p/383563/highlight/true#M6138 PF should hold bigger or equal MTU than VFs but the kernel code seem only says "The 82599 cannot support a mix of jumbo and non-jumbo PF/VFs". I have tested this and confirmed that it is a specific issue of this driver. I tried this out using Broadcomm NIC and other Mellanox NICs and it is working well.
IMO, Nmstate should not handle specific driver/NIC issues.