Very slow routing table modification if RTA_FLOW is set

Very slow routing table modification if RTA_FLOW is set

[NetArt - Grzegorz Nosek]

Hello all,

I have noticed that using realm patch for quagga
<http://vcalinus.gemenii.ro/quaggarealms.html> causes the kernel to
spend a lot more time processing rtnetlink messages.

If routes added to the kernel are not tagged with a realm number, the
time from sending a netlink cmd to receiving an ack is mostly stable
at several dozen microseconds or less.

However, if I add route tagging with 'neighbor X.X.X.X realm
origin-as', the time spent in kernel:
1. seems to increase with the numer of FIB entries
2. is much more jittery

The net result is that after adding about 100k routes, the time between
cmd and ack is usually around 4 _milli_seconds, but sometimes the
route is added immediately (i.e. after 20 us or so), just like when
the table is nearly empty. Overall, the process of receiving a full
routing table slows down from a minute to about 11.

The kernel is 2.6.18.6. I have tried using both FIB_HASH and FIB_TRIE.
I'll try to collect dome results from oprofile next and if anything
pops out at me, I'll let you know.

The core of the quagga patch with regard to the kernel is:

  if (rib->realmto)
      addattr32 (&req.n, sizeof req, RTA_FLOW, rib->realmto);

while constructing the netlink packet.

Is this a known problem? Can anything be done about it?

Please CC as I'm not subscribed to the list.

Best regards,
 Grzegorz Nosek

Re: Very slow routing table modification if RTA_FLOW is set

[David Miller]

From: NetArt - Grzegorz Nosek <grzegorz.nosek@netart.pl>
Date: Thu, 1 Mar 2007 15:29:11 +0100

> I have noticed that using realm patch for quagga
> <http://vcalinus.gemenii.ro/quaggarealms.html> causes the kernel to
> spend a lot more time processing rtnetlink messages.

Please report networking problems to the networking development
list which is netdev@vger.kernel.org, thank you.

Most networking developers do not read linux-kernel.

Re: Very slow routing table modification if RTA_FLOW is set

[David Miller]

From: NetArt - Grzegorz Nosek <grzegorz.nosek@netart.pl>
Date: Thu, 1 Mar 2007 15:29:11 +0100

> I have noticed that using realm patch for quagga
> <http://vcalinus.gemenii.ro/quaggarealms.html> causes the kernel to
> spend a lot more time processing rtnetlink messages.

For the second time, I am going to ask you very nicely to
please post this instead to the Linux networking development
mailing list, located at netdev@vger.kernel.org

That is where you will reach the most people knowledgable in
the area of your problem report, networking developers mostly
do not read linux-kernel

Thank you.

Very slow routing table modification if RTA_FLOW is set

[NetArt - Grzegorz Nosek]

Hello all,

I have noticed that using realm patch for quagga
<http://vcalinus.gemenii.ro/quaggarealms.html> causes the kernel to
spend a lot more time processing rtnetlink messages.

If routes added to the kernel are not tagged with a realm number, the
time from sending a netlink cmd to receiving an ack is mostly stable
at several dozen microseconds or less.

However, if I add route tagging with 'neighbor X.X.X.X realm
origin-as', the time spent in kernel:
1. seems to increase with the numer of FIB entries
2. is much more jittery

The net result is that after adding about 100k routes, the time between
cmd and ack is usually around 4 _milli_seconds, but sometimes the
route is added immediately (i.e. after 20 us or so), just like when
the table is nearly empty. Overall, the process of receiving a full
routing table slows down from a minute to about 11.

The kernel is 2.6.18.6. I have tried using both FIB_HASH and FIB_TRIE.
I'll try to collect dome results from oprofile next and if anything
pops out at me, I'll let you know.

The core of the quagga patch with regard to the kernel is:

  if (rib->realmto)
      addattr32 (&req.n, sizeof req, RTA_FLOW, rib->realmto);

while constructing the netlink packet.

Is this a known problem? Can anything be done about it?

Please CC as I'm not subscribed to the list.

Best regards,
 Grzegorz Nosek