From owner-cvs-src@FreeBSD.ORG Wed Sep 20 10:06:08 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8AA416A403; Wed, 20 Sep 2006 10:06:08 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 9F4C943D5F; Wed, 20 Sep 2006 10:06:07 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 20 Sep 2006 11:06:06 +0100 (BST) Received: from localhost ([127.0.0.1] helo=maths.tcd.ie) by walton.maths.tcd.ie with SMTP id ; 20 Sep 2006 11:06:06 +0100 (BST) To: Peter Jeremy In-reply-to: Your message of "Wed, 20 Sep 2006 19:28:42 +1000." <20060920092842.GD738@turion.vk2pj.dyndns.org> Date: Wed, 20 Sep 2006 11:06:06 +0100 From: David Malone Message-ID: <200609201106.aa59351@walton.maths.tcd.ie> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/bge if_bge.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2006 10:06:09 -0000 > >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.