> Subject: Re: [Intel-wired-lan] [PATCH v5] ixgbe: Add module parameter to > disable VLAN filter > > On 05/26/2015 06:11 PM, Hiroshi Shimamoto wrote: > >> On 05/21/2015 06:10 AM, Hiroshi Shimamoto wrote: > >>> From: Hiroshi Shimamoto <h-shimam...@ct.jp.nec.com> > >>> > >>> Introduce module parameter "disable_hw_vlan_filter" to disable HW VLAN > >>> filter on ixgbe module load. > >>> > >>> From the hardware limitation, there are only 64 VLAN entries for HW VLAN > >>> filter, and it leads to limit the number of VLANs up to 64 among PF and > >>> VFs. For SDN/NFV case, we need to handle unlimited VLAN packets on VF. > >>> In such case, every VLAN packet can be transmitted to each VF. > >>> > >>> When we try to make VLAN devices on VF, the 65th VLAN registration fails > >>> and never be able to receive a packet with that VLAN tag. > >>> If we do the below command on VM, ethX.65 to ethX.100 cannot be created. > >>> # for i in `seq 1 100`; do \ > >>> ip link add link ethX name ethX.$i type vlan id $i; done > >>> > >>> There is a capability to disable HW VLAN filter and that makes all VLAN > >>> tagged packets can be transmitted to every VFs. After VLAN filter stage, > >>> unicast packets are transmitted to VF which has the MAC address same as > >>> the transmitting packet. > >>> > >>> With this patch and "disable_hw_vlan_filter=1", we can use unlimited > >>> number of VLANs on VF. > >>> > >>> Disabling HW VLAN filter breaks some NIC features such as DCB and FCoE. > >>> DCB and FCoE are disabled when HW VLAN filter is disabled by this module > >>> parameter. > >>> Because of that reason, the administrator has to know that before turning > >>> off HW VLAN filter. > >> You might also want to note that it makes the system susceptible to > >> broadcast/multicast storms since it eliminates any/all VLAN isolation. > >> So a broadcast or multicast packet on one VLAN is received on ALL > >> interfaces regardless of their VLAN configuration. In addition the > >> current VF driver is likely to just receive the packet as untagged, see > >> ixgbevf_process_skb_fields(). As a result one or two VFs can bring the > >> entire system to a crawl by saturating the PCIe bus via > >> broadcast/multicast traffic since there is nothing to prevent them from > >> talking to each other over VLANs that are no longer there. > > that's right. > > > > On the other hand, an untagged packet is not isolated, > > doesn't it same broadcast/multicast storm on untagged network? > > Yes, that is one of the reasons for VLANs. It provides isolation so > that if you have two entities on the same network you won't have entity > A able to talk to entity B. The problem is with VLAN promiscuous > enabled if entity B is a VF it will see the traffic but has no way to > know that it was VLAN tagged and a part of entity A's VLAN.
Sorry, I guess I failed to make a question to clarify. Occupying PCIe bus with broadcast/multicast packets causes performance degradation. VLAN filter can isolate traffic and reduce PCIe bus usage, but untagged broadcast/multicast traffic is still problem, I think. What is difference between tagged packet and untagged packet? > > > > >> For the sake of backwards compatibility I would say that a feature like > >> this should be mutually exclusive with SR-IOV as well since it will > >> cause erratic behavior. The VF will receive requests from all VLANs > >> thinking the traffic is untagged, and then send replies back to VLAN 0 > >> even though that isn't where the message originated. > > Sorry, I couldn't catch the above part. > > Could you explain a bit more? > > > > thanks, > > Hiroshi > > > >> Until the VF issue > >> is fixed this type of feature is a no-go. > > > > The current behavior for a VF is that if it receives a VLAN that it > didn't request it assumes it is operating in port VLAN mode. The > problem is with your patch the VF will be receiving all traffic but have > no idea which VLAN it came from. As a result it could be replying to > multicast or broadcast requests on one VLAN with the wrong VLAN ID. > > The VLAN behavior of the VF drivers will need to be fixed before > something like that could be supported with ANY of the VFs. As such you > will probably need to fix the VF driver in order to allow any of them to > come online when VLAN filtering is disabled, as the driver will need to > report the VLAN tag ID up to the stack. Thanks, that explains cleaner, I think I got the issue. I have to check the exact behavior on my box to understand correctly, will do. thanks, Hiroshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
