-
Notifications
You must be signed in to change notification settings - Fork 30
VLAN Strip Debugging
CAUTION: This document is generated output from {X}fm source. Any modifications made to this file will certainly be overlaid by subsequent revisions. The proper way of maintaining the document is to modify the source file(s) in the repo, and generating the desired .pdf or .md versions of the document using {X}fm.
Virtual Function Daemon -- VFd
VLAN ID Stripped When Strip Disabled
An odd failure case has been observed in some environments and is documented here as, at least at the time of the writing, the unexpected behaviour is caused by the manner which the DPDK application configures the device via DPDK library calls. With the same application, and thus the same _ internal_ device configuration, we have observed different results with regard to VLAN ID stripping on Rx packets.
It is the intent of this brief to describe what was observed, and what we believe is the correct behaviour. We will also indicate the application device settings that are related, and potential causes of unexpected behaviour.
The initial symptom of the problem was that in the VF configuration file the value of stag stripping was set to false, yet the VLAN ID was being removed from the packets received by the DPDK application. This symptom was not observed in all environments; in some, the VLAN IDs remained in the packet as was expected.
Further examination of the NIC registers indicated that indeed stripping was enabled, however VFd logs indicated that the option was being turned off when the VF was configured on the NIC. When the kernel driver (ixgbevf) was used in the guest, the packets arrived with the VLAN ID as was expected.
The problem was observed in conjunction with the DPDK application (gobbler[1]) and was directly related to setting the Rx offload DEV_RX_OFFLOAD_VLAN_STRIP flag. When this offload flag was not set by the application, the expected behaviour in the "failing" environment was observed.
It is logical to assume that if the DPDK application sets the strip offload that the VLAN ID should be stripped from Rx packets regardless of the setting pushed to the NIC by VFd as the result of the VF configuration file. We assert that this is the correct behaviour, and the problem that was observed really was not a problem.
However, it seems there are some environments (likely some versions of the Niantic NIC itself) where the strip offload setting by the DPDK application does not reach the NIC, and the VFd configuration setting always applies. We consider this to be incorrect behaviour, but is not something that is within VFd's control and it is up to the systems administration staff to ensure that the VF configuration provided to VFd reflects the desired strip stag setting based on the application's needs.
When troubleshooting VLAN ID stripping "bugs," it is likely that the unexpected behaviour is caused by one of the following and is not a VFd bug.
- The strip stag setting in the VF's configuration file is incorrect, and the application is not setting the offload properly or at all and the default is incorrect.
- The DPDK application is setting the strip related offload which is opposite to the value in VFd VF configuration file, and the expectation is that the value in the VFd configuration is enforced.
- The DPDK application is attempting to set the strip related offload, however the underlying device is not being updated with the setting and the setting expected is opposite of that configured in the VFd VF configuration.
[1] Gobbler is available as a test tool in the VFd gadgets repo: github.com/att/vfd.gadgets.git
Source: vfd/doc/strip_issue.xfm
Original: 13 June 2018
Revised: 13 June 2018
Formatter: tfm V2.2/0a266