[dpdk-dev] [PATCH 2/2] virtio: allow running w/o vlan filtering

Vincent JARDIN vincent.jardin at 6wind.com
Tue Aug 4 14:51:48 CEST 2015

Thomas, Changchun,

On 29/07/2015 14:56, Thomas Monjalon wrote:
> 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.

+1 with Stephen, remove return -ENOTSUP;

applications must not fail, software stacks will handle it. We did 
experiment some issues when testpmd was failing while it was supposed to 
run. A notice would be good enough.

>>> 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"

Agree, it is not a failure of a configuration, it is a failure of 
negotiation of virtio's capabilities.

Let's use another example: we do not expect a guest kernel to panic() 
because it is not properly negotiated? So why should a DPDK application 
fail and return -ENOTSUP?

Thank you,

More information about the dev mailing list