[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.WNT.4.64.0906031407190.5072@ppwaskie-MOBL2.amr.corp.intel.com>
Date: Wed, 3 Jun 2009 14:17:21 -0700 (Pacific Daylight Time)
From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To: Rick Jones <rick.jones2@...com>
cc: "Zou, Yi" <yi.zou@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"Leech, Christopher" <christopher.leech@...el.com>,
"Dev, Vasu" <vasu.dev@...el.com>,
"Love, Robert W" <robert.w.love@...el.com>,
"Ma, Steve" <steve.ma@...el.com>,
"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
Subject: Re: Question regarding protocol specific mtu for FCoE
> 1) the "HW MTU" used by the NIC and the guts of the driver
> 2) the legacy networking (eg IP etc) MTU passed up through the legacy path
> 3) the fcoe MTU passed up through the fcoe path
>
> where 1 is the max of 2,3
Whatever is decided to do is going to be targeted at ixgbe first. The
scenario you outlined here is exactly how ixgbe hardware works:
- Set HLREG0 to enable jumbo frames. This allows larger frames to be
accepted, but doesn't limit them to any minimum size.
- Set MHADD (for 82598) or MAXFRS (for 82599 - same register, new name) to
indicate what the absolute maximum frame size you will receive. Again,
doesn't limit the minimum size.
- The networking software can send any size up to MAXFRS (maximum frame
size) and the hardware will happily receive it and pass it up the stack.
Cheers,
-PJ Waskiewicz
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists