From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 5 21:37:31 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82C4216A4CE; Sun, 5 Sep 2004 21:37:31 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E4D443D1D; Sun, 5 Sep 2004 21:37:31 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i85LbVla053076; Sun, 5 Sep 2004 14:37:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i85LbV1V053075; Sun, 5 Sep 2004 14:37:31 -0700 (PDT) (envelope-from dillon) Date: Sun, 5 Sep 2004 14:37:31 -0700 (PDT) From: Matthew Dillon Message-Id: <200409052137.i85LbV1V053075@apollo.backplane.com> To: Luigi Rizzo References: <20040905205249.GA81337@cell.sick.ru> <20040905142036.A23213@xorpc.icir.org> cc: hackers@freebsd.org cc: Gleb Smirnoff cc: net@freebsd.org Subject: Re: bridge callbacks in if_ed.c? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2004 21:37:31 -0000 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 device anyone would ever want to use would be ED. i.e. they would be under a major cpu load anyway and would be far better served using a better ethernet card. It seems silly to leave a major hack in the system just to support attacks on an ethernet device that nobody in their right mind would use if they expected to be attacked! Also, most ED devices are limited to 10BaseT (?), it's hard to imagine how the added load could possibly make things any worse then they would otherwise be, and similarly hard to imagine why anyone would want to use a programmed-I/O interface at 100BaseT or greater speeds (I'd say that the poor guy would deserve what he gets from that!). -Matt :there are performance reasons to do this way -- grabbing :the entire packet is expensive because it is done via programmed :I/O, so the current code only grabs the header, does the :filtering, and grabs the rest of the packet only if :needed. : :Probably the current code runs bridge_in_ptr() twice, but I :believe this is still cheaper than grabbing all packets :entirely. : :I'd rather not apply the patch unless you can show that :the current code leads to incorrect behaviour. : :cheers :luigi