lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A26E4AE.4020607@hp.com>
Date:	Wed, 03 Jun 2009 14:01:34 -0700
From:	Rick Jones <rick.jones2@...com>
To:	"Zou, Yi" <yi.zou@...el.com>
CC:	"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

>> Do FCoE upper layers have anything analagous to a TCP_MAXSEG option? That
>> allows an application using TCP to ask for a smaller MSS than TCP might have
>>  chosen otherwise.
> 
> No, FCoE does not have that. The current kernel FCoE initiator initiates its
> max frame size based on the associated netdev->mtu, which normally is 1500.
> So, unless the LAN mtu is changed, FCoE stack is no able to use baby jumbo
> frame.

So FCoE cannot say "fcoe_mtu = min(OPTIMAL_FCOEMTU,netdev->mtu)" and send-down 
frames based on that?

>> Would a NIC over which FCoE was running be able to be of two minds of what 
>> the MTU happens to be?  I'd think that if one user of the NIC needed/wanted
>>  and MTU > foo one would just set the MTU large enough to include foo and be
>>  done with it?
> 
> For a nic that supports converged traffic, i.e. LAN + FCoE, I think
> it's safe to assume the nic has that capability. Setting LAN MTU large
> enough will work for FCoE, but it affects everyone using netdev->mtu, so
> you may see degraded LAN performance, which is certainly not good.

There have been some instances of increased MTU running causing applcations to 
run afoul of Nagle and what not, but I don't think it is a general truism that 
using a larger MTU degrades LAN performance.

Perhaps it is just me not getting out enough but I'm still having trouble coming 
to grips with the idea of a NIC that has two (or more) ideas of a valid frame 
size based on ethertype or whatnot.

At the risk of another of my "Emily Litella" moments, it sounds like the NIC HW 
will have to be set to use an MTU that is the max of the desired IP and FCoE MTUs 
and so you are not really talking about adding one MTU concept but two so you have:

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

rick jones
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ