James Carlson wrote:
> You said this:
>
> The project extends the kernel's ability to handle multiple routes for the
> same
> prefix; currently the kernel only does some form of round robin for default
> routes and the project extends that to all off-link routes (default,
> prefix, and
> host routes).
>
> That text appears to say directly that you're extending the existing
> round-robin behavior seen for default routes to all off-link routes.
>
> Is that not true?
The key is "some form" - currently we don't actually specify that the
current default route logic is round-robin, nor do we specify when we
actually (re)select one of the default routes. (The implementation can
actually re-select each time it runs low on memory, when the IRE_CACHE
bucket gets too long, or when routes or interfaces are added or deleted.)
>> 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.
>
> OK. Hashed IDs instead of round-robin is certainly fine by me. If
> you go back through the thread, I was just trying to find out exactly
> what the feature was (and wasn't) supposed to do. Nothing more.
Understood.
But it leads to the question at what detail we should document the
behavior of the new implementation. We want to be helpful to users
wanting to understand things, without preventing us from evolving the
implementation to do better load spreading over time.
>>> 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?
>
> The IP stack has a contract extended to 'ce' to use it.
Can you point out where in the contract it says that TCP/IP will use MDT
in any particular case? I see interfaces for the driver to specify to IP
that the driver can handle MDT, and a format (M_MULTIDATA) plus
supporting data structures and functions that the driver can use to
handle M_MULTIDATA. But there isn't anything that requires TCP/IP to use
MDT in any particular case.
If we look at the implementation there are a large number of conditions
that apply to MDT.
- It is never used with SCTP.
- TCP turns it off if there are IPv4 options, IPv6 extension headers,
IPsec, to IPQoS
- Not used with RTF_MULTIRT
My point is that the driver can not assume that any particular packet
will use MDT today. Thus I can't see how it would be an interface change
to reduce the set of cases when TCP/IP sends down M_MULTIDATA to the
driver to the null set.
> I'm not asking about removal of the functions. I agree that'd be
> quite foolish. It'd break at least the 'ce' driver and do so in
> violation of the agreed-on contract and for no apparent benefit. But,
> as I said, I'm not asking for that at all. (Nor do I understand why
> anyone would think I'd ask for breakage like that or that by asking
> questions I'd somehow "block this case." I never said any such
> things.)
>
> What I am asking for is *merely* documentation. Please explicitly say
> that this project retires those previous projects (the ARC cases
> themselves). You could do so by:
I sure wish you would have stated that up front! Would have saved some
time for all of us.
> - Explicitly stating that the interfaces specified in those previous
> projects are now Obsolete.
>
> - Going through the process of notifying the contract holders that
> the interfaces are going away.
>
> That's all. It shouldn't be this hard.
Will do.
I'll send out an updated writeup shortly.
Erik
