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

hi John,  

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.