From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Miroslaw Subject: Re: [PATCH 04/13] acl: allow zero verdict Date: Tue, 13 Dec 2016 17:43:28 +0100 Message-ID: <20161213164327.faeihscaq7zdxazk@rere.qmqm.pl> References: <2601191342CEEE43887BDE71AB9772583F0E6E0B@irsmsx105.ger.corp.intel.com> <20161213135443.ovmlunbh67dr4tew@rere.qmqm.pl> <2601191342CEEE43887BDE71AB9772583F0E7008@irsmsx105.ger.corp.intel.com> <20161213145308.lqqnm6ivryjfxih7@rere.qmqm.pl> <2601191342CEEE43887BDE71AB9772583F0E736D@irsmsx105.ger.corp.intel.com> <20161213161409.ekbagsze5pcy2ppl@rere.qmqm.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Cc: "dev@dpdk.org" To: "Ananyev, Konstantin" Return-path: Received: from rere.qmqm.pl (rere.qmqm.pl [84.10.57.10]) by dpdk.org (Postfix) with ESMTP id 00801106A for ; Tue, 13 Dec 2016 17:43:28 +0100 (CET) Content-Disposition: inline In-Reply-To: <20161213161409.ekbagsze5pcy2ppl@rere.qmqm.pl> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Dec 13, 2016 at 05:14:09PM +0100, Michal Miroslaw wrote: > On Tue, Dec 13, 2016 at 03:13:42PM +0000, Ananyev, Konstantin wrote: [...] > > > Dear Konstantin, > > > > > > Can you describe how the ACL code treats zero specially? I could not find > > > anything, really. The only thing I found is that iff I use zero userdata > > > in a rule I won't be able to differentiate a case where it matched from > > > a case where no rule matched. > > > > Yes, that's what I am talking about. > > > > > If I all my rules have non-zero userdata, > > > then this patch changes nothing. > > > > Ok, then why do you remove a code that does checking for invalid userdata==0? > > That supposed to prevent user to setup invalid value by mistake. > > > > But if I have a table where 0 means drop > > > (default-drop policy) then being able to use zero userdata in DROP rules > > > makes the ACLs just that more useful. > > > > Ok, and what prevents you from do +1 to your policy values before > > you insert it into the ACL table and -1 after you retrieved it via rte_acl_classify()? > > The check is enforcing an assumption that all users want to distinguish > the cases whether any rule matched and whether no rules matched. Not all > users do, hence the assumption is invalid and this patch removes it. > > Yes, people can work around it by loosing 1 of 2^32 useful values and > convoluting their code. > > You seem to argue that 0 is somehow an invalid value, but I can't find > anything in the ACL that would require it to be so. Could you point me > to the code in DPDK where this actually matters? I just noticed that it's probably you who wrote most of the ACLs code, so I guest you're the right person to ask the question above. Nice work, BTW. :-) Best Regards, Michał Mirosław