From owner-freebsd-net  Fri Aug 28 01:53:35 1998
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id BAA19785
          for freebsd-net-outgoing; Fri, 28 Aug 1998 01:53:35 -0700 (PDT)
          (envelope-from owner-freebsd-net@FreeBSD.ORG)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA19772
          for <net@freebsd.org>; Fri, 28 Aug 1998 01:53:28 -0700 (PDT)
          (envelope-from luigi@labinfo.iet.unipi.it)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA04891 for net@freebsd.org; Fri, 28 Aug 1998 08:56:15 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199808280656.IAA04891@labinfo.iet.unipi.it>
Subject: Proposal for (minimal) change to network drivers in promisc. mode
To: net@FreeBSD.ORG
Date: Fri, 28 Aug 1998 08:56:15 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

In most (all ?) network card drivers, there are comments like the
following (generally copied from one driver to the other...):

    /*
     * Note that the interface cannot be in promiscuous mode if
     * there are no BPF listeners.  And if we are in promiscuous

now, isn't that a strong assumption ? There could be more reasons
to enable promiscuous mode on a machine (e.g. the bridging code i
am writing now, and possibly others), and the savings in the code
deriving from that assumption are really negligible: typically the
code would go from

    if (sc->arpcom.ac_if.if_bpf) {
	bpf_mtap(&sc->arpcom.ac_if, m);
	if ((sc->arpcom.ac_if.if_flags & IFF_PROMISC) && pkt is not for us)
	    drop pkt ;
    }

to

    if (sc->arpcom.ac_if.if_bpf)
	bpf_mtap(&sc->arpcom.ac_if, m);
    if ((sc->arpcom.ac_if.if_flags & IFF_PROMISC) && pkt is not for us)
	drop pkt ;

where the second 'if' is very cheap when not in promiscuous mode.

Some drivers already decouple bpf and PROMISC handling in the way
shown above, and i think this is all in the interest of clarity.

For others the modifications would be trivial. At a
first scan of the code i see the following:

    "de", "fe", "ie", "lnc"	already fixed.

    "ed", "fxp", "ep", "wl", "zp":	one-line fix as shown above

	Note: the ep" driver one seems to have a redundant expensive
		check for broadcast address

    "le", "ze"	almost as simple as above

    "eg", "el", "ex", "tx" seem not to support multicast/promisc mode
		so this is less of a problem.

What do you think, can i submit patches for at least a few of these drivers
with the hope that they get committed ?

	luigi

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message