From owner-freebsd-net@FreeBSD.ORG  Wed May 21 14:03:46 2003
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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 DD97337B401
	for <freebsd-net@freebsd.org>; Wed, 21 May 2003 14:03:46 -0700 (PDT)
Received: from mail.sandvine.com (sandvine.com [199.243.201.138])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 0CB3243F75
	for <freebsd-net@freebsd.org>; Wed, 21 May 2003 14:03:46 -0700 (PDT)
	(envelope-from ddolson@sandvine.com)
Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19)
	id <K42CVDSD>; Wed, 21 May 2003 17:03:44 -0400
Message-ID: <FE045D4D9F7AED4CBFF1B3B813C8533701918C71@mail.sandvine.com>
From: Dave Dolson <ddolson@sandvine.com>
To: freebsd-net@freebsd.org
Date: Wed, 21 May 2003 17:03:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: netgraph: why does ng_ether bother enqueuing packets?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2003 21:03:47 -0000

For reasons of performance, I tried the following modification to ng_ether.c
in FreeBSD 4.7, and it seemed to work fine.
The change is to call ng_send_data() vs. ng_queue_data().

We are running in polling mode, so ng_ether_input is called @ netisr anyhow.
(Always ?)

  static void
  ng_ether_input2(node_p node, struct mbuf **mp, struct ether_header *eh)
  {
        const priv_p priv = node->private;
        meta_p meta = NULL;
        int error;
  
        /* Glue Ethernet header back on */
        if ((error = ng_ether_glueback_header(mp, eh)) != 0)
                return;
  
        /* Send out lower/orphan hook */
+ #ifdef DEVICE_POLLING
+       /* send directly, since we're already @ splnet */
+       (void)ng_send_data(priv->lower, *mp, meta);
+ #else
        (void)ng_queue_data(priv->lower, *mp, meta);
+ #endif
        *mp = NULL;
  }

Does anyone know why this might be bad?  
Any reason why this couldn't be done in interrupt (non-polling) mode also?

The system's main purpose is to process packets.

Thanks,
David Dolson (ddolson@sandvine.com, www.sandvine.com)