Skip navigation

     This article is out of date!!  Use this article instead:  http://communities.intel.com/community/wired/blog/2012/03/16/even-more-ecc-updates

 

     ECC, FCC, GCC, its all big soup of acronym, most of which you would think doesn't apply to networking.  Sure GCC compiles our drivers under Linux*, and FCC might someday monitor the interwebs more (but doesn't today), but ECC still stands out as the one that might not apply.

But it does.

     ECC has many real "definitions" error correcting circuits, error correcting code, or error correction code, but they all do the same thing.  It helps keep data intact within the chip memory.   ECC uses a special algorithm to encode information in a block of bits that contains sufficient detail to permit the recovery of a single bit error in the safeguarded data.  This protocol will not only detect single bit errors, but will transparently correct them on the fly.   Double errors will be flagged as an error and the device will try to get software’s attention about it.  Related to ECC is parity.  Parity will keep track of the quantity of bits in total and track them as either even or odd.  Should this parity change while it is the chip memory, it will be flagged as an error.  Since which bit went rogue you can't tell, this is a poor man's protection. Also if more than 1 bit changes parity check can miss it.  (Warning!  HTML Table!)

 

 

Product

Packet Buffer

(In band Traffic)

Managability

(out of band traffic)

82546

None

None

82571

ECC

Parity

82580 **new**

ECC

ECC

82575 and 82576

ECC

ECC

82598 and 82599

ECC

ECC

82573 /  82574 / 82583

None

None

82559 to 82551

None

None

 


     Both ECC and parity have a basic limitation in that if the error is large enough, it will look okay.  ECC is far more resistant to this.    We try to make sure bad things don't happen to your data, but it still might happen.  And while it will try to tell you when it does go bad, sometimes it still won't notice.  That's why Intel lawyers get edgy around articles like this.  Multiple bit errors are very rare, and probably will cause other problems to the machine.  Data integrity isn't made with a single point safety net.  If you want to guarantee your data, use a multiple layered approach since its unlikely that the all them will fail.

Big finish!
1)  ECC can help your undestand what happens to your data
2)  Our more recent products support it
3)  Thanks for reading the blog

Here at Wired Ethernet blog, we’ve covered FCoE a couple of times.   But FCoE isn’t just the adapter.  It’s an entire ecosystem, and today I have a couple of links that we use to help explain things when dealing with other ecosystem partners’ materials.  Now, we don’t recommend any equipment, and our linking to them does not constitute any sort of endorsement of the equipment or the site, and all the other disclaimer stuff that makes our lawyers worry.

 

A nice walkthrough of working with a Cisco Nexus* 5000 from an IT point of view.

 

Here is more from our buddies at the vendor.

 

Post in the comments your favorite links about FCoE switch setup.

dougb

How to: Basic EEPROM Checksums

Posted by dougb Oct 14, 2010

In our EEPROMs we try to keep an eye on the contents since it is read by hardware.  At the same time, we don't want to increase initialization time too much so our scheme needed to balance protection with speed.  Basically we just sum together the first 63 16-bit words, ignoring any carries, and then subtract that result from 0xBABA.  That value goes into word 0x3F in the EEPROM. When validating the checksum, the first 64 words are added together and if the result is 0xBABA, the checksum is declared good. Here’s how the checksum word value is calculated in C:

 

 

    u16 nvm_data;
    u16 checksum = 0;

    for (i = 0; i < 0x3F; i++) {
        ret_val = read_EEPROM_word( i, &nvm_data);
        checksum += nvm_data;
    }
    checksum = 0xBABA – checksum;

 

After writing the value in checksum to word 0x3F, we have a valid checksum for the EEPROM. In assembly it’s more complex, mostly because of it being in assembly.

        ;
        ; zero word index counter and accumulator
        ;
        xor     bx, bx
        xor     cx, cx
UEC_Loop:
        INVOKE  e1000_read_single_word, bx ; result in ax
        add     cx, ax             ; add result to accumulator
        inc     bx                 ; bump word index
        cmp     bx, 03Fh           ; are we done?
        jb      UEC_Loop           ; don't include the checksum word
        ;
        ; dropped out of loop - we've read first 63 words
        ;
        mov     bx, 0BABAh
        sub     bx, cx             ; proper checksum word value in bx

 

 

There are a couple of tricky parts when talking about this topic.  The first is, “Why 0xBABA?”  The second is, “What about 10-Gigabit EEPROMs?”

The first is easy to explain.  When the algorithm designers were working on it they needed a value that was not likely to appear in uninitialized EEPROMs.   Since it was to be in hex, the desire to make it "readable" was desired.    One of those engineers loves classic rock music, so he selected 0xBABA.   The second answer is a whole ’nother post!

Wrap up!

 

1)  Our EEPROM checksum scheme helps to keep our data intact by detecting unexpected content changes.

2)  It is a simple, time-tested scheme that doesn’t have too much overhead.

3)  Thanks for using Intel(R) Ethernet.

dougb

Linux Posting Rules

Posted by dougb Oct 6, 2010

The Wired Ethernet Linux* team produces and maintains a number of Linux kernel device drivers for wired Intel® Ethernet controllers and as well as a couple of drivers for other system level peripherals.  The drivers are the e100, e1000, e1000e, igb, ixgb, ixgbe, igbvf, ixgbevf, ioatdma and dca.  The Wired Ethernet team maintains these drivers in the upstream Linux kernel (kernel.org kernel).

The Wired Ethernet team also releases stand-alone versions of these drivers for business reasons.  We refer to these drivers as stand-alone or out-of-tree drivers.  There are customers who take and use these drivers instead of the upstream versions.  This is mostly because they need the latest hardware on an older kernel version.      This also allows Wired Ethernet to release drivers with fixes or new hardware and feature enablement independent of the upstream kernel release schedule.   These stand alone drivers are very popular and are released as source which can then be compiled and installed into a system.  The stand-alone drivers are released via our SourceForge* site, http://e1000.sourceforge.net as well as on http://support.intel.com. 

The Wired Ethernet Linux team is considered to be co-maintainers with the Linux kernel networking maintainer.  This means that we post or acknowledge changes to any of our drivers.  The Intel Wired Ethernet Linux team is highly involved with all aspects of driver changes in the upstream kernel.org kernel for the LAD supported drivers.  The team is also involved in network architecture discussions for new features and enhanced performance.  The team is also responsible for supporting bug reports which are filed against any of our drivers.   The reports come from a lot of different sources which include but are not limited to the netdev mail list, the e1000 SourceForge project, all of the Linux Operating System vendors and any of the Original Equipment Manufacturing companies.  In the Wired Ethernet organization there are technical marketing people who help sort through some of the bug reports but the Linux team is responsible for analyzing and fixing the bugs.

The team also takes fixes and driver changes from the Linux community if and when they make sense.  We relicense some code which means we need to retain sole copyright to prevent problems.  Here is how we deal with that.  Since the code is GPL code, anyone can change the code, but not all changes are relevant nor are they always complete.  So the Wired Ethernet Linux team again analyzes these requested changes, and if they are applicable they are then applied.  If changes are required to the patches, the updated patches are supplied for comment and then for inclusion if agreed upon.  There is an exception to this which applies to the HW specific files in our drivers.  This code is common code within all of Wired Ethernet drivers, and Intel maintains the sole copyright on these code components.  If changes are requested for this code, the changes are analyzed and an Intel supplied patch is supplied which address the issue at hand.   This allows these components to be used across a wide breadth for other drivers.  The original author is always accredited with the change but Intel has to be the only author of this code to retain the sole copyright on it.

The Wired Ethernet Linux release process can be a bit complicated to understand.  The basic principle is that not only does Wired Ethernet continually submit changes upstream, but we also release the stand-alone drivers which include the changes submitted.  This works by selecting a release date based on when new HW, either a device or NIC, is going to be released.  The team then works to generate a driver that contains all of the upstream patches as well as any of the new HW enabling code that will be pushed upstream when the HW releases.  This driver is then tested on both the new HW as well as a wide range of older HW.  The team has a large number of automated tests which are run against the driver in a test bed that contains a lot of different Wired Ethernet devices and NIC’s.  This mechanism gives us a period of time to test and stabilize the driver before we release it.  In addition, the patches that are sent upstream are tested to make sure that they don’t break anything.  The team also has some automation testing for this purpose as well.

There are three things that happen when we do a formal release of our drivers.  One, patches that are in this version of the driver that are not already upstream are prepared against the latest net-next tree.  These patches are tested and compile tested against the latest net-next tree.  Once that is done the patches are pushed upstream.  Two, at this time the stand-alone driver is pushed out to the Wired Ethernet SourceForge site, http://e1000.sourceforge.net .  Three, also at this time we inform the various Operating System Vendors that the release has happened, and if any of them are waiting on the code, they will then pick up the upstream patches for their various releases.

So the bottom line is that the Linux team in Wired Ethernet is fully engaged with the Linux community in every aspect of coding, testing and release of Wired Ethernet device drivers to the upstream kernel as well as to the various companies that depend on these device drivers.

(this post was a combo effort with John R from our Linux team)

Filter Blog