From owner-freebsd-current@FreeBSD.ORG Wed Jul 9 14:36:53 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88FDD9A; Wed, 9 Jul 2014 14:36:53 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4670B2507; Wed, 9 Jul 2014 14:36:53 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 36C4C1FE028; Wed, 9 Jul 2014 16:36:45 +0200 (CEST) Message-ID: <53BD5385.4090208@selasky.org> Date: Wed, 09 Jul 2014 16:36:53 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Navdeep Parhar , freebsd-net@freebsd.org, FreeBSD Current Subject: Re: [RFC] Add support for changing the flow ID of TCP connections References: <53BC2E73.6090700@selasky.org> <53BC43AE.3040409@FreeBSD.org> In-Reply-To: <53BC43AE.3040409@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 14:36:53 -0000 On 07/08/14 21:17, Navdeep Parhar wrote: > On 07/08/14 10:46, Hans Petter Selasky wrote: >> Hi, >> >> I'm working on a new feature which will allow TCP connections to be >> timing controlled by the ethernet hardware driver, actually the mlxen >> driver. The main missing piece in the kernel is to allow the mbuf's >> flowid value to be overwritten in "struct inpcb" once the connection is >> established and to have a callback once the TCP connection is gone so >> that the assigned "flowid" can be freed by the ethernet hardware driver. >> >> The "flowid" will be used to assign the outgoing data traffic of a >> specific TCP connections to a hardware controlled queue, which in >> advance contain certain parameters about the timing for the transmitted >> packets. >> >> To be able to set the flowid I'm using existing functions in the kernel >> TCP code to lookup the "inpcb" structure based on the 4-tuple, via the >> "ifp->if_ioctl()" callback of the network adapter. I'm also registering >> a function method table so that I get a callback when the TCP connection >> is gone. >> >> A this point of development I would like to get some feedback from >> FreeBSD network guys about my attached patch proposal. >> >> The motivation for this work is to have a more reliable TCP >> transmissions typically for fixed-rate media content going some >> distance. To illustrate this I will give you an example from the world >> of VoIP, which is using UDP. When doing long-distance VoIP calls through >> various unknown networks and routers it makes a very big difference if >> you are sending data 20ms apart or 40ms apart, even at the exact same >> rate. In the one case you might experience a bunch of packet drops, and >> in the other case, everything is fine. Why? Because the number of >> packets you send per second, and the timing is important. The goal is to >> apply some timing rules for TCP, to increase the factor of successful >> transmission, and to reduce the amount of data loss. For high throughput >> applications we want to do this by means of hardware. >> >> >> While at it I would like to "typedef" the flowid used by mbufs, "struct >> inpcb" and many more places. Where would the right place be to put such >> a definition? In "sys/mbuf.h"? >> >> >> Comments are appreciated! > > I think we need to design this to be as generic as possible. I have > quite a bit of code that does this stuff but I haven't pushed it > upstream or even offered it for review (yet). > Hi, When will the non hardware related patches be available for review? I understand there are multiple ways to reach the same goal, and I think it would be great if we could agree on a common API for applications. --HPS