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. --HPSReceived on Wed Jul 09 2014 - 12:36:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:50 UTC