From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <changchun.ouyang@intel.com>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
by dpdk.org (Postfix) with ESMTP id 5D44AC642
for <dev@dpdk.org>; Thu, 30 Jul 2015 03:23:16 +0200 (CEST)
Received: from orsmga002.jf.intel.com ([10.7.209.21])
by orsmga101.jf.intel.com with ESMTP; 29 Jul 2015 18:23:16 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.15,574,1432623600"; d="scan'208";a="774033973"
Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91])
by orsmga002.jf.intel.com with ESMTP; 29 Jul 2015 18:23:13 -0700
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server (TLS)
id 14.3.224.2; Thu, 30 Jul 2015 09:23:12 +0800
Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.126]) by
SHSMSX104.ccr.corp.intel.com ([169.254.5.45]) with mapi id 14.03.0224.002;
Thu, 30 Jul 2015 09:23:11 +0800
From: "Ouyang, Changchun" <changchun.ouyang@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Thread-Topic: [dpdk-dev] [PATCH 2/2] virtio: allow running w/o vlan filtering
Thread-Index: AQHQyf48V4ZPWp0Ry0SAJIO89fktuJ3zNEhQ
Date: Thu, 30 Jul 2015 01:23:10 +0000
Message-ID: <F52918179C57134FAEC9EA62FA2F962511C5123E@shsmsx102.ccr.corp.intel.com>
References: <1425602726-26538-1-git-send-email-stephen@networkplumber.org>
<F52918179C57134FAEC9EA62FA2F962511A0C194@shsmsx102.ccr.corp.intel.com>
<20150306082436.43415409@urahara> <205454145.ebl7zG6qks@xps13>
In-Reply-To: <205454145.ebl7zG6qks@xps13>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2015 01:23:16 -0000
I have comments for that.
Pls see below.
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, July 29, 2015 8:57 PM
> To: Ouyang, Changchun
> Cc: dev@dpdk.org; Stephen Hemminger
> Subject: Re: [dpdk-dev] [PATCH 2/2] virtio: allow running w/o vlan filter=
ing
>=20
> Back on this old patch, it seems justified but nobody agreed.
>=20
> --- 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;
> }
>=20
> 2015-03-06 08:24, Stephen Hemminger:
> > "Ouyang, Changchun" <changchun.ouyang@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.
Yes, vlan filter is an option, but currently virtio driver has no software =
solution for vlan filter.
So I would like to disable hw_vlan_filter in rxmode if the dev can't really=
support it rather than removing the return there.
> > >
> > > The question is that guest only send command, no real action to do th=
e
> vlan filter.
> > > So if both host and guest have no real action for vlan filter, who wi=
ll 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
There is vlan strip, but have no vlan filter in the rx function.
> > 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"