From owner-freebsd-net@FreeBSD.ORG Tue Aug 28 09:24:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FFF31065670 for ; Tue, 28 Aug 2012 09:24:33 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm25-vm0.bullet.mail.bf1.yahoo.com (nm25-vm0.bullet.mail.bf1.yahoo.com [98.139.213.156]) by mx1.freebsd.org (Postfix) with SMTP id A4E608FC14 for ; Tue, 28 Aug 2012 09:24:31 +0000 (UTC) Received: from [98.139.212.144] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 09:24:25 -0000 Received: from [98.139.213.5] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 09:24:25 -0000 Received: from [127.0.0.1] by smtp105.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 09:24:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1346145865; bh=3KK3NuarPP1Aq3tVdzNtGQHVvVlH3gd+mT8ry9HGwj8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=s4YlEWAqY2GLOwLQVnNwUybv82mK9wMnDLckFhMWQXkwcKnWpKrrPSBZlcV7iEFzfmz5qyUaf7Ih8Pumok+TPt+ZTZdZBSLph/aVrEVhOI9ZVmEBePLQ4gYXtOFPF9zFxXzxEkfFiDhcF18JnA2soNvSJWyqm9YFvX8n5uXQi9w= X-Yahoo-Newman-Id: 432194.21404.bm@smtp105.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9njmQGwVM1kRcJPgWhIy87ao4_ffksZx3Ptr0qhXMPl2oJ7 KLhNpcGz.Qks2IXKgXWYS7EAkbyWR2_P5TwW0VgcMlULmOJNsxErM0Q1zEnK PSIQ2A0hyVAMe9ZA8g.21C5xq3b1GfaIZTE3NwnUigknNPXTLKbVT1SIfq84 Dds5LoZs66ynV6aFGDBbN4MU_Qz9QClqTS.QnWFyCigyrlyaFw0L1.E74yoU a1z35DtjNVYCl4QpPBjRmle1RdFXJ_Ijj1mzg7EWE5JLrWtLRTNnO9GitI7t dTGJKC2gtPNAs2QnXwpTP8SpRDtIHgMAMrOkgKq7u6OVRX1_zvTE2MdeC1TF bPcbJd2QXHMqWBaNnq5PUII.7bTvP4xvT1FiZR2cINOosBfb6hlCucqz5DVF zseVmD0i2F_XbEMuB.7mw7XLdQXswokSC9jqaN0Shw7BdLdNGrQdp2W2jl4l SoJMhPe3u62A5yFg6G1fFvqhvswfLBEnOvjIdJWrLCuX9eO3TAf0jiOJstxa qy7JRQy9g76rnH8_ZEgyCTyZP6_w- X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-vc0-f182.google.com (moonlightakkiy@209.85.220.182 with plain) by smtp105.mail.bf1.yahoo.com with SMTP; 28 Aug 2012 02:24:25 -0700 PDT Received: by vcbgb22 with SMTP id gb22so7090621vcb.13 for ; Tue, 28 Aug 2012 02:24:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.40 with SMTP id a8mr11824140vdf.4.1346145864784; Tue, 28 Aug 2012 02:24:24 -0700 (PDT) Received: by 10.58.114.111 with HTTP; Tue, 28 Aug 2012 02:24:24 -0700 (PDT) Date: Tue, 28 Aug 2012 03:24:24 -0600 Message-ID: From: PseudoCylon To: Anuranjan Shukla Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Proposal for changes to network device drivers and network stack (RFC) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 09:24:33 -0000 > ------------------------------ > > Message: 2 > Date: Fri, 24 Aug 2012 21:11:45 -0700 > From: Anuranjan Shukla > Subject: Proposal for changes to network device drivers and network > stack (RFC) > To: "freebsd-net@freebsd.org" > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > At Juniper Networks, we've been using FreeBSD to build JUNOS (Juniper's > network operating system). So far the additions and changes to the > functionality were made inline, making the task of upgrading to new > versions of FreeBSD progressively difficult. We've been looking at JUNOS > to see if we can build it off of a clean FreeBSD base rather than making > changes to the OS inline. As part of that work, we've come up with a few > expansive change proposals to FreeBSD kernel that will make this task > possible for us, and hopefully also contribute something of interest to > the community. If the community is in agreement with these, we'd like to > contribute/commit them to FreeBSD. > > This is a proposal and an RFC. The actual nomenclature is open to ideas > (naming etc). From Juniper, Marcel (marcel@freebsd.org) will be attending > the upcoming DevSummit at Cambridge. He's indicated that interested folks > are welcome to chat with him about this stuff during the summit. > > The changes we propose are (the code/diffs etc are indicated > at the end of this email): > > - Network Device Drivers > - Building FreeBSD kernel without network stack, network stack as a module > - Changes to mbuf and socket structures (minor member additions) > > Network Device Drivers: > ----------------------- > As we indicated during DevSummit 2012, JUNOS extended the interface > functionality in a big way to support logical interfaces, interface > hierarchies and scaling in general. Not surprisingly this resulted in > changing the drivers to use our custom interface structure(s). A simple > way to resolve this without impacting the rest of the large codebase is to > avoid directly accessing (get/set) the ifnet structure from the drivers. > Using get/set functions to update the functionality would make the driver > more 'flexible' for the network stack to work with in situations where the > stack wants to extend the interface functionality. > > For eg, > > em_start_locked(struct ifnet *ifp, struct tx_ring *txr) > { > - struct adapter *adapter = ifp->if_softc; > + struct adapter *adapter = if_getsoftc(ifp); > struct mbuf *m_head; > > EM_TX_LOCK_ASSERT(txr); > > - if ((ifp->if_drv_flags & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) != > + if ((if_getdrvflags(ifp) & (IFF_DRV_RUNNING|IFF_DRV_OACTIVE)) != > IFF_DRV_RUNNING) > return; > > if (!adapter->link_active) > return; > > - while (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) { > + while (!if_sendq_empty(ifp)) { > /* Call cleanup if number of TX descriptors low */ > if (txr->tx_avail <= EM_TX_CLEANUP_THRESHOLD) > em_txeof(txr); > if (txr->tx_avail < EM_MAX_SCATTER) { > - ifp->if_drv_flags |= IFF_DRV_OACTIVE; > + if_setdrvflagbits(ifp,IFF_DRV_OACTIVE, 0); > break; > } > - IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); > + m_head = if_dequeue(ifp); > if (m_head == NULL) > break; > /* > @@ -1010,7 +1009,7 @@ em_start_locked(struct ifnet *ifp, struct tx_ring > if (em_xmit(txr, &m_head)) { > if (m_head == NULL) > break; > - IFQ_DRV_PREPEND(&ifp->if_snd, m_head); > + if_sendq_prepend(ifp, m_head); > break; > > This allows Juniper to have its own interface structure(s) instead of > ifnet, and still be able to use the driver without modification. Since the > notion of ifnet is abstracted away, other users can also find this useful > in plugging in functionality without having muck around in the driver code. > > The ifnet split/restructuring was discussed in DevSummit at BSDCan in May > 2012. This change can also aid in that work. > Non-attendees like me would better read the minutes before commenting anything, but http://wiki.freebsd.org/201205DevSummit/Network indicates the result is TBD. So, I will just dump my thought. Wouldn't using prepossessor macro or hooking be more flexible? (Could support multiple functionality.) i.e. #ifndef LOOK_MA_NEW_IFNET #define IF_GETDRVFLAGS(f) f->if_drv_flags ... #else #define IF_GETDRVFLAGS(f) new_getdrvflags(f) ... #endif or init somewhere ifp->if_getdrvflags = new_getdrvflags; ... and call if ((ifp->if_getdrvflags(ifp) & ... AK