Re: [RFC] Add support for changing the flow ID of TCP connections

Hi!

The flowid value has way, way too many possible meanings but it's
always been a mostly-static value. I'm worried about overriding it
with multiple meanings that cause features to not work at all
together.

So I'd rather leave the flowid/flowtype as it currently is so it
doesn't upset packet reordering and can be used by things like RSS for
scaling, and instead introduce a new connection ID to be used for your
purpose. That way the existing use of flowid for packet ordering and
flowid/flowtype for doing network scaling and netisr selection can
work together with your connection id requirements.

Having stack support for hardware/firmware packet scheduling is cool.
It seems to somewhat overlap with other parts of the TCP offload
though and I'm concerned about bloating out inpcb by 3 pointers for
each connection where lots of connections on the same NIC will point
to the same function set or NULL.

I'd hit up what others in this space are doing. There's pacing support
in the chelsio NIC for example and I'm not sure what Navdeep's plans
are for that in upstream FreeBSD.

Other than that, cool!



-a


On 8 July 2014 10:46, Hans Petter Selasky <hps_at_selasky.org> 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!
>
> --HPS
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"