From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 2D8DB2A66 for ; Tue, 25 Oct 2016 23:14:16 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id c78so47794528wme.0 for ; Tue, 25 Oct 2016 14:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=BmRdLCayNf1cto1W5SDoWxnsrINt5i1cAl6Y03ZiuHI=; b=JTt0ME5502Y0Xt7QEdAFYAr6w9qR0jgbeMYL4oLZ3BDG5SPtyMA2X/lQ2jxWaFO8GZ AzdzncjW/UgLwE50WZUN0FozaDg5pFdMOgt8tE5IayW5OCvHW2KFcnycuxAGbyMmvgvl YzrvZlu55Ce/QvhwmgdO0opZC4nRHIBncP+90LtW+v4Z5/Cg9VU4uyIy+GL/7w/VXqVl Vff5+iPqEkFF4Ph2eEb0+JzGAIeqMi4pIUk8WLDF90Bb3hd50xvvp1By5S6S1O4wX06j dEy4As7Y/c4tuboZ7HLOcyFmX8GT7TqF4LvWuHGlsg53+9/Oqdsfe/VgXB8OdYKDqpgI gZUg== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=BmRdLCayNf1cto1W5SDoWxnsrINt5i1cAl6Y03ZiuHI=; b=btGpfpV68uGNzCGrvks3uhstX3kk5/1p3SMVd22ENPzvKxZ81DjAPMPgW0M9ChX6ka ZEgHotgWZF0V2p4g4/9fwFEQycp/mqfTx25m4WwocTFqlK2lGZZff7nzknZwsKaZutR4 yqH0AzqaYaQJalbrhge/iGyNHlAI9mwuRasxOGIVL8czHDLnKtKDQiZ6XkiJOkMBDzDQ pge3yFzb6JaHDAxKKHKJ37TP3nL9nSp5Tr1R85c7+j67spmUAWL13+UGWWeGU/xpC06m GsN0SzubO2Aob81vNBjUmNwz3/uuxD1znVDn9IgseMZ/CQyZHgtzYRHExB2r9227oNn9 wEFA== X-Gm-Message-State: ABUngvfe0QqU6Pc4ODwaV3QrdZWjIBITm866rtK36XIFc4r7APCnNy6Nb2epsy4NdKKbhhBo X-Received: by 10.194.42.39 with SMTP id k7mr18103840wjl.212.1477430055897; Tue, 25 Oct 2016 14:14:15 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id rv12sm27155439wjb.29.2016.10.25.14.14.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Oct 2016 14:14:15 -0700 (PDT) From: Thomas Monjalon To: Frederico Cadete , "Frederico.Cadete-ext@oneaccess-net.com" Date: Tue, 25 Oct 2016 23:14:14 +0200 Message-ID: <2131812.eDc2xJHoTn@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1471943445-20696-1-git-send-email-Frederico.Cadete-ext@oneaccess-net.com> <9BB6961774997848B5B42BEC655768F80E273098@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] testpmd: fix fdir command on MAC and tunnel modes 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: Tue, 25 Oct 2016 21:14:16 -0000 2016-09-27 11:01, Frederico Cadete: > On Tue, Sep 27, 2016 at 4:42 AM, Wu, Jingjing wrote: > > From: Frederico.Cadete- > >> The flow_director_filter commands has a pf|vf option for most modes > >> except for MAC-VLAN and tunnel. On Intel NIC's these modes are not > >> supported under virtualized environments. > >> But the application was checking that this field was parsed for these cases, > >> even though this token is not registered with the cmdline parser. > >> > >> This patch skips checking of this field for the commands that don't accept it. > >> > >> Signed-off-by: Frederico Cadete [...] > > > > Thanks for the patch. > > And thanks a lot for the review. > > > But with this change the field of pf_vf cannot omit either. > > I think it still looks confused because it will allow any meaningless string. > > Sorry, I am not aware that it can be omitted. > For MAC/VLAN and tunnel mode it does not and will not allow any > meaningless string. > At least that was my intention :) > > The cmdline parser expects "... flexbytes (flexbytes_value) (drop|fwd) > queue ..." . > This is what is documented [1] and the command's cmdline_parse_inst_t > [2] matches this. > If you put something in-between "(drop|fwd)" and "queue" it is > rejected by the parser > in librte_cmdline. > > > In MAC_VLAN or TUNNEL mode, why not just use pf. > > With the current code, because if you write that in the command, it is > rejected by the parser :) > > Do you mean it would be preferable to make these commands always take > such an argument, > and only at the NIC driver check that it must equal PF for MAC_VLAN or > TUNNEL mode? > The command becomes a bit more complicated for the current intel > NIC's, but as I understand > it currently does not work anyway. Unless I'm missing something else. > > > > > Maybe an optional field supporting on DPDK cmdline library is exactly what we > > Are waiting for :) > > Laudable goal! My excuses but it's beyond my current skills and bandwith :/ Thanks Frederico. Your approach has been re-submitted and fixed by Wenzhuo: http://dpdk.org/patch/16679