Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934319AbXINQSq (ORCPT ); Fri, 14 Sep 2007 12:18:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1763732AbXINQSQ (ORCPT ); Fri, 14 Sep 2007 12:18:16 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72]:6601 "EHLO sj-iport-3.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1764614AbXINQSO (ORCPT ); Fri, 14 Sep 2007 12:18:14 -0400 X-IronPort-AV: E=Sophos;i="4.20,256,1186383600"; d="scan'208";a="524068233" To: "Michael Chan" Cc: "Steve Wise" , "netdev" , linux-kernel@vger.kernel.org, general@lists.openfabrics.org, anilgv@broadcom.com, uri@broadcom.com Subject: Re: [ofa-general] InfiniBand/RDMA merge plans for 2.6.24 X-Message-Flag: Warning: May contain useful information References: <46E97BB0.9030106@opengridcomputing.com> <1189724358.9540.113.camel@dell> From: Roland Dreier Date: Fri, 14 Sep 2007 09:18:01 -0700 In-Reply-To: <1189724358.9540.113.camel@dell> (Michael Chan's message of "Thu, 13 Sep 2007 15:59:18 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.20 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 14 Sep 2007 16:18:01.0671 (UTC) FILETIME=[D2706570:01C7F6EA] 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 X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1784 Lines: 35 > > I've been meaning to track down the bnx2 iscsi offload patch to look > > and see if this issue is addressed, since the same problem seems to > > exist: it seems an iscsi connection and a main stack tcp connection > > might share the same 4-tuple unless something is done to avoid that > > happening. > iSCSI does not do passive listens, only active connections to the > target. But you're right, the port space is still shared between iSCSI > and the main stack. We currently rely on user apps binding to the main > stack to reserve certain ephemeral ports, and telling the iSCSI driver > which ports to use. Got it... I wasn't thinking that clearly, but it is clear that a full 4-tuple collision with only active connections is quite unlikely. I guess you would have to make both an offloaded and a non-offloaded iSCSI connection to the same target and get really unlucky with ephemeral port allocation. So in practice I guess it's not an issue at all with your driver yet. However, do you have any plans to support iSCSI offload for targets? Also, looking at the first CNIC patch, I can't help but notice that you seem to have at least some support for iWARP there. How does the CNIC look? Does it share the same interface/addresses as the non-offload NIC, or does it create a completely separate netdevice? I want to make sure that whatever solution we come up with for cxgb3 doesn't cause problems for you. And of course if you have a better idea than what Steve has come up with, that would be great :) - 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/