From owner-freebsd-net@FreeBSD.ORG Mon Sep 6 06:14:24 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF31A16A4CE; Mon, 6 Sep 2004 06:14:24 +0000 (GMT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id B115743D1F; Mon, 6 Sep 2004 06:14:24 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i866ELIb026902; Sun, 5 Sep 2004 23:14:21 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i866ELXh026901; Sun, 5 Sep 2004 23:14:21 -0700 (PDT) (envelope-from rizzo) Date: Sun, 5 Sep 2004 23:14:21 -0700 From: Luigi Rizzo To: Matthew Dillon Message-ID: <20040905231421.B26501@xorpc.icir.org> References: <20040905205249.GA81337@cell.sick.ru> <20040905142036.A23213@xorpc.icir.org> <200409052137.i85LbV1V053075@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200409052137.i85LbV1V053075@apollo.backplane.com>; from dillon@apollo.backplane.com on Sun, Sep 05, 2004 at 02:37:31PM -0700 cc: hackers@freebsd.org cc: Gleb Smirnoff cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? (My pov) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2004 06:14:25 -0000 On Sun, Sep 05, 2004 at 02:37:31PM -0700, Matthew Dillon wrote: > Well, wait a second... are we talking about a lot of packets being > discarded by the filter in 'normal' operation, or are we talking about > an attack? Because if we are takling about an attack the LAST ethernet ... Sure, in this thread we are talking of a performance hack for a specific piece of hardware, which may be obsolete and poorly performing, but is also one of the few widespread ones supporting coax. Once upon a time, this hack was basically the only way to make a coax bridge perform decently and not saturate the bus (ISA or PCMCIA). Granted, these days maybe nobody uses coax anymore or has a desire to upgrade these boxes. If the existing code is broken (but please make a reasonable effort to prove it, don't just hint things) or gets in the way because e.g. it would complicate locking for everyone else, or because the bridge_in_ptr() or BDG_ACTIVE() calls disappear from the API, then i am all for the suggested change. But if the suggested change is something in preparation for other changes that may never see the light, then i'd rather just add a comment/reminder in the relevant bridging file, and nuke the code in if_ed.c and everywhere else when this becomes necessary. After all the problem (alleged layering violation) is well understood, and the offender (assuming this is the only one -- the way to check would be rename bridge_in_ptr() and BDG_ACTIVE() to something different and try a build of the kernel and modules) and the trivial fix are known so postponing the change is not going to harm anyone. Speaking about layering violation -- sure, the above bridge thing is a small one, but there are much worse (and more critical) offenders. E.g. the device driver preferably should not know who is going to consume its packets, and you are pointing the finger at the bridging code -- but this applies to bpf as well, yet several drivers still have explicit if (ifp->if_bpf) bpf_mtap(ifp, m_head); or implicit BPF_MTAP(ifp, m_head); bpf hooks. And another huge one is the support for delayed checksums, which permeates the entire network stack and breaks bpf feeding it with packets carrying invalid checksums. I guess the above means "do what you like, just don't put an 'Approved by: luigi' line in the commit msg" :) cheers luigi