Subject: Re: tcp/udp vector h/w checksum
To: john heasley <firstname.lastname@example.org>
From: Jonathan Stone <email@example.com>
Date: 02/05/2005 11:22:31
In message <20050205182306.GA20912@shrubbery.net>,john heasley writes:
>I've asked for comment on this before, but that may have been obscured
>by information about the gem driver.
>Basically, there are at least two chips, hme and gem, which offer only a
>linear h/w checksum. That is, given a start offset and a stuff offset,
>they checksum from the start to the end of the packet and place the result
>at the stuff offset. They have no provision to compute the pseudo-header
>portion of the checksum.
>The pseudo-header checksum can be computed in the driver, but that means
>code duplication and more time spent in the driver.
>The attached diff adds the pseudo header to the packet if M_CSUM_NO_PSEUDOHDR
>is set on if_csum_flags_tx and overloads m_pkthdr.csum_data, placing the IP
>header length in the high 16 bits and thus the driver does not need to look
>at the packet at all.
>I've been using this with hme for more than a month now and have not noticed
>any problems. I'd like commit this today and get the hme changes in shortly
I can see your problem, but I think your patch breaks the (intended)
existing semantics of M_CSUM_NO_PSEUDOHDR.
The gotcha is that we support hardware, e.g., bge(4), which implements
a full normal IPv4 checksum on outbound traffic, but does only the
no-pseudoheader on received traffic. (That's a defensible choice for,
e.g., summing fragmented large IP datagrams). And we really don't
want to do the Tx-no-phdr work in cases where we don't have to. (I
wasn't aware of the hme/gem hardware, or just wasn't thinking clearly,
when I implemented the x-side no-phdr flag we have.)
So.... if you can find a spare bit, I suggest creating separate Rx and
Tx CSUM_NO_PHDR flags. I'm happy to review or test or suggest
changes, but I can't get to bge hardware until Monday.