netdev
[Top] [All Lists]

Re: 3c59x.c modified for time measurement / code included

To: Guilhem Tardy <guilhem_tardy@xxxxxxxxx>
Subject: Re: 3c59x.c modified for time measurement / code included
From: Donald Becker <becker@xxxxxxxxx>
Date: Wed, 19 Sep 2001 15:27:22 -0400 (EDT)
Cc: netdev@xxxxxxxxxxx, andrewm@xxxxxxxxxx, greearb@xxxxxxxxxxxxxxx
In-reply-to: <20010919132205.52080.qmail@web11501.mail.yahoo.com>
Sender: owner-netdev@xxxxxxxxxxx
On Wed, 19 Sep 2001, Guilhem Tardy wrote:

> Subject: 3c59x.c modified for time measurement / code included

I had previously guessed that you had selected the 3c905C for its
various features, including checksum and real-time support.  But you
don't seem to be using the special hardware at all.

> parts of the function boomerang_rx(struct net_device *dev) in 3c59x.c
....
>                       skb->protocol = eth_type_trans(skb, dev);
>                       {                                       /* Use hardware 
> checksum info. */
> /* ### avoid checksum on all packets ! */
> //                            int csum_bits = rx_status & 0xee000000;
> //                            if (csum_bits &&

Why did you comment this out?

I had previously guessed that you wanted to limit changes to just the
driver, and don't want to duplicate the software checksum code.  The
3c905B /3c905C has the easiest to use hardware TCP/IP checksum assist --
the hardware does all of the work for you.

Presumably you only want to accept uncorrupted packets, and you don't
want to protocol layers to subsequently reject the packets because of an
invalid checksum.  (Ignoring the issue of fragmented packets...)  The
best approach is to retain the checksum support, only annotate packets
that pass the chip's checksum, and continue to set CHECKSUM_UNNECESSARY
as before.

> /* ### add <driver rcv completed> time */
> if (*(skb->data + 9) == 17 && *(((unsigned int *) (skb->data+20)) + 1) ==
> htons(6969)) {

Acckkk!!  Don't you really want u16 ( u8/u16/u32) as the type?
And probably htons(0x6969) not htons(6969).
And that unaligned access indicates that you probably have the wrong offset.

Look at the receive debugging code in the pci-skeleton.c example driver
for an example of how to use skb->data
    ftp://www.scyld.com/pub/network/pci-skeleton.c

Also, if you are using the 3c905C (or later) you have the "RealTimeCnt"
register.  This is a counter at offset 0x40 intended to support
real-time transmit scheduling and time stamps. It is a wrapping 32 bit
counter that increments every 800ns.

Donald Becker                           becker@xxxxxxxxx
Scyld Computing Corporation             http://www.scyld.com
410 Severn Ave. Suite 210               Second Generation Beowulf Clusters
Annapolis MD 21403                      410-990-9993


<Prev in Thread] Current Thread [Next in Thread>