James Carlson wrote: > The table that I know about is in here: > > > http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/~checkout~/src/usr.bin/netstat/netstat.1?rev=1.51&content-type=text/plain > > ... and it maps RTF_CLONING to 'C' and RTF_CLONED to 'c'. I don't > know of a flag that maps to 'W', but I guess it's possible that was > done on some system.
Ah - I looked at freebsd at http://www.freebsd.org/cgi/man.cgi?query=netstat&apropos=0&sektion=0&manpath=FreeBSD+7.2-RELEASE&format=html which has different flags: C RTF_CLONING Generate new routes on use c RTF_PRCLONING Protocol-specified generate new routes on use W RTF_WASCLONED Route was generated as a result of cloning > Lining up with BSD would be a nice thing, if possible, but if we have > to be different, I wouldn't complain too much. Which BSD seems to be the key question ;-) I'll stick with 'C'. >> Note that right now the refactor-gate implementation for local >> connections doesn't have visibility to the port numbers when it does the >> ECMP behavior. We'd to fix that to get better spreading. > > I'm not sure I follow. I thought that the selection mechanism for > local connections was described as round-robin. How would port > numbers or any ECMP get involved with that? Where is it described as round-robin? In my email where I said "currently the kernel only does some form of round robin for default routes"? The issue is that we don't want the implementation to pick a different route just because some unrelated route change caused a need to revalidate the ire cached for the connection. We do this by having a predictable implementation. My point was that that algorithm can be improved. > (I agree that if you're doing ECMP, the more flow-identifying stuff > you can get in there, the better. But that might be tending towards > design review ...) I think we already crossed that line on this particular topic ;-) >> Not enough hours in a day, and I don't want to spend those few hours on >> debating whether or not Cassini is the best Ethernet driver ever. >> (As far as I know Cassini is the only driver that uses multidata.) > > At least to me, that's not quite the point. We're _breaking_ that > previous feature by permanently disabling it. I think that may well > be a good thing -- I can believe that we get acceptably good > performance without the complication of MDT -- but I don't think it's > useful to say that those things are still "supported" but simply never > work. In which sense is it a feature? It is just a performance trick with a contract private interface. Given that the trick now cost more in support complexity than its benefits, why are we not free to stop using that trick? > Would we say we "support" LSO but then never allow anyone to use it? Do we claim to support MDT? I don't see what that would mean given that the interfaces are contract private, hence no ISV/IHV should use them. > I think doing this cleanly means obsoleting those old interfaces > properly. I do not see any harm in keeping the MDT interfaces in place so that the Cassini driver binaries continue to load into the kernel and work properly. Once Cassini is EOLed we can remove all vestiges of the MDT from the system, but removing it earlier implies addition cost to the business (maintaining another version of the Cassini driver) which doesn't seem warranted. But if you are going to block this case on this issue, then I would be forced to go spend the time to start the EO*L process. Erik
