Re: Request for review (HW checksum patches)

[Zach Brown]

> Right now, just the Alteon cards.  Support for the 3Com-XL can probably
> be added without too much trouble.  I don't see a driver for the 3Com-990
> though, and I can't find a reference to it on the 3Com website, is 
> this a new card?

Its fairly new, and the future of support for it under free OSes looks
grim.  

its basically got an arm core in it that does all the magic.  rumor has
it that there are lots of nasty nasty patents involved in the thing and
3com isn't too excited about giving out docs (or, even worse, are under
patent licensing agreements that forbid them from doing so).  I called
3com and asked to get a list of patents associated with the card but
all they gave me were the 3com ones on doing typical ethernet interface
stuff.. no magical driver interraction patents.

I'd love to get more conclusive information.  It looks like a fun
little toy.

in differnet news, the most recently released eepro100 linux driver from
intel shows how to do csum offloading and shows how they load microcode
to do interrupt mitigation and such.  one would hope that they could
now actually admit to the features and release docs, but.. :(

Its worth noting that vendors like syskonnect actually want to _help_
people write drivers.  they should be encouraged :)

-- 
 zach


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Request for review (HW checksum patches)

[Keith Stevenson]

On Sat, Mar 25, 2000 at 10:36:24PM -0600, Jonathan Lemon wrote:
> On Sat, Mar 25, 2000 at 09:25:33PM -0500, Keith Stevenson wrote:
> > 
> > Which card(s) do your patches support?  I have a 3Com 3CR990-TX (typhoon)
> > which does both TCP checksumming and 3DES (for IPSec).  I'd love to give
> > it a try.
> 
> Right now, just the Alteon cards.  Support for the 3Com-XL can probably
> be added without too much trouble.  I don't see a driver for the 3Com-990
> though, and I can't find a reference to it on the 3Com website, is 
> this a new card?

I'm not sure whether or not it is generally available yet.  I got it as part of
an early release preview program.  Needless to say, the only drivers that come
prepackaged with it are for Win2k.  I'll see if I can find anything which
resembles documentation in the stuff which came with the card.  (I highly
doubt that I will.)

Regards,
--Keith Stevenson--

-- 
Keith Stevenson
System Programmer - Data Center Services - University of Louisville
[EMAIL PROTECTED]
PGP key fingerprint =  4B 29 A8 95 A8 82 EA A2  29 CE 68 DE FC EE B6 A0


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Request for review (HW checksum patches)

[Jonathan Lemon]

On Sat, Mar 25, 2000 at 09:25:33PM -0500, Keith Stevenson wrote:
> On Sat, Mar 25, 2000 at 06:56:42PM -0600, Jonathan Lemon wrote:
> > 
> > The patches I have were designed to solve a single problem, just
> > checksum offloading.  There are enough bits left in the new flag field
> > that you could use for something else, I don't know enough about what
> > you'd want to do to say if it's enough for a general mechanism.
> 
> Which card(s) do your patches support?  I have a 3Com 3CR990-TX (typhoon)
> which does both TCP checksumming and 3DES (for IPSec).  I'd love to give
> it a try.

Right now, just the Alteon cards.  Support for the 3Com-XL can probably
be added without too much trouble.  I don't see a driver for the 3Com-990
though, and I can't find a reference to it on the 3Com website, is 
this a new card?
--
Jonathan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Request for review (HW checksum patches)

[Keith Stevenson]

On Sat, Mar 25, 2000 at 06:56:42PM -0600, Jonathan Lemon wrote:
> 
> The patches I have were designed to solve a single problem, just
> checksum offloading.  There are enough bits left in the new flag field
> that you could use for something else, I don't know enough about what
> you'd want to do to say if it's enough for a general mechanism.

Which card(s) do your patches support?  I have a 3Com 3CR990-TX (typhoon)
which does both TCP checksumming and 3DES (for IPSec).  I'd love to give
it a try.

Regards,
--Keith Stevenson--

-- 
Keith Stevenson
System Programmer - Data Center Services - University of Louisville
[EMAIL PROTECTED]
PGP key fingerprint =  4B 29 A8 95 A8 82 EA A2  29 CE 68 DE FC EE B6 A0


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Request for review (HW checksum patches)

[Jonathan Lemon]

In article [EMAIL PROTECTED]> you write:
>> From: Jonathan Lemon <[EMAIL PROTECTED]>
>> Date: Sat, 25 Mar 2000 13:35:53 -0600
>> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
>> Subject: Request for review (HW checksum patches)
>> X-Mailer: Mutt 1.0pre2i
>> Delivered-to: [EMAIL PROTECTED]
>> X-Loop: FreeBSD.org
>>
>>   I have a set of patches which allows offloading checksums to
>> NICs which support it (right now, only the Alteon based cards).
>> The patch is at <http://www.freebsd.org/~jlemon/csum.patch>.
>
>This prompts a question on a related issue: there seems to be an increase  
>in support of protocol operations on NICs (e.g., tickle/keep-alive support  
>while the system is sleeping; IPSec; ...).  Is there enough there to let us  
>build a general mechanism for communication between stack and driver for  
>this sort of thing (e.g., a "meta-data" slot in the packet header which  
>points to an mbuf, or other structure, that contains the details)?

The patches I have were designed to solve a single problem, just
checksum offloading.  There are enough bits left in the new flag field
that you could use for something else, I don't know enough about what
you'd want to do to say if it's enough for a general mechanism.
--
Jonathan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Request for review (HW checksum patches)

[Jonathan Lemon]

In article  you 
write:
>FWIW, Win2000 has a mechanism for dealing with what they call task
>offloading.  If you decide to attack the problem, an inexpensive device you
>can use for testing is the 3C905B; it does IP+TCP checksums.

Yes, unfortunately it doesn't handle fragments at all.  I looked
at the card specs when devising the interface, to make sure that 
the new interface will be able to handle various chips.  I haven't
changed the 3com driver though, as I didn't want to spend time 
trying to figure out what the chip actually does vs what the manual
says it does.
--
Jonathan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Request for review (HW checksum patches)

[Sam Leffler]

FWIW, Win2000 has a mechanism for dealing with what they call task
offloading.  If you decide to attack the problem, an inexpensive device you
can use for testing is the 3C905B; it does IP+TCP checksums.

Sam
- Original Message -
From: "Justin C. Walker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, March 25, 2000 12:49 PM
Subject: Re: Request for review (HW checksum patches)


> > From: Jonathan Lemon <[EMAIL PROTECTED]>
> > Date: Sat, 25 Mar 2000 13:35:53 -0600
> > To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> > Subject: Request for review (HW checksum patches)
> > X-Mailer: Mutt 1.0pre2i
> > Delivered-to: [EMAIL PROTECTED]
> > X-Loop: FreeBSD.org
> >
> >   I have a set of patches which allows offloading checksums to
> > NICs which support it (right now, only the Alteon based cards).
> > The patch is at <http://www.freebsd.org/~jlemon/csum.patch>.
>
> This prompts a question on a related issue: there seems to be an increase
> in support of protocol operations on NICs (e.g., tickle/keep-alive support
> while the system is sleeping; IPSec; ...).  Is there enough there to let
us
> build a general mechanism for communication between stack and driver for
> this sort of thing (e.g., a "meta-data" slot in the packet header which
> points to an mbuf, or other structure, that contains the details)?
>
> We're currently trying to deal with this in Mac OS X, and it'd be nice to
> avoid having multiple wheels of different size and shape in the same
source
> base.
>
> Regards,
>
> Justin
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Request for review (HW checksum patches)

[Justin C. Walker]

> From: Jonathan Lemon <[EMAIL PROTECTED]>
> Date: Sat, 25 Mar 2000 13:35:53 -0600
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Request for review (HW checksum patches)
> X-Mailer: Mutt 1.0pre2i
> Delivered-to: [EMAIL PROTECTED]
> X-Loop: FreeBSD.org
>
>   I have a set of patches which allows offloading checksums to
> NICs which support it (right now, only the Alteon based cards).
> The patch is at <http://www.freebsd.org/~jlemon/csum.patch>.

This prompts a question on a related issue: there seems to be an increase  
in support of protocol operations on NICs (e.g., tickle/keep-alive support  
while the system is sleeping; IPSec; ...).  Is there enough there to let us  
build a general mechanism for communication between stack and driver for  
this sort of thing (e.g., a "meta-data" slot in the packet header which  
points to an mbuf, or other structure, that contains the details)?

We're currently trying to deal with this in Mac OS X, and it'd be nice to  
avoid having multiple wheels of different size and shape in the same source  
base.

Regards,

Justin


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Request for review (HW checksum patches)

[Jonathan Lemon]

  I have a set of patches which allows offloading checksums to 
NICs which support it (right now, only the Alteon based cards).
The patch is at .  

Note that the alpha bits are currently untested.
--
Jonathan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message