Date: Thu, 3 Jul 2014 10:35:55 +0100 From: Nikolay Denev <ndenev@gmail.com> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: Kevin Oberman <rkoberman@gmail.com>, Sreenivasa Honnur <shonnur@chelsio.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: FreeBSD iscsi target Message-ID: <CA%2BP_MZEJ=Gj4%2B8tKdZHAObjw-_riGLYLFOeiUXj9vn=JkwShmQ@mail.gmail.com> In-Reply-To: <20140703091321.GP5102@zxy.spb.ru> References: <CAPjTQNEsQGDHdApx0-=h63QN4o=zXKen0Y_6Ehj9_isfgac9tw@mail.gmail.com> <F2BBBB6E0068844991318A316F34795C390447@nice.asicdesigners.com> <20140701091252.GB3443@brick> <20140701231305.GA37246@zxy.spb.ru> <CAN6yY1t2qDzfeO37p2s_3=vzEVv5C813M0ttqjnM4tJGkkBhyA@mail.gmail.com> <20140702112609.GA85758@zxy.spb.ru> <CAN6yY1uzfjoDfEdti91Ogy11LzT3-5JvLREBdW6ynEOgm0uUPA@mail.gmail.com> <20140702203603.GO5102@zxy.spb.ru> <CAN6yY1von-Z586V=8qs3%2BOfV3oXes380s2GD-149EYWLxws-qA@mail.gmail.com> <CA%2BP_MZE013dv22Sb-rk7ZoiYbCTodmth0d-XpdM6mrpw3WxQmg@mail.gmail.com> <20140703091321.GP5102@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 3, 2014 at 10:13 AM, Slawa Olhovchenkov <slw@zxy.spb.ru> wrote: > On Thu, Jul 03, 2014 at 09:31:45AM +0100, Nikolay Denev wrote: > >> On Thu, Jul 3, 2014 at 12:06 AM, Kevin Oberman <rkoberman@gmail.com> wrote: >> > On Wed, Jul 2, 2014 at 1:36 PM, Slawa Olhovchenkov <slw@zxy.spb.ru> wrote: >> > >> >> On Wed, Jul 02, 2014 at 12:51:59PM -0700, Kevin Oberman wrote: >> >> >> >> > On Wed, Jul 2, 2014 at 4:26 AM, Slawa Olhovchenkov <slw@zxy.spb.ru> >> >> wrote: >> >> > >> >> > > On Tue, Jul 01, 2014 at 10:43:08PM -0700, Kevin Oberman wrote: >> >> > > >> >> > > > On Tue, Jul 1, 2014 at 4:13 PM, Slawa Olhovchenkov <slw@zxy.spb.ru> >> >> > > wrote: >> >> > > > >> >> > > > > On Tue, Jul 01, 2014 at 11:12:52AM +0200, Edward Tomasz Napierala >> >> > > wrote: >> >> > > > > >> >> > > > > > Hi. I've replied in private, but just for the record: >> >> > > > > > >> >> > > > > > On 0627T0927, Sreenivasa Honnur wrote: >> >> > > > > > > Does freebsd iscsi target supports: >> >> > > > > > > 1. ACL (access control lists) >> >> > > > > > >> >> > > > > > In 10-STABLE there is a way to control access based on initiator >> >> > > > > > name and IP address. >> >> > > > > > >> >> > > > > > > 2. iSNS >> >> > > > > > >> >> > > > > > No; it's one of the iSCSI features that seem to only be used >> >> > > > > > for marketing purposes :-) >> >> > > > > > >> >> > > > > > > 3. Multiple connections per session >> >> > > > > > >> >> > > > > > No; see above. >> >> > > > > >> >> > > > > I think this is help for 40G links. >> >> > > > > >> >> > > > >> >> > > > I assume that you are looking at transfer of large amounts of data >> >> over >> >> > > 40G >> >> > > > links. Assuming that tis is the case, yes, multiple connections per >> >> > > session >> >> > > >> >> > > Yes, this case. As I know, single transfer over 40G link limited by >> >> > > 10G. >> >> > > >> >> > ??? No, not at all. Getting 40G performance over TCP is not easy, but >> >> there >> >> > is no 10G limitation. >> >> >> >> As I know (may be wrong) 40G is bundled 4x10G link. >> >> For prevent packet reordering (when run over diferrent link) all >> >> packets from one sessoin must be routed to same link. >> >> Same issuse for Etherchannel. >> >> >> > >> > No, 40G Ethernet is single channel from the interface perspective.. What >> > my be confusing you is that they may use "lanes" which, for 40G, are >> > 10.3125G. But, unlike the case with Etherchannel, these lanes are "hidden" >> > from the MAC. The interface deals with a single stream and parcels it out >> > over the 10G (or 25G) lanes. All 100G optical links use multiple lanes >> > (4x25G or 10x10G), but 40G my use either a single 40G lane for distances of >> > up to 2km or 4x10G for longer runs. >> > >> > Since, in most cases, 40G is used within a data center or to connect to >> > wave gear for DWDM transmission over very long distances, most runs are >> > under 2km, so a single 40G lane may be used. When 4 lanes are used, a >> > ribbon cable is required to assure that all optical or copper paths are >> > exactly the same length. Since the PMD is designed to know about and use >> > these lanes for a single channel, the issue of packet re-ordering is not >> > present and the protocol layers above the physical are unaware of how many >> > lanes are used. >> > >> > Wikipedia has a fairly good discussion under the unfortunate title of 100 >> > Gigabit Ethernet <https://en.wikipedia.org/wiki/100_Gigabit_Ethernet>. >> > Regardless of the title, the article covers both 40 and 100 Gigabit >> > specifications as both were specified on the same standard, 802.3ba. >> > >> > -- >> > R. Kevin Oberman, Network Engineer, Retired >> > E-mail: rkoberman@gmail.com >> > _______________________________________________ >> > freebsd-current@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> >> I found this white paper useful in understanding how this works : >> http://www.cisco.com/c/en/us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-726674.pdf > > In real world "Reality is quite different than it actually is". > http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-696669.html > > See "Packet Path Theory of Operation. Ingress Mode". > Interesting, however this seems like implementation specific detail, and not limitation of native 40Gbit ethernet. Still, it's something that one must be aware of (esp when dealing with Cisco gear :) ) I wonder why they are not doing something like this : http://blog.ipspace.net/2011/04/brocade-vcs-fabric-has-almost-perfect.html --Nikolay
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BP_MZEJ=Gj4%2B8tKdZHAObjw-_riGLYLFOeiUXj9vn=JkwShmQ>