From owner-freebsd-net@FreeBSD.ORG  Wed Feb  6 14:37:17 2013
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: net@freebsd.org
Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115])
 by hub.freebsd.org (Postfix) with ESMTP id 09C85837;
 Wed,  6 Feb 2013 14:37:17 +0000 (UTC)
 (envelope-from luigi@onelab2.iet.unipi.it)
Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238])
 by mx1.freebsd.org (Postfix) with ESMTP id C4AFEEDA;
 Wed,  6 Feb 2013 14:37:16 +0000 (UTC)
Received: by onelab2.iet.unipi.it (Postfix, from userid 275)
 id 34E6D73029; Wed,  6 Feb 2013 15:37:14 +0100 (CET)
Date: Wed, 6 Feb 2013 15:37:14 +0100
From: Luigi Rizzo <rizzo@iet.unipi.it>
To: "Alexander V. Chernikov" <melifaro@freebsd.org>
Subject: Re: Make kernel aware of NIC queues
Message-ID: <20130206143714.GA45782@onelab2.iet.unipi.it>
References: <5112666F.3050904@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5112666F.3050904@FreeBSD.org>
User-Agent: Mutt/1.4.2.3i
Cc: freebsd-hackers@freebsd.org, net@freebsd.org
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/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, 06 Feb 2013 14:37:17 -0000

On Wed, Feb 06, 2013 at 06:19:27PM +0400, Alexander V. Chernikov wrote:
> Hello list!
> 
> Today more and more NICs are capable of splitting traffic to different 
> Rx/TX rings permitting OS to dispatch this traffic on different CPU 
> cores. However, there are some problems that arises from using multi-nic 
> (or even singe multi-port NIC) configurations:
...
> I propose implementing common API to permit drivers:
> * read user-supplied number of queues/other queue options (e.g:
> * notify kernel of each RX/TX queue being created/destroyed
> * make binding queues to cores via given API
> * Export data to userland (for example, via sysctl) to permit users:
> a) quickly see current configuration
> b) change CPU binding on-fly
> c) change flowid numbers on-fly (with the possibility to set 1) 
> NIC-supplied hash 2) manually supplied value 3) disable setting M_FLOWID)
> 
> Having common interface will help users to make network stack tuning 
> easier and puts us one step further to make (probably userland) AI which 
> can auto-tune system according to template ("router", "webserver") and 
> rc.conf configuration (lagg presense, etc..)
> 
> 
> What do you guys think?

this is certainly a good idea and a welcome one.

Linux has tried to come up with a common framework to implement
this kind of controls using "ethtool", and we should probably
have a look at their approach and reuse it (or at least the good ideas)
to avoid reinventing the same thing.

cheers
luigi