3COM 3C990 NIC

Is anyone maintaining the 3C990 driver? I'm using the code from 3COM and it doesn't look like it's been kept up to date with the various kernel changes. I'm also using the latest Red Hat kernel in case it matters.

When compiling with SMP support, I'm getting the following errors during a depmod -ae

depmod: *** Unresolved symbols in /lib/modules/2.4.18-17.8.0smp/kernel/drivers/net/3c990.o

depmod:         pci_write_config_byte
depmod:         eth_type_trans
depmod:         __wake_up
depmod:         __kfree_skb
depmod:         alloc_skb
depmod:         init_etherdev
depmod:         kmalloc
depmod:         pci_free_consistent
depmod:         pci_find_class
depmod:         pci_read_config_byte
depmod:         cpu_raise_softirq
depmod:         free_irq
depmod:         unregister_netdev
depmod:         __out_of_line_bug
depmod:         iounmap
depmod:         pci_alloc_consistent
depmod:         interruptible_sleep_on_timeout
depmod:         __ioremap
depmod:         pci_read_config_word
depmod:         kfree
depmod:         request_irq
depmod:         netif_rx
depmod:         skb_over_panic
depmod:         jiffies
depmod:         softnet_data
depmod:         printk
depmod:         __const_udelay

I get no problems in the single processor compile & depmod. Can these be safely ignored? The SMP #define simply includes the spinlock stuff.

#ifdef SMP
#include <linux/spinlock.h>
#endif

Homepage: http://interclypse.net
Registered Linux user #215241 (http://counter.li.org/)

I have a completely reworked version that I expect to be able to release RSN. (I know, I know, some of you have heard that before... it just takes time to get people around here to sign off on these things. :/)

It will support zero-copy TCP, TCP segmentation offload, and when DaveM's IPSEC is in, I'll be able to do hardware offload for that as well.

D

Cool :)

Will you be submitting this for inclusion in the kernel?

And, what differences exists between the 3c59x and 3c90x hardware, and 3c990? Just IPSEC?

JEff

Yes, I plan to run it by you first, and then once it is in shape, have it included. 3Com has agreed to release their firmware binary under a BSD license so that we can include it. (No source code, unfortunately.)

Not really sure, ethernet hardware wise -- the driver communicates with an onboard ARM chip, which we have to load firmware for. We then communicate with it via several rings for commands, Tx packets, Rx packets, etc. There is an onboard random number generator and crypto chip. We never drive the real hardware directly, just talk to the firmware, which still has a few issues that I am working with 3Com to resolve.

The nice thing about the firmware setup is that we don't really care which card in the 3c990 family we're talking to per se -- they can change the hardware all they want, and the driver should just work as long as we have recent firmware. I currently support every version I know about:
3C990-{TX,SVR,B,M}-{,95,97}.

To set a date for this current vaporware -- I expect to have it to before the end of November, and potentially much sooner. We have a conference just after Thanksgiving, and our sponsors are itching to be able to say to those attending that we've published this.

Dave

I'd be interested in testing it if you are looking for feedback.

--Chris

Homepage: http://interclypse.net
Registered Linux user #215241 (http://counter.li.org/)

Please tell me what the interface is to offload IPSEC transformations to the card. What information does the card need to properly transform the packet and what transforms are supported?

Currently there are no plans for an offload strategy, because we lack knowledge in the area of exactly what cards provide.

The card was designed with NDIS 5.0 task offloading in mind. The documents for that (in the NT DDK) will give you an overview of where they're going; I'll try to provide more detail here.

The cards support varying levels of encryption, depending on the model. Some support no encryption, some only DES, and some Triple DES. We can query the card to determine what it supports. Those cards that support DES or 3DES support the MD5 and SHA1 hashes.

The cards support IPSEC packets in the following modes:
1. [IP1][AH][payload]
2. [IP1][ESP][payload]
3. [IP1][AH][ESP][payload]
4. [IP2][AH][IP1][payload]
5. [IP2][AH][IP1][payload]
6. [IP2][AH][ESP][payload]

where payload can be any type of data, including more nested levels of IPSEC, as long as they have been encrpyted/hashed by the host.

There may be other modes supported; the documentation I have for the cards is inconsistent in some places, and flat out wrong in others. Experimentation is needed to be sure of what is supported beyond the above.

Only IPv4 is supported at this time, IPv6 is not supported (maybe in a later firmware). IP options are supported, while fragments are not. They will be passed through without processing. The adapter can do scatter gather, checksumming, TSO, VLAN insertion, and IPSEC on the same packet.

The IPSEC engine must register a Security Association with the card before we can offload the crypto. While NDIS supports a fair number of selectors for SA's, the Typhoon cards only key off of the destination address and SPI for inbound packets. For Tx processing, an opaque handle must be passed to the adapter identifying the SA to be used to process the packet.

Once again, future releases of the firmware may be able to do more for us, but I wouldn't count on it, nor would it necessarily be desirable.

On Tx, we must add space for the AH and/or ESP headers and any needed padding, and fill in the SPI and Next Header fields. For ESP, the adapter will fill in the IV from its hardware random number generator (this feature may be selectable.)

To register an SA, we need to provide the adapter with the protocol (NULL, AH, or ESP), the hash type (MD5 or SHA1), the direction for this SA (Tx or Rx), the encryption type (None, DES, 2 key 3DES, 3 key 3DES, ECB or CBC), the SPI, the dest address and mask, and the keying material. The card will give us a 16 bit handle. If we are to nest as in mode 3 or 6 above, we pass in both SA's to the driver, which will return a 32 bit handle. The handle will be zero if a problem occurs. We can query the maximum number of SA's supported. To delete an SA, we give the card the handle it gave us. For Tx, we must pass the handle in as part of the Tx descriptor.

On Rx, the card will lookup the destination/mask and SPI in its tables, and if it finds an SA for the packet, will attempt to decrypt it and verify the hash. It will put the results of this processing in the Rx descriptor it passes to the host.

Hopefully, the above will help. The NDIS docs have been pretty useful as well.

Dave