From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id BC142A56E for ; Wed, 5 Aug 2015 03:04:06 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 04 Aug 2015 18:03:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,612,1432623600"; d="scan'208";a="536150168" Received: from kmsmsx152.gar.corp.intel.com ([172.21.73.87]) by FMSMGA003.fm.intel.com with ESMTP; 04 Aug 2015 18:03:46 -0700 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by KMSMSX152.gar.corp.intel.com (172.21.73.87) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 5 Aug 2015 09:01:55 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.126]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.188]) with mapi id 14.03.0224.002; Wed, 5 Aug 2015 09:01:54 +0800 From: "Ouyang, Changchun" To: Vincent JARDIN , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH 2/2] virtio: allow running w/o vlan filtering Thread-Index: AQHQyf48V4ZPWp0Ry0SAJIO89fktuJ37To0AgAFM4EA= Date: Wed, 5 Aug 2015 01:01:53 +0000 Message-ID: References: <1425602726-26538-1-git-send-email-stephen@networkplumber.org> <20150306082436.43415409@urahara> <205454145.ebl7zG6qks@xps13> <55C0B564.1090509@6wind.com> In-Reply-To: <55C0B564.1090509@6wind.com> 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" 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, 05 Aug 2015 01:04:07 -0000 Hi Vincent, > -----Original Message----- > From: Vincent JARDIN [mailto:vincent.jardin@6wind.com] > Sent: Tuesday, August 4, 2015 8:52 PM > To: Thomas Monjalon; Ouyang, Changchun > Cc: dev@dpdk.org; Stephen Hemminger > Subject: Re: [dpdk-dev] [PATCH 2/2] virtio: allow running w/o vlan filter= ing >=20 > Thomas, Changchun, >=20 > 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" 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. >=20 > +1 with Stephen, remove return -ENOTSUP; >=20 > applications must not fail, software stacks will handle it. We did experi= ment Do you mean handling it in software stack outside the virtio pmd? AFAIK, inside virtio PMD, we have no codes to handle it currently. > some issues when testpmd was failing while it was supposed to run. A noti= ce > would be good enough. >=20 Use '--disable-hw-vlan-filter' in testpmd command line will allow it conti= nue to work.=20 You can have a try. >=20 > >>> > >>> 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 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" >=20 > Agree, it is not a failure of a configuration, it is a failure of negotia= tion of > virtio's capabilities. I am not sure which one is better when app configures one feature but fail = to negotiate it with host(which means has no such capability to support this feature currently). 1)The driver cheat the app, and continue to do the rest of work(of course n= eed some hints). 2)give hints and exit, then user re-run app with correct configuration. >=20 > 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 f= ail > and return -ENOTSUP? I think user mode driver/app and kernel is different thing :-) Changchun