problem in driver network code

problem in driver network code

[francois donzet]

Hi all

I am writing my own ethernet driver, and i have a
little question on checksum offloading :

I am trying to understand the role of skb->csum. I've
read some code, and see that it is filled (for example
in e100 code) by the sum of all words excepting the
ethernet II header.

The fact is, on an input path, if CHECKSUM_HW is set,
TCP uses skb->csum to verify the complete checksum
(adding the pseudo header one).

It seems to me that there is a problem ;). If i store
in skb->csum a sum of all words of the packet data, it
 will be unusable by tcp (the skb->csum doesn't
contain the checksum of tcpheader plus data only, as
the ipheader is part of the packet when the sum is
computed)

What do i miss ? I think the skb->csum MUST at one
point contain only a sum on tcpheader+data.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Re: problem in driver network code

[Rask Ingemann Lambertsen]

On Fri, Nov 07, 2003 at 09:38:44AM +0100, francois donzet wrote:
> 
> It seems to me that there is a problem ;). If i store
> in skb->csum a sum of all words of the packet data, it
>  will be unusable by tcp (the skb->csum doesn't
> contain the checksum of tcpheader plus data only, as
> the ipheader is part of the packet when the sum is
> computed)

That can be accounted for by the TCP code because the IP header is known to
the TCP code. IIRC, the pseudoheader is similiar to a real IP header, so it
may take just a few lines of code to make up for the difference, but I
haven't checked that.

What do you do with an IEEE 802.1q (VLAN) or 802.2 (LLC) packet? The VLAN
code in vlan_skb_recv() does not adjust skb->csum or skb->ip_summed. Neither
does the 802.2 code.

-- 
Regards,
Rask Ingemann Lambertsen

Re: problem in driver network code

[francois donzet]

 --- Rask Ingemann Lambertsen <rask@sygehus.dk> a
écrit : > On Fri, Nov 07, 2003 at 09:38:44AM +0100,
francois
> donzet wrote:
> > 
> > It seems to me that there is a problem ;). If i
> store
> > in skb->csum a sum of all words of the packet
> data, it
> >  will be unusable by tcp (the skb->csum doesn't
> > contain the checksum of tcpheader plus data only,
> as
> > the ipheader is part of the packet when the sum is
> > computed)
> 
> That can be accounted for by the TCP code because
> the IP header is known to
> the TCP code. IIRC, the pseudoheader is similiar to
> a real IP header, so it
> may take just a few lines of code to make up for the
> difference, but I
> haven't checked that.

The theory seems fine, but there is no clue of this
way in the code.

> What do you do with an IEEE 802.1q (VLAN) or 802.2
> (LLC) packet? The VLAN
> code in vlan_skb_recv() does not adjust skb->csum or
> skb->ip_summed. Neither
> does the 802.2 code.

no matter the link layer header is 802.3,802.2 or
8021.q . Tcp checksum offloading is supported,
whatever the type of the link layer (as skb->csum is
computed without the link layer header).



___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

hw checksum acceleration (Was: problem in driver network code)

[Rask Ingemann Lambertsen]

On Mon, Nov 10, 2003 at 09:14:17AM +0100, francois donzet wrote:

> > What do you do with an IEEE 802.1q (VLAN) or 802.2
> > (LLC) packet? The VLAN
> > code in vlan_skb_recv() does not adjust skb->csum or
> > skb->ip_summed. Neither
> > does the 802.2 code.
> 
> no matter the link layer header is 802.3,802.2 or
> 8021.q . Tcp checksum offloading is supported,
> whatever the type of the link layer (as skb->csum is
> computed without the link layer header).

The documentation says that skb->csum covers the whole packet as seen by
netif_rx(). eth_type_trans() pulls off the 14 byte header before netif_rx()
is called. But if the frame is really 802.1q or 802.2, then the extra bytes
of the header will be pulled off but skb->csum will still cover those bytes.
Unless, of course, the device knows about 802.1q and 802.2, but that wasn't
supposed to be necessary, was it?

-- 
Regards,
Rask Ingemann Lambertsen