From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6645DC10F03 for ; Thu, 25 Apr 2019 07:12:47 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3203820685 for ; Thu, 25 Apr 2019 07:12:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="J6h3bWdB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3203820685 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=47g3rE1V3DNnJFX0rm9SWqTleGITKp5sgbJ2UPIgrS8=; b=J6h3bWdBtDiwJ4 tRzPdv2Es3KhIoxNEf3Q+dGG6MSdvbfGtipM0R/pm1cI0a6RNBnrrb2CrkwOlAXrX34W5MPLIiTHS ljESG4CLNeWQvUquY3zrBdEY2rqfWw7+F6fYFs6rV0+V4MDpSO6ig3bHUzCnva4jfGMUMOPKDVqYX o0b84si0SlDXoQvvUKM4mWcFeX3MgAjNoTC83Mwl9t5jpGGHYpRhSmZz6QdGizdwkbGATJz7gzF58 el7AaWv861YdTohBqREC4nyv3hYRlH0CoQLxnNq5+N8LHyCEYLSKoDf1SUJRy3w2hA7uj1yZzzT3h tPqPe8xvCwt2ZFqh38/g==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hJYYi-0000zo-Hc; Thu, 25 Apr 2019 07:12:40 +0000 Received: from relay11.mail.gandi.net ([217.70.178.231]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hJYYe-0000yz-Eq for linux-arm-kernel@lists.infradead.org; Thu, 25 Apr 2019 07:12:38 +0000 Received: from bootlin.com (aaubervilliers-681-1-27-33.w90-88.abo.wanadoo.fr [90.88.147.33]) (Authenticated sender: maxime.chevallier@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 731C2100012; Thu, 25 Apr 2019 07:12:23 +0000 (UTC) Date: Thu, 25 Apr 2019 09:12:22 +0200 From: Maxime Chevallier To: Saeed Mahameed Subject: Re: [PATCH net-next v2] net: mvpp2: cls: Add Classification offload support Message-ID: <20190425091222.421f37c9@bootlin.com> In-Reply-To: <78f50363899afdd2a5ca2c8895cafa3b6e6c13ce.camel@mellanox.com> References: <20190423075031.26074-1-maxime.chevallier@bootlin.com> <20190424090123.5089586c@bootlin.com> <78f50363899afdd2a5ca2c8895cafa3b6e6c13ce.camel@mellanox.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190425_001236_802055_4D188B9D X-CRM114-Status: GOOD ( 22.03 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "antoine.tenart@bootlin.com" , "netdev@vger.kernel.org" , "gregory.clement@bootlin.com" , "linux@armlinux.org.uk" , "linux-kernel@vger.kernel.org" , "nadavh@marvell.com" , "thomas.petazzoni@bootlin.com" , "miquel.raynal@bootlin.com" , "stefanc@marvell.com" , "mw@semihalf.com" , "davem@davemloft.net" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Saeed, On Wed, 24 Apr 2019 18:05:51 +0000 Saeed Mahameed wrote: >Maybe ethtool doesn't do anything with the return value, but if the >user is not using any special flag, then the interpretation should be >absolute location/ID as provided by the user, see below scenario >example > >> The point for doing so is that we have a clear separation in our >> classification tables between different traffic classes, so we have a >> range of entries for tcp4, one for udp4, one for tcp6, etc. >> >> Having a "global" location numbering scheme would, I think, also be >> confusing, since it would make the user use loc 0->7 for tcp4, loc >> 8->15 for udp4 and so on. >> > >why ? even with your hw clear class separation, user can use any loc >for udp4 and tcp4 or any flow for that matter, in case they won't >overlap. > >And in case they do overlap, then I think you must have a global >location scheme! take this scenario for instance: > >scenario 1: >loc 0 ip4 action 2 >loc 1 udp4 action -1 >loc 2 tcp4 action -1 > >This should result of all udp4, tcp4, and ip4 traffic to go to rx ring >2, even if the user asked to drop udp/tcp4. once rule at location 0 is >deleted then udp/tcp4 traffic will be dropped. > >scenario 2: >loc 0 udp4 action -1 >loc 1 tcp4 action -1 >loc 2 ip4 action 2 > >should result in dropping all upd4/tcp4 but allow receiving ip4 on ring >4. > >User doesn't see and should not see your hw tables scheme, i feel that >for scenario 1 your implementation will drop udp4 and tcp4 since they >will be separated from ip4 rule at loc 0, which is not what the user >expects, please correct me if i am wrong. You're correct, this is what's going to happen with the current implementation. >that being said, i think you should keep the global location scheme at >least from user perspective and respect the prioritization of the user >inserted rules especially when there are overlapping. > >even if there is no overlapping, location could mean: priorities rules >at lower locations in hw processing so they can get higher performance. Ok, I'll have to rework the design of the tables a bit to be compliant with this, but this is achievable. I'll make sure to CC you on next revisions. >> Maybe in this case I should stick with insertions thay rely on >> (such as "first", "last", "any") and have a scheme >> where priorisation is based strictly on the rule insertion order ? >> > >Sure for when the special flags are set, but you will have to report >RX_CLS_LOC_SPECIAL on ETHTOOL_GRXCLSRLCNT. > >also if you don't want to support the global location scheme then >return -EOPNOTSUPP/-EINVAL when user specifies a non special location >? Given your review, I'll keep support for the global location scheme. >> > So the above example should result in one flow rule in your >> > hardware. >> > but according the code below the calculated index in >> > mvpp2_ethtool_cls_rule_ins might end up different than the >> > requested >> > location, which will confuse the user. >> >> I'm also working on writing a proper documentation for this driver, >> including the behaviour of the classifier implementation, hopefully >> this would help. >> > >hmm, i think all driver should be aligned and provide same behavior, at >least for the non special flag use case, >vendors must report -EOPNOTSUPPORT if a specific use case operation is >not supported. I agree, I'll however document what the limitations are in terms of supported features, etc. Thanks for the clarifications, it really helps a lot. Maxime _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel