From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by dpdk.org (Postfix) with ESMTP id 90358CF9 for ; Wed, 29 Jul 2015 14:58:00 +0200 (CEST) Received: by wicgb10 with SMTP id gb10so199443152wic.1 for ; Wed, 29 Jul 2015 05:58:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=Vc0UqBugFz4gZfuK1Y4LV4rdtJ3bPfz8OGJQ+3caVRY=; b=BlOclbSQgTW8yUgRkpw2UcPq2+XN85V/gUI7A9unPQfAPeSAU3SuCusVZ6tyvuKJJk 0TBOaCV8SNFe3JlwfjaSin49MBjLyYrjEs255ordQoHtlF6LLKI9ZJtB8YYgAbwn140N m3GQtzcGKKP/UNkqm6BNcRxbAawudfU9DpKf9TRsCBLDKXADXrEhiG/bZsAOZ/xV998m 2W54EiKfZdR9HxdMHnUmct8HpfiPTH1mVKPR4SiKyP44bO6Y4OA9th7rzzZhf2XUzC8w DLI+1VoHJWKJkAFJcC1ANAO7yN0Od2cfyjlQ4d3Dzqin2cwqhaSM3TBDsNW0lHjevzV5 Hg6g== X-Gm-Message-State: ALoCoQklsfk3iiWNvTrvHTOh3tAhDDnelwywPN0r1j7RgSNehRzvXbWJvUpooF1TCLNa9VpXal5T X-Received: by 10.194.89.5 with SMTP id bk5mr79825089wjb.144.1438174680376; Wed, 29 Jul 2015 05:58:00 -0700 (PDT) Received: from xps13.localnet (6wind.net2.nerim.net. [213.41.151.210]) by smtp.gmail.com with ESMTPSA id c11sm24277592wib.1.2015.07.29.05.57.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2015 05:57:59 -0700 (PDT) From: Thomas Monjalon To: "Ouyang, Changchun" Date: Wed, 29 Jul 2015 14:56:45 +0200 Message-ID: <205454145.ebl7zG6qks@xps13> Organization: 6WIND User-Agent: KMail/4.14.8 (Linux/4.0.4-2-ARCH; KDE/4.14.8; x86_64; ; ) In-Reply-To: <20150306082436.43415409@urahara> References: <1425602726-26538-1-git-send-email-stephen@networkplumber.org> <20150306082436.43415409@urahara> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 2/2] virtio: allow running w/o vlan filtering X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 12:58:00 -0000 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" 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"