In message <ea5996adc1bf510031774ad6319eadf8@shagadelic.org>,
Jason Thorpe writes:

>On Feb 5, 2005, at 12:34 PM, Jonathan Stone wrote:
>
>> If we also add an XXX comment to sys/sys/mbuf.h, warning that the
>> flags have different interpretation in different if_csum_flags_rx
>> context versus if_csum_flags_tx context, I'd be happier.
>
>He did add such a comment.

Nope.  John's diff did add a comment mentioning Rx and Tx behaviour;
but it certainly did not mention the scope of the change in usage
(if_csum_flags_tx/if_csum_flags_rx). As I wrote to John later in
message <E1CxY5b-0006GW-00@smeg.dsg.stanford.edu>:

  JS> The M_CSUM_NO_PSEUDOHDR ``quirk'' was a one-off that I tacked on to
  JS> handle how bge hardware does checksum offload. The ``quirk'' only
  JS> applied to m_pkthdr.csum_flags, as a modifier to M_CSUM_DATA.  Now
  JS> that you want it to apply to per-interface flags as well, I'd say its
  JS> time to stand back a little, and think about how the checksum "quirk"
  JS> mechanism will scale to other hardware with slightly different
  JS> quirkiness.

I can (I once suggested it!) very easily see hardware designers doing
a full, 1s-complemented UDP sum for non-fragmented, single-frame UDP
received packets; but doing the non-1s-complement, non-pseudo header
sum for fragmented packets.

OK, so that example doesn't work so for TX, but you can see how keying
upper-level behaviour off per-interface quirk flags may be problematic:
the quirkiness may depend on size or oather attributes of the packet!

So I want to think a little more carefully about the semantics of
mbuf-header quirk csum flags, versus per-interface Rx/Tx csum flags,
before we start resuing mbuf csum-quirk flags to if_csum_flags_{tx,rx}.
(That's why I suggested an XXX comment.)

(Does that make more sense now?)