setting ICSK_CA_PRIV_SIZE larger than 16 * sizeof(u32)

setting ICSK_CA_PRIV_SIZE larger than 16 * sizeof(u32)

[Kiran Kotla]

Hi guys,

We have a recently implemented our Congestion control algorithm named
PERT (Probabilistic early response TCP), in the linux kernel.

As a part of it, we needed to define some variables in the private
variables part ( __u32 icsk_ca_priv[16] ) of per flow structure
(struct inet_connection_sock) in the file
"include/net/inet_connection_sock.h"

As you can see the limit on the number of private variables has been
imposed to 16 u32 variables. However, our protocol requires that we
have more than 16 say upto 25 u32 variables.
We tried changing the size of icsk_ca_priv from 16 to a larger value
and correspondingly changed the #define  ICSK_CA_PRIV_SIZE to a larger
value which was initially set to  "16 * sizeof(u32)".

We have searched the entire kernel code but did not find any other
dependency on the size of "icsk_ca_priv". We compiled the code and
rebooted the machine with the new image and we see a kernel crash
(Panic) at the very piece of code where this structure is being
initialized. We reset it back to 16 and it worked perfectly fine.

I just wanted to ask if there is a way to change the size of this
private variable array "icsk_ca_priv".

The only other option we have to get the kernel running with our
protocol is to reduce the number of private variables and this is not
possible without affecting the behavior of our protocol.

It would be great if someone of you who have used this structure
sometime shedded light on this.

Your replies are very well appreciated.

Thanks a ton in advance.

best wishes
Kiran Kotla

Re: setting ICSK_CA_PRIV_SIZE larger than 16 * sizeof(u32)

[David Miller]

From: "Kiran Kotla" <kotlakiran@gmail.com>
Date: Fri, 27 Jun 2008 03:37:59 -0500

[ Changed linux-net to netdev.  linux-net is for user questions,
  netdev is for development discussion... ]

> The only other option we have to get the kernel running with our
> protocol is to reduce the number of private variables and this is not
> possible without affecting the behavior of our protocol.

I severely doubt this.  25 32-bit state variables is just way
over the top.

Don't give up so easily.  Maybe some values can be 16-bit instead
of 32-bit.

Perhaps pairs of two odd-sized values can be encoded into a single
32-bit (one is 7 bits, the other is <= 25 bits).

Get creative.

I'm going to be very much an asshole about making that blob any
bigger, because it means every single socket in the kernel will get
bigger even if they don't use your congestion control algorithm.

Re: setting ICSK_CA_PRIV_SIZE larger than 16 * sizeof(u32)

[Kiran Kotla]

Hi david,

Thank you very much for your response. I am new to this forum and not
sure if I could include you in my reply.

Well, we tried our best to reduce the size of our private variables.

The major consumers of space however are two arrays of 32 bit integers
each of size '8', which are used to estimate drop probability and
early congestion response probability (our protocol specific), which
cannot be reduced to be 16 bit integers and further the size of the
array cannot be reduced to some value lesser without degrading the
estimation of drop probability.

I guess the only way left is to have a trade-off between the
performance of our protocol and size of the array.

In any case, I was wondering if still there is a way to increase the
size of the blob, though we would not to increase the size of blob to
get our protocol running in the kernel.

Thanks again!
Kiran

On Fri, Jun 27, 2008 at 4:30 AM, David Miller <davem@davemloft.net> wrote:
> From: "Kiran Kotla" <kotlakiran@gmail.com>
> Date: Fri, 27 Jun 2008 03:37:59 -0500
>
> [ Changed linux-net to netdev.  linux-net is for user questions,
>  netdev is for development discussion... ]
>
>> The only other option we have to get the kernel running with our
>> protocol is to reduce the number of private variables and this is not
>> possible without affecting the behavior of our protocol.
>
> I severely doubt this.  25 32-bit state variables is just way
> over the top.
>
> Don't give up so easily.  Maybe some values can be 16-bit instead
> of 32-bit.
>
> Perhaps pairs of two odd-sized values can be encoded into a single
> 32-bit (one is 7 bits, the other is <= 25 bits).
>
> Get creative.
>
> I'm going to be very much an asshole about making that blob any
> bigger, because it means every single socket in the kernel will get
> bigger even if they don't use your congestion control algorithm.
>

Re: setting ICSK_CA_PRIV_SIZE larger than 16 * sizeof(u32)

[Stephen Hemminger]

On Fri, 27 Jun 2008 16:20:10 -0500
"Kiran Kotla" <kotlakiran@gmail.com> wrote:

> Hi david,
> 
> Thank you very much for your response. I am new to this forum and not
> sure if I could include you in my reply.
> 
> Well, we tried our best to reduce the size of our private variables.
> 
> The major consumers of space however are two arrays of 32 bit integers
> each of size '8', which are used to estimate drop probability and
> early congestion response probability (our protocol specific), which
> cannot be reduced to be 16 bit integers and further the size of the
> array cannot be reduced to some value lesser without degrading the
> estimation of drop probability.
> 
> I guess the only way left is to have a trade-off between the
> performance of our protocol and size of the array.
> 
> In any case, I was wondering if still there is a way to increase the
> size of the blob, though we would not to increase the size of blob to
> get our protocol running in the kernel.
> 
> Thanks again!
> Kiran

If need be you can use a pointer to an allocated array for that (it would be
up to your code to free it).  You might even want to make this per route
rather than per socket. That would require lookup/locking/ref counting, but
it would allow sharing path information when multiple sockets along same
path are present.