In message <20050205213556.GB20912@shrubbery.net>john heasley writes
>Sat, Feb 05, 2005 at 12:34:13PM -0800, Jonathan Stone:
>> In message <1107634190.260137.8498.nullmailer@yamt.dyndns.org>,
>> YAMAMOTO Takashi writes:
>> >hi,
>> 
>> >bge doesn't have to set M_CSUM_NO_PSEUDOHDR in if_csum_flags_tx.
>> >what's a problem?
>> 
>> D'oh! If there are separate flag spaces for Tx and Rx, then the patch
>> isn't actually wrong.  <slap head> That's what I get for replying
>> before my first coffee of the day; very sorry.
>
>hey, thanks for reviewing it!  I appreciate it.

Well, thanks. But inaccurate critisum can be a pain, and I'm sorry for
that.


>> I still don't like the precedent it sets, and I think it'd be cleaner
>> to allocate a separate mask bit (0x40000000?); but it's not a big deal.
>
>Is that precedent not already set by the other flags whose meaning is
>slightly different depending upon the direction of flow?

The way I saw Jason's original code, the original m_pkthdr.csum_flags
had clear meanings. The only difference is that due to asymmetry
between send and receive, the flags (and associated data) were passed
from hardware to software on receive, but passed from software to
hardware on transmit. (the output path checks the driver capabilities,
and  driver

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

Also, after checking the code again, I wonder if we can't do better at
initializing the {th,uh}_sum fields to zero, and mandating that the
field be suitably pulled-up and aligned for software summing.  (I've
never been entirley happy about KAME(?) detuning of software checksums,
but that's a different story).


>I chose not to eat another bit because it seemed like the others (differing
>in the direction of flow)

certainly defensible.

> and I do not know what other cases may need to be
>handled in the remaining available bits (granted there are ~15 left).
>Perhaps that is silly?

... silly is a bit strong, but basically that's one reason why I'd
like to think about how we use the namespace, and pkthdr flags versus
interface flags.