From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland Dreier Subject: Re: Question regarding protocol specific mtu for FCoE Date: Wed, 03 Jun 2009 16:27:25 -0700 Message-ID: References: <7C88852EF6F99F4EB538472FCFEBE2223A7E6F45@orsmsx509.amr.corp.intel.com> <4A26BAF7.3070301@hp.com> <7C88852EF6F99F4EB538472FCFEBE2223A7E6FBD@orsmsx509.amr.corp.intel.com> <4A26E4AE.4020607@hp.com> <4A26FB01.1020502@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from sj-iport-6.cisco.com ([171.71.176.117]:2116 "EHLO sj-iport-6.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752949AbZFCX1Y (ORCPT ); Wed, 3 Jun 2009 19:27:24 -0400 In-Reply-To: <4A26FB01.1020502@hp.com> (Rick Jones's message of "Wed, 03 Jun 2009 15:36:49 -0700") Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: Rick Jones Cc: "Zou, Yi" , "netdev@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "Leech, Christopher" , "Dev, Vasu" , "Love, Robert W" , "Ma, Steve" , "Waskiewicz Jr, Peter P" , "Kirsher, Jeffrey T" > Aren't all stations in the same broadcast domain "supposed" to have > the same MTU, at least down at L2? So, a station in the broadcast > domain just doing IP and a station in the broadcast domain doing > IP+FCoE "should" have the same MTU at the HW level right? > > I could see where there would be lots of PMTU going-on if the > communications were to off-campus sites also had an FCoE upping their > MTU. Otherwise, the MSS exchange at connection establishment is going > to preclude it right? PMTU only "hits" when one has a so called > "dumb-bell" network which is "wider" at the ends than in the middle. Yes, I think such dumb-bell networks would be pretty common (servers in two different data centers with FCoE enabled, talking through an old-school WAN with 1500 MTU). And even if they're not as common I think, we probably do want to have some way to handle this. I'm probably not as up on old and/or obscure networking protocols, but to me FCoE is the first time I've been forced to think about coexistence of IP and non-IP protocols through the same netdev. - R.