At least, that’s what I thought.  Then I started having people react to our solution and tell me how ‘nice’ it is we actually did something as simple as NIC Teaming.  So I wanted to list out the functionality we offer on our 10Gb NIC part of the solution.

If you look at the traditional NIC function that has been in any server platform now for almost ten years there are a list of basic features you expect to have to ‘just work’  they can include:

• NIC Teaming
• VLAN Support
• Wake on LAN Support
• Serial over LAN support (IBM BladeCenter Feature)
• Software iSCSI Initiator and iSCSI Software Boot Support
• Preboot Execution Envrionment (PXE) support

The OneConnect platform, whether it be mezzanine card or PCIe based, offers this functionality on its NIC ports, whether physical or virtual, out of the box. In addition to that functionality, where we go above and beyond is at the hardware layer we also provide TCP Offload Engine support.   With all of these technologies enabled we can still drive over 3.6m packets per second in an ethernet environment.

Moving forward with an entitlement you can easily turn on FCoE or iSCSI HBA support within the adapter as well.  The upgrade process is a simple flash update that can be applied remotely or locally on the systems using our OneCommand tools.

It appears that the appropriate sacrifices were made to the gods of computer shows and our demonstration of the eVFA adapter on the IBM BladeCenter at Storage Networking World: Europe.

Unfortunately, due to my need to be in the States to help finish up our final testing before general availability, I was unable to attend in person. Instead, I helped walk the team over the phone through enabling the adapter & getting VMware up and running.

I’ve been following vicariously through people that have gotten updates and posted their thoughts. One author, Nigel Poulton, was lucky enough to gain some nice pictures of the HS22 with the eVFA card installed in his write-up, and he touches on something I wanted to expand on a little bit in this quote:

NOTE: Of particular interest to me was the fact that the core features, as well as the base cost, of this adapter are 10Gbps Ethernet. This is very interesting when you consider Emulex are traditionally a Fibre Channel company. Clearly Emulex are moving with the market here and recognising Ethernet as the dominant technology and building on that. Emulex also have people on IEEE 802.1 committees such as DCB. Now that’s what I call not betting against Ethernet.

I love it when a plan comes together and people ‘get’ it. This has been something I’ve been trying to communicate to the technical community within IBM since I’ve come on board.

As with most new product announcements, some details take time to permeate in the industry before they are fully understood. There will be questions, and change can take quite some time (See: It is not an Inflection Point…it is an Inflection Process).

I was around and working in datacenters when Fibre Channel hit the world back in the late 90s. While we don’t have the problem now of ‘it’s expensive’ we do have the concerns of how will I manage? Will it do everything I need? and lots of other questions that aren’t completely answered yet. I’ve traded comments on Twitter with Cisco’s Brad Hedlund about how I think Multi-Hop CEE/DCE is that last step and how multiple FCFs (Fibre Channel Forwarders) are my two ‘must have’ features. What I mean by that is if you look at this white paper from Cisco you will notice that they have two separate and redundant networks. The reason for that is right now you can only have one device in your FCoE network that forwards traffic to FCoE. Now, granted, it’ll take a large network to require more than one FCF today but if you look at some SAN infrastructures that are out there they would necessitate multiple isolated networks to completely rip & replace their FC infrastructure.

I’ve also had a bit of time to bounce some comments to Dell’s Jeff Sullivan over a blog post that came out comparing FCoE to iSCSI. After some clarification from the authors, I see where they are headed, but I do think the idea is fundamentally flawed in that FC in some way had to be forced into the OSI model and that because of that there might be some concerns. I do agree iSCSI is more mature than FCoE and probably why they are seeing success with it. But you also have a complete end to end solution maturity here. FCoE while has had some successes with announcements around products in the adapter, switch, and storage parts of the market it’s not nearly as ubiquitous as FC and iSCSI are. Slight plug here, but my OneConnect OCe10102-I card is the only adapter that is hardware offload is the only uCNA that does that, and extremely well I might add.

That post is a must read too, it has some great points though about the state of the FCoE space. The ‘all’ part isn’t there 100%. Which is why a move to 10Gb now for data traffic, and migrate to FCoE for storage traffic is actually resonating so well with a lot of our customers. I’m aware of large opportunities that are buying both an FC card and the eVFA card already in the pipeline. So while going entirely to FCoE does work for some, there are a lot of more conservative companies that will put the stuff in place for a migration, but aren’t ready for it today.

So those are my thoughts for the month of October. Now that things are wrapping up and the eVFA card is becoming readily available in a short amount of time. I’m will continue my planned discussion about the eVFA in future posts.

vNIC is a feature of the adapter to present multiple adapters to the operating system through the PCI Function ID of the adapter.   When an operating system scans the adapter and the vNIC function is enabled through the UEFI BIOS (which is on by default) the operating system will see up to eight PCI function IDs with eight unique MAC addresses.   The PCI Functions are numbered 0 – 7 and are always enumerated with functions 0,2,4,6 being assigned to Port 0 as VNIC 1 – 4, and then 1,3,5,7 being assigned to Port 1 as VNIC 1-4.

In the initial launch, you will have some basic configuration options at the card level. However, primarily you will be configuring your vNIC solution from the switch as the switch controls the virtual groups and the bandwidth assigned to each virtual NIC.   The switch in this solution is provided to IBM by Blade Network Technologies.   It’s their BNT 10-Port 10Gb Ethernet Switch Module.  They have some detailed information similar to our pages on the IBM BladeCenter Virtual Fabric solution along with a solution brief.

The BNT switch also provides 1Gb or 10Gb connections just like the eVFA adapter does.   Giving you the ability to start with 1Gb network and grow into 10Gb.   You could easily provide 10Gb of bandwidth to the blades and between your IBM BladeCenters and still connect to the corporate network at 1Gb.

We will be working on a IBM Redbook that will be available when the solution ships later in October.  If you have any scenarios you’d like to see discussed in the RedBook feel free to give me some ideas either here or you can e-mail me as always.

I wanted to start at the easy side, and work my way into the more complex features.   So the easiest side of this is that at it’s core, the eVFA (my short name for this) is the base function of the adapter.  At it’s core, this adapter is a two port 10Gb Ethernet adapter with full offload functionality.   So let’s take a look at that function first.

As we’ve previously announced back in May, Emulex chose to partner with ServerEngines to deliver converged networking solutions.   This is the first adapter to come out of that partnerships.   The ASIC used is Emulex’s ‘Tigershark’. 

The core features of this NIC is that it is a PCI Gen2 interface, and a dual port 10Gb ethernet out of the ASIC.   The adapter also has the NCSI support for WoL an SoL so you can provide full services via this adapter for those protocols as well.  Some key things to keep in mind is that this is a PCI Gen2 device and to get the full bandwidth out of it you do need a PCI Gen2 aware blade.  Currently that is IBM’s BladeCenter HS22.   At launch this will be the only server supported however since Gen2 is backwards compatible with Gen1 in theory it would work, albeit not at full performance capability due to the bandwidth limitations of the Gen1 slot in older blades.

As a standard NIC the eVFA adapter has full TOE offload.   This is mostly exploited using the Windows Chimney Stack AKA The MS Windows 2003 Scalable Networking Pack or a default feature of Windows 2008.   These allow the adapter to do most of the heavy lifting of packetizing and de-packetizing the data.   The end result is lower CPU utilization & PCI Bus traffic for network traffic.   This is especially helpful for heavy network traffic solutions.  Details of how it’s enabled on Windows 2003/2008 can be found here.  It is enabled by default on Windows 2008 Server R2.  If you’re using Linux it’s currently not a supported option.   We have no plans to bring anything custom out for linux so as long as TOE is viewed as non-viable by the kernel developers we will not offer any support for it.  Because of that, the idea of TOE enabled adapters is not that exciting for linux servers.  VMware is schedule to bring Asynchronous support for 10Gb iSCSI offloads about the time the iSCSI software key will be available so we should line up nicely for that functionality.

IBM today announced the Emulex Virtual Fabric Adapter for IBM BladeCenter. This adapter in conjunction with the Blade Network Technologies 10-port 10G Ethernet Switch Module introduces IBM BladeCenter’s new Virtual Fabric Architecture. The eVFA Adapter is based on Emulex’s OneConnect family of Universal Converged Network Adapters (uCNA)

With the introduction of these products, IBM enters the Virtual NIC environment. Based on ethernet standards that are available the new eVFA adapter provides the ability to take a standard dual port multi-protocol adapter and carve it into up to eight independent networking adapters.

This is regardless of the operating system on top of it, and is in no way tied to any virtualization software. You can use this technology on Microsoft Windows Server, Red Hat Enterprise Linux, SUSE Enterprise Linux, and VMware. So any high I/O environment you have can benefit from this solution allowing you to bring to bear enough I/O to keep Intel’s Xeon 5500 based BladeCenter HS22.

Next week at VMworld 2009 I, along with a few others, will be demonstrating this technology in the IBM Booth. So if you are able to attend VMworld I highly recommend you stop by. We will be demonstrating one of VMware’s best practice designs for a VMotion based solution using the eVFA adapter.

This is just the first step in convergence. As I’ve rambled on about before 10Gb is the base to the converged network, and building on that moving forward is the goal. The eVFA Adapter will have licensed upgrades to enable either iSCSI or FCoE protocols as well due in the first half of 2010. It will be a software download that you apply to the adapter, so there will be no need to replace any hardware if you are migrating to FCoE or iSCSI based technologies.

In conjunction with a software license for the BNT 10-Port switch you will be able to seamlessly migrate into the world of FCoE when you are ready.

However if you don’t plan on doing that any time soon, you can always add the Emulex LPe1205V-CIOV adapter for two 8Gb ports of ‘regular old’ Fibre Channel, giving you eight ethernet, and two fibre channel ports per HS22.

My goal over the next few weeks is to highlight the various components of this solution and do a bit of a ‘deep dive’ in the technology behind them to provide some education to those of you who like to play along at home.

Since my first post introducing my thoughts on where we stood with FCoE and it’s now been three months and there has been some ratification activity and there has been a few more independent bloggers out there that have begun to tear into the world of FCoE.

I’ve seen some good information on no multi-hop FCoE capabilities (yet) limiting FCoE to the edge of your SAN network. This of course will change with time but it’s an important limitation to notice for those of you hearing of how FCoE is out to solve world hunger now that it’s ‘ratified’.

We also have Howard Marks talking about how FCoE Ain’t There Yet as well. He points out the Gartner term “Peak of Inflated Expectations” which I jokingly refer to ‘solving world hunger’ when I talk about FCoE. He drags out some of the past ‘solve world hunger’ products such as ATM. For those of you who didn’t play along at home when ATM was coming out it was going to replace everything from Token Ring and Ethernet in your LAN, get rid of frame relay WANs, and eliminate the PSTN phone network. Since we have those technologies still you can see how well that worked out.

Another thing to keep in mind is from an OS perspective FCoE adapters are extremely new, and might be difficult to get working compared to what you are used too. I’d also expect a lot of updates to the driver & firmware depending on how the adapter is designed.

My personal belief on where this is going to go is probably a bit different than the rest of the world. I really think that the 10Gb ethernet side of the equation is the big push.

WIth HP’s Flex 10 technology introducing the concept of carving up a 10Gb pipe I think it’s a great start but at the same time it’s a bit monolithic in that it only talks about using an Ethernet pipe as a bunch of small pipes. What really interests me is the idea of taking a 10Gb link and multi-protocl stacking it with FCoE, or iSCSI, as well as standard TCP/IP data traffic. Until adapters can do that easily and the switches they work with handle this seamlessly as well I don’t think one new protocol is going to make a huge impact in the larger data centers.

In my last post I talked about this new word everyone is tossing about the new buzz word ‘convergence’ and how I noticed that it wasn’t very converge-y (is that a word?) of them to announce a new adapter, and then only talk about one of the features that would be needed to truly ‘converge’ an adapter.

Imagine my ‘oh no they didn’t’ reaction when indeed, they announced YET ANOTHER 10Gb Ethernet Card. They even go so far to toss in a quote from someone with SAN in their name in the press release and they group the ethernet card under their ‘converged networking‘ banner on their product page but the only thing converge-y about it is that it has an ethernet port and can go in a server right next to their FCoE adapter.

Oh, and until April 30th, that chip had a Netxen brand on it. So now, I’d imagine it’s not the same device driver stack as the ethernet port on their FCoE adapter.

So there you now have two cards that ‘converge’ your network. Each with a specific function and absolutely no convergence whatsoever. So if you want 10Gb Networking & FCoE you get two adapters. Just like before. Looking at the definition of the verb convergence you get: ” (of a number of things) gradually change so as to become similar or develop something in common” or “come together from different directions so as eventually to meet”. I guess our competitor will get there eventually, but the market isn’t going to wait forever. They want a solid convergence point, and soon.

On another note, I’m going to do a couple plugs because we’re giving away some things on our website.

The first is if you download Emulex’s Converginomics Guide guide you get a chance to win a free Kindle 2. For you technical guys just download it quick and skim it. It’s fairly high level but hey a chance to win a Kindle 2 is always worth downloading a PDF file.

Also on the IBM Microsite we’re giving away a free iPod Touch via a random drawing if you answer a quick survey.