netdev
[Top] [All Lists]

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

To: Donald Becker <becker@xxxxxxxxx>
Subject: Re: 3c59x.c modified for time measurement / code included
From: Guilhem Tardy <guilhem_tardy@xxxxxxxxx>
Date: Wed, 19 Sep 2001 14:34:13 -0700 (PDT)
Cc: netdev@xxxxxxxxxxx, andrewm@xxxxxxxxxx, greearb@xxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.10.10109191501540.1209-100000@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
> 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.

As a matter of fact, I did retain some of the hardware checksum as in "if
(rx_status & RxDError)", but you are right in saying that I should keep the
hardware TCP & UDP checksum as well, thanks.

> > /* ### 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?

That was pointed out in a previous email, and I agree (see below).

> And probably htons(0x6969) not htons(6969).

OK.

        /* ### add <driver rcv completed> time */
        if (*(((u8 *) skb->data) + 9) == 17 && ((u16 *) (((u8 *) skb->data) + 
20))[1]
== htons(0x6969)) {
                *((u32 *) (skb->data + 28)) = 0x00000000;
                ((u32 *) (skb->data + 28))[1] = 0x00000001;
                (((u32 *) (skb->data + 28))[2] = 0x00000002;
        }

> 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

Thanks for the link, I looked at it but remain puzzled at this problem with
"unaligned access". Could you please tell me more about it?

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

Is this supported by recent NICs from other vendors as well?

As for my current test, I actually don't need such a thing, since I already got
a 8192Hz counter (by interrupt) working and an accuracy of a few milliseconds
is enough. But if I can access this RealTimeCnt from other parts of the kernel
AND from the application space, this could come handy. Do you have sample code
for that?

Regards,
Guilhem.


__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/

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