On 07/08/14 21:17, Navdeep Parhar wrote:
On 07/08/14 10:46, Hans Petter Selasky wrote:
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
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
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).
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"