From owner-cvs-all@FreeBSD.ORG Wed Sep 20 11:19:16 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 693EE16A407; Wed, 20 Sep 2006 11:19:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9976543D7B; Wed, 20 Sep 2006 11:19:15 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 121AC46BE7; Wed, 20 Sep 2006 07:19:15 -0400 (EDT) Date: Wed, 20 Sep 2006 12:19:14 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: David Malone In-Reply-To: <200609201106.aa59351@walton.maths.tcd.ie> Message-ID: <20060920121541.P79640@fledge.watson.org> References: <200609201106.aa59351@walton.maths.tcd.ie> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/dev/bge if_bge.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2006 11:19:16 -0000 On Wed, 20 Sep 2006, David Malone wrote: >>> 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. As an issue of symmetry, it strikes me that the driver is most aware of what has been removed from the packet, and so in the best position to provide substitute data to make up for the removed data. As a matter of abstraction, it seems likely that the link layer might provide a utility routine to help mock up the missing data, however. I tend to agree with the observation that we should not frob the driver level state as a result of BPF listeners -- if nothing else, this increases the chances of hitting race conditions between changing of card state and the descriptor rings, in which some packets in the rings were processed with tag stripping, and some without, but the driver treats them all as being consistent with its most recent notion of how the flags were set. Ideally, we should frob the hardware's encapsulation/etc as little as possible, and probably drain the send and receive descriptor rings when that happens so there's a clean transition. Robert N M Watson Computer Laboratory University of Cambridge