Sat, Feb 05, 2005 at 02:07:39PM -0800, Jonathan Stone:
> 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.

Ah, I understand now.  Suggestions?  I have none.  Though both sets of
fields (ifnet and pkthdr) are dedicated to check sum handling.

I'm really only familiar with hme and gem; no idea what capabilities
other chips offer (today) other than the info I've picked off tech-net,
which is negligible.

> 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

This seems like that place to do that; if you're not going to otherwise
alter the checksum field, then zero it.  Note the comment:
                 * XXX Does any hardware require the {th,uh}_sum
                 * XXX fields to be 0?
But, I'm not clear on how the IPsec code complicates that (if at all) or
would benefit from it being done elsewhere.  IPsec seems to short-circuit
the logic - do it's thing and ship the packet.

> 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).

OK, that seems orthogonal to the diffs at hand, but you're now beyond my
understanding of mbufs.  It seems like that might be ununecessary data
moving - but I am probably missing something.