Message ID | 205454145.ebl7zG6qks@xps13 (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 5B81DE62; Wed, 29 Jul 2015 14:58:02 +0200 (CEST) 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 <dev@dpdk.org>; Wed, 29 Jul 2015 14:58:00 +0200 (CEST) Received: by wicgb10 with SMTP id gb10so199443152wic.1 for <dev@dpdk.org>; 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 <thomas.monjalon@6wind.com> To: "Ouyang, Changchun" <changchun.ouyang@intel.com> 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> <F52918179C57134FAEC9EA62FA2F962511A0C194@shsmsx102.ccr.corp.intel.com> <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 <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> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Thomas Monjalon
July 29, 2015, 12:56 p.m. UTC
Back on this old patch, it seems justified but nobody agreed. > "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. > > > > 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"
Comments
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 filtering > > 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@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 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 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"
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@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, Vincent
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 filtering > > 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@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 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 notice > would be good enough. > Use '--disable-hw-vlan-filter' in testpmd command line will allow it continue to work. You can have a try. > > >>> > >>> 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. 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 need some hints). 2)give hints and exit, then user re-run app with correct configuration. > > 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? I think user mode driver/app and kernel is different thing :-) Changchun
In Linux and BSD, if driver does not support filtering, the kernel takes care of the situation. A DPDK application will need a device layer; maybe some part of the port/pipeline would be a good place for it. On Tue, Aug 4, 2015 at 6:01 PM, Ouyang, Changchun < changchun.ouyang@intel.com> wrote: > > 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 > filtering > > > > 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@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 > 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 > notice > > would be good enough. > > > > Use '--disable-hw-vlan-filter' in testpmd command line will allow it > continue to work. > You can have a try. > > > > > >>> > > >>> 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. > > 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 > need some hints). > 2)give hints and exit, then user re-run app with correct configuration. > > > > > 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? > I think user mode driver/app and kernel is different thing :-) > > Changchun > >
> Use '--disable-hw-vlan-filter' in testpmd command line will allow it continue to work. > You can have a try. Yes, but not using this flag should not imply to exit. > 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 need some hints). > 2)give hints and exit, then user re-run app with correct configuration. Same as Stephen: 3) give hints of capabilities, do not exit, then user app does whatever it wants (including exit if needed). Thank you,
2015-08-05 12:49, Vincent JARDIN: > > Use '--disable-hw-vlan-filter' in testpmd command line will allow it continue to work. > > You can have a try. > > Yes, but not using this flag should not imply to exit. > > > 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 need some hints). > > 2)give hints and exit, then user re-run app with correct configuration. > > Same as Stephen: > > 3) give hints of capabilities, do not exit, then user app does whatever > it wants (including exit if needed). I would tend to apply this patch but as it was discussed we need some clear acknowledgement. Huawei?
This is a very old thread which has no conclusion. Now that we have more experience with virtio, could we try to fix it properly? http://dpdk.org/patch/3897/ 2015-10-21 15:58, Thomas Monjalon: > 2015-08-05 12:49, Vincent JARDIN: > > > Use '--disable-hw-vlan-filter' in testpmd command line will allow it continue to work. > > > You can have a try. > > > > Yes, but not using this flag should not imply to exit. > > > > > 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 need some hints). > > > 2)give hints and exit, then user re-run app with correct configuration. > > > > Same as Stephen: > > > > 3) give hints of capabilities, do not exit, then user app does whatever > > it wants (including exit if needed). > > I would tend to apply this patch but as it was discussed we need some > clear acknowledgement. > Huawei?
--- 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: