Date: Wed, 20 Sep 2006 11:06:06 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/bge if_bge.c Message-ID: <200609201106.aa59351@walton.maths.tcd.ie> In-Reply-To: Your message of "Wed, 20 Sep 2006 19:28:42 %2B1000." <20060920092842.GD738@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200609201106.aa59351>