Back on this old patch, it seems justified but nobody agreed.
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -1288,7 +1288,6 @@ virtio_dev_configure(struct rte_eth_dev *dev)
&& !vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_VLAN)) {
PMD_DRV_LOG(NOTICE,
"vlan filtering not available on this host");
- return -ENOTSUP;
}
2015-03-06 08:24, Stephen Hemminger:
> "Ouyang, Changchun" <changchun.ouyang at intel.com> wrote:
> > > From: Stephen Hemminger
> > > Vlan filtering is an option, and not a requirement.
> > > If host does not support filtering then it can be done in software.
> >
> > The question is that guest only send command, no real action to do the vlan
> > filter.
> > So if both host and guest have no real action for vlan filter, who will do
> > it?
>
> The virtio driver has features.
> Guest can not send commands to host where feature bit not enabled.
> Application can call filter_set and check if filter worked or not.
>
> Our code already had to do MAC and VLAN validation of incoming packets
> therefore if hardware can't do vlan match, there is no problem.
> I would expect other applications would do the same thing.
>
> Failing during configuration is bad. DPDK API should never force
> application to play "guess the working configuration" with the device
> driver or do string match on "which device is this anyway"
