From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 79A2B26AC1 for ; Thu, 22 Aug 2024 14:41:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724337673; cv=none; b=CVmrwzEekGEq/8/b8RReY24mQwwEuZvE4T9f27Udihow+MDZ1VtR9pPkB9ZlRbAnZIP4XLAcv0bpXLrmFgsZHbI+pO10CWpTlA1vtQT9Xg51aVckDFbBTVZJCRNZFlKAh8E2grlGoqK/IVvGSjD7uqiGwoKSN2kCULXKEdUEcrE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724337673; c=relaxed/simple; bh=HRGyu2ZLDmHAVY6/VBIUN7nMaIP/UYvPrcnsTJQHVWk=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=c13ZR6FOjiVj+7xV0TDilxqYXG03iOdg96MC8MS73fxI1vPKhqSokpIpWtdj0vm/IjciMk9p1PTvYC+bReyetFDeEoJsuhsCnl3uqnJBA3ZM3c2xjgJPxS2TvvFs+DNsq+IbUL4mNFOju1A3kFKy8cyYrsz3FMH9cyONrDxawnw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m2EfJKBB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="m2EfJKBB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDDC8C32782; Thu, 22 Aug 2024 14:41:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724337673; bh=HRGyu2ZLDmHAVY6/VBIUN7nMaIP/UYvPrcnsTJQHVWk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=m2EfJKBB3NbfouVEn/2erHSA1+P7DCvt9YOm0U7HNp7wP7bGP25+pwVhd4srRQUMC ovBQl2PgX5gVwAaMlAyNoyDA0jUNtBSz8Kvg8C9dMAEZyzgtFR90G7zE0HweyunbcD MrE2k5VwHNvdAdKhVCEgh63rGVko5POC1cFh8/XG0A1lSHXr8BUrrtevmuCZkw9vl3 nlECmoC+ufYAbjLg8+sL5AzLGDvqFBNWCkw6gnTd9N/9mMpwrMgR1qLjei2n8vHTIe Nn5eRV0+Zpfo2M7yRlwo0jApQBKKwy3elKS8RrHaZgGnZodSmW4ZCGfTm1P8WqFJJL edixU3NdbaOFQ== Date: Thu, 22 Aug 2024 07:41:12 -0700 From: Jakub Kicinski To: Jiri Pirko Cc: Paolo Abeni , netdev@vger.kernel.org, Madhu Chittim , Sridhar Samudrala , Simon Horman , John Fastabend , Sunil Kovvuri Goutham , Jamal Hadi Salim Subject: Re: [PATCH v3 03/12] net-shapers: implement NL get operation Message-ID: <20240822074112.709f769e@kernel.org> In-Reply-To: References: <7ed5d9b312ccda58c3400c7ba78bca8e5f8ea853.1722357745.git.pabeni@redhat.com> <4cb6fe12-a561-47a4-9046-bb54ad1f4d4e@redhat.com> <47b4ab84-2910-4501-bbc8-c6a9b251d7a5@redhat.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 22 Aug 2024 14:02:54 +0200 Jiri Pirko wrote: >>> This is what I understood was a plan from very beginning. >> >> Originally the scope was much more limited than what defined here. Jakub >> asked to implement an interface capable to unify the network device >> shaping/rate related callbacks. > > I'm not saying this is deal breaker for me. I just think that if the api > is designed to be independent of the object shaper is bound to > (netdev/devlink_port/etc), it would be much much easier to extend in the > future. If you do everything netdev-centric from start, I'm sure no > shaper consolidation will ever happen. And that I thought was one of the > goals. > > Perhaps Jakub has opinion. I think you and I are on the same page :) Other than the "reference object" (netdev / devlink port) the driver facing API should be identical. Making it possible for the same driver code to handle translating the parameters into HW config / FW requests, whether they shape at the device (devlink) or port (netdev) level. Shaper NL for netdevs is separate from internal representation and driver API in my mind. My initial ask was to create the internal representation first, make sure it can express devlink and handful of exiting netdev APIs, and only once that's merged worry about exposing it via a new NL. I'm not opposed to showing devlink shapers in netdev NL (RO as you say) but talking about it now strikes me as cart before the horse.