cvs commit: src/sys/dev/bge if_bge.c

[David Malone]

> >Putting ethernet specific code in bpf_* feels like a bad idea.

> Is this any worse than having ethernet specific code in the mbuf header?

Well, I didn't really like the sound of that either, but I was too
polite to mention it ;-)

> >(It's interesting to note that as ethernet cards introduce more
> >features it is getting harder for us to tell what we put on the
> >wire.

> This probably makes it more critical for bpf to not automatically
> disable NIC features, otherwise we run the risk of introducing
> heisenbugs in the network system.

True - turning off hardware VLAN tagging when there is a BPF listener
also seems wrong (though I guess it would be the driver that actually
did this, not BPF).

> >With VLAN tagging we can't trust the VLAN tag.

> Unlike checksums etc, the kernel must be able to determine the VLAN
> tag to be able to process the packet.  The problem is that it isn't
> where bpf expects.

True, though BPF just expects to find the data where it should be
on the wire. It seems like it should be up to the responsibility
of the code calling bpf_*tap* to make sure it is in that format.
Checksums that seem incorrect to bpf have already caused a non-trivial
number questions on the mailing lists.

We almost need a way to indicate to BPF that there are certain
ranges of bytes that we couldn't see because they are provided by
the hardware rather than us.

	David.