3COM 3C990 NIC

3COM 3C990 NIC

[Christopher Keller]

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/)

Re: 3COM 3C990 NIC

[David Dillow]

Christopher Keller wrote:
> 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.

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

Re: 3COM 3C990 NIC

[Jeff Garzik]

David Dillow wrote:
> 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.

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

Re: 3COM 3C990 NIC

[David Dillow]

Jeff Garzik wrote:
> 
> David Dillow wrote:
> > 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. :/)

> Will you be submitting this for inclusion in the kernel?

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.)

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

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

Re: 3COM 3C990 NIC

[Christopher Keller]

[-- Attachment #1: Type: text/plain, Size: 611 bytes --]

On Mon, 2002-10-21 at 21:54, David Dillow wrote:

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

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/)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 3COM 3C990 NIC

[David S. Miller]

On Mon, 2002-10-21 at 21:54, David Dillow wrote:
> 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.

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.

Re: 3COM 3C990 NIC

[David Dillow]

"David S. Miller" wrote:
> 
> On Mon, 2002-10-21 at 21:54, David Dillow wrote:
> > 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.
> 
> 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?

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.

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

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

Dave