From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by dpdk.org (Postfix) with ESMTP id 5C5635A45 for ; Wed, 5 Aug 2015 03:22:10 +0200 (CEST) Received: by ioea135 with SMTP id a135so34955055ioe.1 for ; Tue, 04 Aug 2015 18:22:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y/KcLGxG7Tp8NyHrLOQeB6Xkya9xKGJIK9HxlE94Mo0=; b=GdcOI1atysD7Sesdg+f7mdL0Vrt+yVdJaPlU3m3mUGFrqaDFnUaOU6RUnxrZcBD/tB m1oWtXS3LCTWYi0FbzWW7HW8mRKjFuIaIlQO9kVs+y1PXlxMtJoyB1R+iAnRuzTZVWW9 fVs6sj9lqcd8uWacsYqQEvZkDyeCdGTTGRhuC4onF3hGM4qCl0D/0s9zu+uoORds+GTI IMi4QfW7OttqITunrmBVkoCC8acuOMcwjTERmoA2Gq6ho8T6bnhiycZXZszNbVL36Ch8 g3Zz+rSoprmwTMUScs2UdfMYjZ65VfGbdH2Rm3i9G9xm762sJQevsN6ETbGk1w0z4nFN gkNg== X-Gm-Message-State: ALoCoQkMgabPQexGfq/GkDhSdbwA4nMo58nCOnaC92asmNMnXjsC/ZGobjDXnQQ41FoaEJrlA51P MIME-Version: 1.0 X-Received: by 10.107.16.75 with SMTP id y72mr8612756ioi.122.1438737729800; Tue, 04 Aug 2015 18:22:09 -0700 (PDT) Received: by 10.64.197.39 with HTTP; Tue, 4 Aug 2015 18:22:09 -0700 (PDT) In-Reply-To: References: <1425602726-26538-1-git-send-email-stephen@networkplumber.org> <20150306082436.43415409@urahara> <205454145.ebl7zG6qks@xps13> <55C0B564.1090509@6wind.com> Date: Tue, 4 Aug 2015 18:22:09 -0700 Message-ID: From: Stephen Hemminger To: "Ouyang, Changchun" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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:22:10 -0000 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" 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 > >