Ethernet Products
Determine ramifications of Intel® Ethernet products and technologies
4986 Discussions

Why unicast promiscuous and vlan promiscuous are disabled in ixgbe vf after all multicast is enabled

yudapeng
Novice
1,666 Views
This issue can be reproduced as the below:
 
Precondition:
    intel x550 NIC is used as PF
 
Steps:
    1. create one VF on intel x550 PF
    2. enable promiscuos mode on VF
    3. enable allmulti mode on VF
    4. send to VF a vlan packet which destination is not same as the VF's MAC address 
 
Expected result:
    the sent packet shall be recieved by VF because promiscuous mode is enabled
 
Actual result:
    the sent packet is NOT recieved by VF 
 
by checking the latest out-of-tree ixgbe kernel driver source code, found that unicast promiscuous and vlan promiscuous are disabled after all multicast is enabled.
 
Question: Why unicast promiscuous and vlan promiscuous are disabled after all multicast is enabled?
 
in ixgbe_sriov.c:

 

static int ixgbe_update_vf_xcast_mode(struct ixgbe_adapter *adapter,
				      u32 *msgbuf, u32 vf)
{
...
	switch (xcast_mode) {
...
	case IXGBEVF_XCAST_MODE_ALLMULTI:
		disable = IXGBE_VMOLR_UPE | IXGBE_VMOLR_VPE;   //Question: Why unicast promiscuous and vlan promiscuous are disabled after all multicast is enabled?
		enable = IXGBE_VMOLR_BAM | IXGBE_VMOLR_ROMPE | IXGBE_VMOLR_MPE;
		break;
	case IXGBEVF_XCAST_MODE_PROMISC:
		if (hw->mac.type <= ixgbe_mac_82599EB)
			return -EOPNOTSUPP;

		fctrl = IXGBE_READ_REG(hw, IXGBE_FCTRL);
		if (!(fctrl & IXGBE_FCTRL_UPE)) {
			/* VF promisc requires PF in promisc */
			e_warn(drv,
			       "Enabling VF promisc requires PF in promisc\n");
			return -EPERM;
		}

		disable = 0;
		enable = IXGBE_VMOLR_BAM | IXGBE_VMOLR_ROMPE |
			 IXGBE_VMOLR_MPE | IXGBE_VMOLR_UPE | IXGBE_VMOLR_VPE;
		break;
	default:
		return -EOPNOTSUPP;
	}
...
}

 

 
0 Kudos
1 Solution
yudapeng
Novice
1,489 Views
0 Kudos
9 Replies
B_Y
Employee
1,606 Views

Hi @yudapeng,


Thank you for posting in Intel Ethernet Communities. 

Kindly provide the following information for us to check on your query:

1) Please advise if you are using custom board or with Intel/OEM system board?

2) Linux distribution

3) Ethtool -i 

4) Ethtool -k or sudo ethtool -k <interface_name>


Thank you.


Best regards,

BY_Intel

Intel Customer Support


0 Kudos
yudapeng
Novice
1,570 Views

1) not sure about the board information, but it should be Intel/OEM system board.

2) Linux distribution: Ubuntu 20.04.6 LTS (Focal Fossa)

 

3)

ethtool -i enp0s31f6
driver: ixgbe
version: 5.18.13
firmware-version: 0x800005b0
expansion-rom-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

4)

ethtool -k enp0s31f6
Features for enp0s31f6:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: on
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp-mangleid-segmentation: off
tx-tcp6-segmentation: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: off
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: on
tx-gre-csum-segmentation: on
tx-ipxip4-segmentation: on
tx-ipxip6-segmentation: on
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
tx-gso-partial: on
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off
hw-tc-offload: off
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: on
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]

Actually I think this issue should exist in all 500 Series NICs, and it looks like the kernel driver cause this issue.

0 Kudos
B_Y
Employee
1,565 Views

Hi @yudapeng,


Thank you for the information. 

1) Please advise if you are using custom board or with Intel/OEM system board?

The 1) question was trying to understand if you are having an Intel system or some other brand system, mainly to understand if your ethernet is an adapter/controller embedded on to the system or PCIe.

If you can share the output of below command, that would be helpful:

lspci | grep -I Ethernet 


Thank you.


Best regards,

BY_Intel

Intel Customer Support



0 Kudos
yudapeng
Novice
1,559 Views

the following information is extracted from output of: lspci | grep -I Ethernet

03:00.0 Ethernet controller: Intel Corporation Ethernet Connection X552 10 GbE Backplane
0 Kudos
B_Y
Employee
1,516 Views

Hi @yudapeng,


The main possible reason for disabling unicast promiscuous and VLAN promiscuous modes after enabling multicast is to avoid unnecessary overhead and potential security risks.

- When multicast is enabled, the network interface is already set to receive all multicast packets sent to multicast group addresses. There is no need to enable unicast promiscuous mode because the interface will not miss any multicast packets.

- Similarly, enabling VLAN promiscuous mode can lead to receiving VLAN tagged packets that might not be intended for the specific VLANs associated with the network interface. This could cause unnecessary processing and potential security concerns if the VF starts receiving traffic from VLANs it shouldn't have access to.

- By enabling only multicast mode and leaving unicast promiscuous and VLAN promiscuous modes disabled, the network interface ensures that it captures and processes multicast traffic efficiently and securely without unnecessarily processing other types of traffic not relevant to its role or configuration. This approach maintains the integrity of VLAN segregation and minimizes any unnecessary overhead on the virtual function.


Since this question related to programming, we also have a forum for those specific issues and you can post it to that forum as per link below so it can get answered in more detail.


Embedded Connectivity Forum

https://community.intel.com/t5/Embedded-Connectivity/bd-p/embedded-networking-connectivity


Additionally, if you have any further issue, you also can open a case with Intel® Premier Support (IPS).

If you have not yet had the Premier account, you can follow the step provided on the link below or you can get help from someone on your team that already have the account to open a case if needed.


How to have Intel® Premier Support access

https://www.intel.com/content/www/us/en/support/articles/000057045/ethernet-products.html


Thank you.


Best regards,

BY_Intel

Intel Customer Support


yudapeng
Novice
1,490 Views

Thanks for the detailed information

0 Kudos
B_Y
Employee
1,488 Views

Hi @yudapeng,


You are welcome. Please let me know if I can be of any further help?


Best regards,

BY_Intel

Intel Customer Support


0 Kudos
yudapeng
Novice
1,427 Views

no more questions, thank you!

0 Kudos
B_Y
Employee
1,392 Views

Hi @yudapeng,


We confirm receipt of your request to close this ticket. Just feel free to post a new question if you may have any other inquiry in the future as this thread will no longer be monitored. Thank you.


Best regards,

BY_Intel

Intel Customer Support


0 Kudos
Reply