On 03/11/2015 10:58 PM, Hiroshi Shimamoto wrote:I'm afraid that I could not explain what we want.
The problem is that unlike multicast promiscuous option that wasOn 03/10/2015 05:59 PM, Hiroshi Shimamoto wrote:Right, my explanation was not accurate.
From: Hiroshi Shimamoto <h-shimamoto@xxxxxxxxxxxxx>Technically it is 4096 VLANs that can be terminated in one NIC, only 63
Disable hardware VLAN filtering if netdev->features VLAN flag is dropped.
In SR-IOV case, there is a use case which needs to disable VLAN filter.
For example, we need to make a network function with VF in virtualized
environment. That network function may be a software switch, a router
or etc. It means that that network function will be an end point which
terminates many VLANs.
In the current implementation, VLAN filtering always be turned on and
VF can receive only 63 VLANs. It means that only 63 VLANs can be terminated
in one NIC.
VLANs can be routed to VFs/VMDq pools though. The PF receives all VLAN
traffic that isn't routed to a specific VF, but does pass the VFTA
registers.
>From the hardware limitation, there are 64 entries in the shared VLAN filter.
That means that only 64 VLANs can be used per port.
Our requirement is that we want to use VLANs without limitation in VF.
Currently there is only this way, disabling VLAN filter, I could find.
supported by the hardware there is nothing to limit this to any one VF.
So if you enable this feature you are not only allowing that one VF to
ignore the VLAN filter rules, but you are disabling them for the PF and
all VFs at once.
We want to use 4k VLANs in a VM which has VF.
I understand that when HW VLAN filter is disabled, all VFs and the PF loses
this functionality.
On the other hand, ixgbe chip can only have 64 VLANs and 64 VFs at most.VLANs are used for isolation, that is kind of the point of a VLAN. SoIs that VLAN filtering specific?On the other hand disabling HW VLAN filtering causes a SECURITY issueIt is worse than that. Now you also receive all broadcast packets on
that each VF can receive all VLAN packets. That means that a VF can see
any packet which is sent to other VF.
all VFs. It means that any of your systems could be buried in traffic
with a simple ping flood since it will multiply each frame by the number
of VFs you have enabled.
I understood that broadcast/multicast packets copied to VFs.
But I couldn't imagine the case each VF has and uses different VLAN.
for example if you had a multi-tenant data center you might use VLANs to
separate the systems that belong to each tenant. This way it appears
that they are off in their own little cloud and not affecting one
another. With VLANs disabled you strip that option away and as a result
you end up with each VF being able to see all of the broadcast/multicast
traffic from every other VF.
That means I think few number of VLANs can be used in each VF and some VLANs
or untagged VLAN may be shared among VFs, then there is broadcast/multicast
storm possibility already, that is just my feeling.
By the way, I think, there is another possibility of DoS by requesting much
number of VLANs from VF. That causes that later VFs cannot have their VLAN
because there are only 64 VLAN entries.
The first VM creates 64 VLANs that id 1-64, then start the second VM and the
second one fails to have requesting VLAN id 65 because there is no room.
I'm not sure why our use case is so unique.By the way, I wonder there is no one who is worried about this VLAN limitation.I believe that your use case if very unique. Specifically things like
thanks,
Hiroshi
VLANs are supposed to be in place to allow for isolation of networks.
Implementing router function, gateway and etc. could use much VLANs.
64 VLANs must be too small for those applications.
I just bring such application into VM and want to use SR-IOV for performance.
Usually an administrator of VM can use VLANs and ixgbevf seems to allow to
use VLAN as the administrator wants. But the hardware limitation of VLAN
filtering makes us to use VLAN harder in virtualized environment.
thanks,
Hiroshi