Ratelimit and rack

[rrs]

Summary

It is preferable to have the ratelimit option in rack, but we should
really allow rack to be built without it. The alternative to this
patch is to add to the ratelimit code and rack a module declare (like hpts)
so that rack will fail to build if you miss the option.

Test Plan

Make sure we can have rack (all the alternate stacks) and still build it
if RATELIMIT is not a configured option validate the kernel compiles.

[imp]

While #ifdefs are a bit ugly, I'm not sure there's a better, performant way to do this...

[tuexen]

Are there platforms we can't build the ratelimit code, but want to use rack?

[imp]

Actually, I changed my mind...

I think it would be better to fix this in tcp_ratelimit.h to have these functions return 0 for !RATELIMIT

[rrs]

Warner:

Ok thats another option too ;)

R

[rrs]

Lets take Warners alternative.. i.e. have the tcp_ratelimit code return 0 for the highest hw rate when
ratelimit is not in the kernel.

[imp]

Love it

[rrs]

It needs to be static and match the signature duhh

[rrs]

Lets get the right function here

[rrs]

Turns out I was wrong, we need both functions not just one.

[tuexen]

It is still not clear what problem we are solving here. On which platform can we not build a kernel with RATELIMIT but want to run RACK on?

[rrs]

Define a kernel that has all the TCP options to get the alternate
stacks but don't add RATELIMIT.

You will get the compile blowing up.

One of the PPC LINT images evidently fails to include RATELIMIT for some reason.

[tuexen]

In D30163#677390, @rrs wrote:

Define a kernel that has all the TCP options to get the alternate
stacks but don't add RATELIMIT.

I would consider that a configuration error.

You will get the compile blowing up.

One of the PPC LINT images evidently fails to include RATELIMIT for some reason.

It fails because it contains

nooptions RATELIMIT

and I think this is a bug in the configuration file. Is there a reason why we can't build
and use RATELIMIT on 32-bit PPC? I use it on 64-bit PPC.

Does FreeBSD have a policy that you can always compile a kernel, even with
invalid kernel configs? If that is the case, I'm fine with this change.
If not, I think we should fix kernel configs to be valid, but not add more
complexity to he configurations we support.

[imp]

Does FreeBSD have a policy that you can always compile a kernel, even with invalid kernel configs?

Generally, yes. The current failure mode is a bit opaque.

[imp]

In D30163#677462, @imp wrote:

Does FreeBSD have a policy that you can always compile a kernel, even with invalid kernel configs?

Generally, yes. The current failure mode is a bit opaque.

Especially since this is a module build error... This is the least painful way to fix that, though not building the module for illegal kernel configurations is the other option had this hack not been so easy.

[tuexen]

In D30163#677462, @imp wrote:

Does FreeBSD have a policy that you can always compile a kernel, even with invalid kernel configs?

Generally, yes. The current failure mode is a bit opaque.

Ahh, OK. I wasn't aware of that. Then I'm fine with this change.

[tuexen]

In D30163#677463, @imp wrote:

In D30163#677462, @imp wrote:

Does FreeBSD have a policy that you can always compile a kernel, even with invalid kernel configs?

Generally, yes. The current failure mode is a bit opaque.

Especially since this is a module build error... This is the least painful way to fix that, though not building the module for illegal kernel configurations is the other option had this hack not been so easy.

I just test building RACK without TCPHPTS. I builds just fine a module, which can't be loaded. So the user will detect the configuration error, just not when building the code, but when trying to use the code. So being able to build RACK without RATELIMIT is consistent.