From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from shards.monkeyblade.net ([184.105.139.130]:36068 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1034028AbeCAShD (ORCPT ); Thu, 1 Mar 2018 13:37:03 -0500 Date: Thu, 01 Mar 2018 13:36:58 -0500 (EST) Message-Id: <20180301.133658.1008622033674396104.davem@davemloft.net> To: ecree@solarflare.com Cc: linux-net-drivers@solarflare.com, netdev@vger.kernel.org, linville@tuxdriver.com Subject: Re: [PATCH RESEND net-next 0/2] ntuple filters with RSS From: David Miller In-Reply-To: <85718e87-e999-abb7-4a84-84858ee86a8e@solarflare.com> References: <85718e87-e999-abb7-4a84-84858ee86a8e@solarflare.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: From: Edward Cree Date: Tue, 27 Feb 2018 17:59:12 +0000 > This series introduces the ability to mark an ethtool steering filter to use > RSS spreading, and the ability to create and configure multiple RSS contexts > with different indirection tables, hash keys, and hash fields. > An implementation for the sfc driver (for 7000-series and later SFC NICs) is > included in patch 2/2. > > The anticipated use case of this feature is for steering traffic destined for > a container (or virtual machine) to the subset of CPUs on which processes in > the container (or the VM's vCPUs) are bound, while retaining the scalability > of RSS spreading from the viewpoint inside the container. > The use of both a base queue number (ring_cookie) and indirection table is > intended to allow re-use of a single RSS context to target multiple sets of > CPUs. For instance, if an 8-core system is hosting three containers on CPUs > [1,2], [3,4] and [6,7], then a single RSS context with an equal-weight [0,1] > indirection table could be used to target all three containers by setting > ring_cookie to 1, 3 and 6 on the respective filters. We really should have the ethtool interfaces under deep freeze until we convert it to netlink or similar. Second, this is a real hackish way to extend ethtool with new semantics. A structure changes layout based upon a flag bit setting in an earlier member? Yikes... Lastly, there has been feedback asking how practical and useful this facility actually is, and you must address that.