From owner-freebsd-net@FreeBSD.ORG Thu Sep 8 17:27:43 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F23E4106564A; Thu, 8 Sep 2011 17:27:42 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id CB9648FC0C; Thu, 8 Sep 2011 17:27:42 +0000 (UTC) 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); Thu, 8 Sep 2011 10:27:42 -0700 From: Ben Hutchings To: "K. Macy" In-Reply-To: References: <201109080834.11607.jhb@freebsd.org> <201109081106.40714.jhb@freebsd.org> <1315498877.2804.10.camel@bwh-desktop> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Thu, 08 Sep 2011 18:27:39 +0100 Message-ID: <1315502859.2804.14.camel@bwh-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Sep 2011 17:27:42.0357 (UTC) FILETIME=[9D5CB450:01CC6E4C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18372.005 X-TM-AS-Result: No--18.630900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: Takuya ASADA , freebsd-net@freebsd.org, jfv@freebsd.org, John Baldwin , Navdeep Parhar Subject: Re: Adding Flow Director sysctls to ixgbe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 17:27:43 -0000 On Thu, 2011-09-08 at 18:28 +0200, K. Macy wrote: > > Whatever the mechanism is, the interface should allow for: > > > > - Flexible matching on layer 2, 3 and 4 header fields > > - Masking out some bits before matching (e.g. ignoring priority bits of > > VLAN tag or least significant bits of IPv4 address) > > - Priority of rules in case several match a single flow. This may > > need to be combined with location, since in a TCAM location may > > determine priority. > > - Requesting packets to be dropped, steered to a single RX queue, or > > steered to a range of RX queues (using a flow hash and indirection > > table) > > - Use of multiple hash indirection tables > > Do you feel that the Linux API for this is the right place to start > looking? You can certainly learn from the mistakes made in Linux. :-) > Earlier you said: "The exact capabilities of the hardware > are all quite > different and we're still recovering from the early mistake of > defining two subtly different interfaces." Have the two APIs been > unified, if not which one do you believe is the "right" one? RX NFC is the right one. The other one (RX n-tuple) will be removed once I've converted the sfc driver to use RX NFC. It isn't flexible enough to cover the full matching capabilities and it doesn't allow for requesting steering + hashing, although I'm hoping to extend it to cover that later. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked.