From patchwork Tue Sep 6 23:48:56 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ben Hutchings X-Patchwork-Id: 113681 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 55D08B6F7C for ; Wed, 7 Sep 2011 09:49:06 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755400Ab1IFXtB (ORCPT ); Tue, 6 Sep 2011 19:49:01 -0400 Received: from exchange.solarflare.com ([216.237.3.220]:45567 "EHLO exchange.solarflare.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755299Ab1IFXs7 (ORCPT ); Tue, 6 Sep 2011 19:48:59 -0400 Received: from [10.17.20.137] ([10.17.20.137]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Sep 2011 16:48:59 -0700 Subject: [PATCH net-next 2/4] ethtool: Explicitly state that RX NFC rule locations are priorities From: Ben Hutchings To: David Miller Cc: netdev@vger.kernel.org, Alexander Duyck , Sebastian Poehn , Santwona Behera In-Reply-To: <1315352693.2788.20.camel@bwh-desktop> References: <1315352693.2788.20.camel@bwh-desktop> Organization: Solarflare Communications Date: Wed, 07 Sep 2011 00:48:56 +0100 Message-ID: <1315352936.12033.1.camel@bwh-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) X-OriginalArrivalTime: 06 Sep 2011 23:48:59.0383 (UTC) FILETIME=[8C4E5870:01CC6CEF] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18368.004 X-TM-AS-Result: No--0.680000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org The location of an RX flow classification rule is needed to identify it for retrieval, replacement or deletion. However it also defines the priority of the rule in the case that a flow is matched by multiple rules. This is what I intended to imply by referring to the use of a TCAM, commonly used to implement that behaviour. However there are other ways this can be done, and it is better to specify this explicitly. Further, I want to add the option for automatic selection of rule locations. Signed-off-by: Ben Hutchings --- I hope we're all in agreement that this is how locations are supposed to be numbered. Ben. include/linux/ethtool.h | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h index dffab51..58407e3 100644 --- a/include/linux/ethtool.h +++ b/include/linux/ethtool.h @@ -456,7 +456,9 @@ struct ethtool_flow_ext { * includes the %FLOW_EXT flag. * @ring_cookie: RX ring/queue index to deliver to, or %RX_CLS_FLOW_DISC * if packets should be discarded - * @location: Location of rule in the table + * @location: Location of rule in the table. Locations must be + * numbered such that a flow matching multiple rules will be + * classified according to the first (lowest numbered) rule. */ struct ethtool_rx_flow_spec { __u32 flow_type; @@ -502,9 +504,6 @@ struct ethtool_rx_flow_spec { * * For %ETHTOOL_SRXCLSRLDEL, @fs.@location specifies the location of an * existing rule on entry. - * - * Implementation of indexed classification rules generally requires a - * TCAM. */ struct ethtool_rxnfc { __u32 cmd;