Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp708965pxj; Wed, 16 Jun 2021 11:42:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz7ekFSCit4nrhkoeYbMUPVpW4RqrtU9QK7jwEQKirEUPir8LzTsQIPuPJ9sre9Wh3SC4kX X-Received: by 2002:a17:906:b191:: with SMTP id w17mr1003635ejy.10.1623868952270; Wed, 16 Jun 2021 11:42:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623868952; cv=none; d=google.com; s=arc-20160816; b=T0pMSUYnUQEQJGt15VTTyhpQA6ZcriWe4gPTdlRGVY8iyn06g859bTRQjGp57G5uoX bC/rOuaAoj0quoiHWbiPRkTFh62jXjmEP4XjJK8i3n78u5HccJ5bGMz++j1q0qnfAR2B L0ktQlCuSaqIoxIbq3mjXtPZy/qkSvBPMD63bQ8iwVKT9OqjauM2a8d6R+b9oO69xpBV +kOuWKuyEoUmuPF9t02+enKp3FSAYsEQPTgv3FNuoU1xncQAwN+4FLMQ0xPNEl9X0waG PLYoSiEm3VrUyrdQcn82orUt+pUxGnrRB+tIpCFlD6ZbBFv7cLrXs5MsEP3qiiUbodkb rPOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=8b/okOVnhsmC8WOydmuYGzKaGTkrkLvWV3Zt6yVl/cU=; b=ZHc5Zjmr3d/9UvsYOCc4BVbnQfRu8cVvzBXon0RVpP7+RFfnJRje+4VF3+GVBBbO0n d+RQqo2ACZr25c9uwJE94Capp8aj6GllEa82IYb9kfOIMSRb/BqcbFiwcElKkArziC2F a1Y3QuCzCzOUF1E1qRsJWGeg05v4k656bnKigY/KNAJmFJjpKj5SMXSCtaLxXSGQaBM+ HHx0iGwD1A5BSUChfWjZBGTMt1hD5KIaJ9Z4JnOP4ZW9J9aaUs5WnPcVGvZml7FYoQiA chb4lCHTPsKtCDz3o5X+7zPWEPSBCB6L/7rFcK9+gxaW/58wKylgnqBP87Eld+EcXVgT gtyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ems3Z3Wy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a20si3604090edj.403.2021.06.16.11.42.09; Wed, 16 Jun 2021 11:42:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ems3Z3Wy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232934AbhFPNJS (ORCPT + 99 others); Wed, 16 Jun 2021 09:09:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233003AbhFPNJL (ORCPT ); Wed, 16 Jun 2021 09:09:11 -0400 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0596C06175F; Wed, 16 Jun 2021 06:07:04 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id ba2so2626296edb.2; Wed, 16 Jun 2021 06:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=8b/okOVnhsmC8WOydmuYGzKaGTkrkLvWV3Zt6yVl/cU=; b=Ems3Z3Wy4snMpUrp8UAukFpyWqZQ0pcxSa8V7C/OJuxQkMFvihA8spkzlKwoqQptit fao5ZPLzxEjQOJqyRqaZb/zdZKOkubHt6s95lUHtA1q7SKGfo1Lyf8aS5LOMhcytxf82 MbYDOB0xSaZbOdhz12E+ltKWAMCAYJ3Or4IB0MEVZYxiqQHFx1FG2mjNUomNgvtDvQ3E RDI43w/LTEWPlK4/HYJfxI1bDimcsvNaWeoU3yz2lBIH6xBOqLO0owznKx/qmke4ZdzR Gln82sQMEshK1Zm14NgIQvJYMwg8Ix3i6qtKNZhsrY+3sMHCBPcb/EEtrqVxpyNVXR95 yO6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=8b/okOVnhsmC8WOydmuYGzKaGTkrkLvWV3Zt6yVl/cU=; b=laOJMyBxKNFr+2ZEQuevKjmIHm5NdCpJe9nEOD0JA/wOb4U3m/5m1KRbaAV1WTbk7W NUVK91rC5F2WoLeXhHjXzp1adKU3BNkmAhhiEB/0vZV2wZH9W+EG6VU5IdVbdSxhUwzL p3daExBSODqXPSHcxqyAa8BdvMmjruDDRH0crb53VvsF1U8uz3jdDz8QNn8ii0ZV778K F3btcOvfbegX7s5GafQIdVduRtHG8tEs55yt3DzKZDkVL5+QshueqNK8T3RZYEMmsolm qHEjRmeYSJfefMkdF25TNlanZdHaJ0Pk7nwJlWvwsC66wjnsSVRu+mPNNy5zt8W97iAx o0rQ== X-Gm-Message-State: AOAM532B7zbgVolxseq5YpdulqVQG63h1mBe9dnPFYGJzQpVeovprUhX Qu/v6564zanvcgutxralwkY= X-Received: by 2002:a05:6402:b76:: with SMTP id cb22mr4092635edb.112.1623848823499; Wed, 16 Jun 2021 06:07:03 -0700 (PDT) Received: from skbuf ([188.26.224.68]) by smtp.gmail.com with ESMTPSA id qq26sm1555929ejb.6.2021.06.16.06.07.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Jun 2021 06:07:03 -0700 (PDT) Date: Wed, 16 Jun 2021 16:07:01 +0300 From: Vladimir Oltean To: Vadym Kochan Cc: "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org, Andrew Lunn , Taras Chornyi , linux-kernel@vger.kernel.org, Mickey Rachamim , Serhiy Boiko , Volodymyr Mytnyk , Vadym Kochan Subject: Re: [PATCH net-next 1/2] net: marvell: Implement TC flower offload Message-ID: <20210616130701.e4k2izlthmj5j6yc@skbuf> References: <20210615125444.31538-1-vadym.kochan@plvision.eu> <20210615125444.31538-2-vadym.kochan@plvision.eu> <20210616005453.cuu3ocedgfcafa7o@skbuf> <20210616130424.GB9951@plvision.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210616130424.GB9951@plvision.eu> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 16, 2021 at 04:04:24PM +0300, Vadym Kochan wrote: > Hi Vladimir, > > On Wed, Jun 16, 2021 at 03:54:53AM +0300, Vladimir Oltean wrote: > > On Tue, Jun 15, 2021 at 03:54:43PM +0300, Vadym Kochan wrote: > > > +static int prestera_port_set_features(struct net_device *dev, > > > + netdev_features_t features) > > > +{ > > > + netdev_features_t oper_features = dev->features; > > > + int err; > > > + > > > + err = prestera_port_handle_feature(dev, features, NETIF_F_HW_TC, > > > + prestera_port_feature_hw_tc); > > > > Why do you even make NETIF_F_HW_TC able to be toggled and not just fixed > > to "on" in dev->features? If I understand correctly, you could then delete > > a bunch of refcounting code whose only purpose is to allow that feature > > to be disabled per port. > > > > The only case where it can be used is when user want to disable TC > offloading and apply set of rules w/o skip_hw. > > So you think it is OK to not having an ability to disable offloading at > all ? Because adding "skip_hw" is already possible per filter in the first place, I don't think that this feature justifies the added complexity, no.