All of lore.kernel.org
 help / color / mirror / Atom feed
* Very slow routing table modification if RTA_FLOW is set
@ 2007-03-01 14:29 NetArt - Grzegorz Nosek
  0 siblings, 0 replies; 4+ messages in thread
From: NetArt - Grzegorz Nosek @ 2007-03-01 14:29 UTC (permalink / raw)
  To: linux-kernel

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


^ permalink raw reply	[flat|nested] 4+ messages in thread
* Very slow routing table modification if RTA_FLOW is set
@ 2007-03-01 14:29 NetArt - Grzegorz Nosek
  2007-03-01 18:35 ` David Miller
  2007-03-02 19:28 ` David Miller
  0 siblings, 2 replies; 4+ messages in thread
From: NetArt - Grzegorz Nosek @ 2007-03-01 14:29 UTC (permalink / raw)
  To: linux-kernel

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-03-02 19:28 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-01 14:29 Very slow routing table modification if RTA_FLOW is set NetArt - Grzegorz Nosek
2007-03-01 14:29 NetArt - Grzegorz Nosek
2007-03-01 18:35 ` David Miller
2007-03-02 19:28 ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.