From: John Heffner <jheffner@xxxxxxx> Date: Thu, 22 Sep 2005 11:14:10 -0400 > I remember this was discussed a while ago but never came about. I > think it makes a lot of sense. I tend to agree, it's just the implementation that I worry about. > > But it should not be much more than adding a new value to RTM_METRICS, > > and a dst_metrics() lookup at the appropriate place plus additions to > > iproute to allow the value to be sent to the kernel, but there is > > complications in that the current RTM_METRICS is all based arount > > integers while the congestion control algorithms is all named by > > strings. But on the other hand this probably should be changed for > > efficiency anyway if doing this as doing a string based lookup for the > > congestion control algorithm on each new tcp connection is probably > > not wanted. > > There doesn't seem to be a really clean way to do this, but I was > thinking of an approach where you could have a table of congestion > controllers exposed via /proc, then the dst cache specifies the index > into that table. As modules are loaded and unloaded, the indices change and thus change meaning while still potentially active in a bunch of DSTs. We could store pointers to the congestion control algorithm in the DST, and pass the RTNETLINK route attribute in as a string with a fixed max length. We would need to enforce this max string length in the congestion control algorithm registry as well. Any takers to code this up? :-) - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
