From owner-freebsd-net@FreeBSD.ORG Fri Sep 7 08:29:32 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 19A0D1065701 for ; Fri, 7 Sep 2012 08:29:32 +0000 (UTC) (envelope-from anshukla@juniper.net) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by mx1.freebsd.org (Postfix) with ESMTP id A44728FC1C for ; Fri, 7 Sep 2012 08:29:31 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUEmwY1BBZ/e3HKRPKF4faYPiW3mG5tx2@postini.com; Fri, 07 Sep 2012 01:29:31 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 7 Sep 2012 01:28:20 -0700 From: Anuranjan Shukla To: George Neville-Neil Date: Fri, 7 Sep 2012 01:28:16 -0700 Thread-Topic: Proposal for changes to network device drivers and network stack (RFC) Thread-Index: Ac2M0rzuKGHDCSRhRNuQSErTsm0BkQ== Message-ID: In-Reply-To: <5F3C03B6-01D0-42DE-BE9E-323DBDC90C8E@neville-neil.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Fri, 07 Sep 2012 08:29:32 -0000 Hi George, Thanks for taking a look. Some answers/comments below. > >> Building FreeBSD without the network stack (network stack as a module) >> ---------------------------------------------------------------------- >> >This would be interesting for many reasons, and I think it would be a good >contribution. Does the work you've done in this area handle the VNET >stuff that is in the stack as well? That is, how well does the network >stack >as a module play with the vnet architecture? I'll follow up on this one separately. > >> struct socket { >>=20 >> int so_fibnum; /* routing domain for this socket */ >> uint32_t so_user_cookie; >> + u_int so_oqueue; /* manage send prioritizing based on >>application >> needs */ >> + u_short so_lrid; /* logical routing */ >> }; >>=20 > >I'd be interested to know how this is used. We use the first one as a 'direction' to the forwarding path to select an appropriate priority queue to send the packet on. In a generic (i.e. Something other than our specific system) system, one could consider interesting ways to use queues on a multi queue NIC with help from a driver. The second one is for a system with logical routing capabilities (multiple routing systems within the same chassis). It gives an application opening a socket an option to select the specific logical routing instance. I'll provide smaller pieces of diffs for the kernel without networking patch I'd sent out. Let me know if you prefer the device driver interface to be in that too. Thanks, Anu