Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753938AbYHJFO0 (ORCPT ); Sun, 10 Aug 2008 01:14:26 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750915AbYHJFOO (ORCPT ); Sun, 10 Aug 2008 01:14:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]:42911 "EHLO sj-iport-6.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750869AbYHJFON (ORCPT ); Sun, 10 Aug 2008 01:14:13 -0400 X-IronPort-AV: E=Sophos;i="4.31,336,1215388800"; d="scan'208";a="138069739" From: Roland Dreier To: David Miller Cc: jgarzik@pobox.com, swise@opengridcomputing.com, divy@chelsio.com, kxie@chelsio.com, netdev@vger.kernel.org, open-iscsi@googlegroups.com, michaelc@cs.wisc.edu, daisyc@us.ibm.com, wenxiong@us.ibm.com, bhua@us.ibm.com, dm@chelsio.com, leedom@chelsio.com, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH 1/1] cxgb3i: cxgb3 iSCSI initiator References: <200808071145.03848.divy@chelsio.com> <489C8BEB.8060001@opengridcomputing.com> <489CC58D.4010606@pobox.com> <20080809.002840.167363463.davem@davemloft.net> X-Message-Flag: Warning: May contain useful information Date: Sat, 09 Aug 2008 22:14:11 -0700 In-Reply-To: <20080809.002840.167363463.davem@davemloft.net> (David Miller's message of "Sat, 09 Aug 2008 00:28:40 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 10 Aug 2008 05:14:11.0989 (UTC) FILETIME=[ECD47C50:01C8FAA7] Authentication-Results: sj-dkim-1; header.From=rdreier@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 956 Lines: 20 > Also, I find it ironic that the port abduction is being asked for in > order to be "compatible with existing tools" yet in fact this stuff > breaks everything. You can't netfilter this traffic, you can't apply > qdiscs to it, you can't execut TC actions on them, you can't do > segmentation offload on them, you can't look for the usual TCP MIB > statistics on the connection, etc. etc. etc. We already support offloads that break other features, eg large receive offload breaks forwarding. We deal with it. I'm sure if we thought about it we could come up with clean ways to fix some of the issues you raise, and just disable the offload if someone wanted to use a feature we can't support. - R. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/