LKML Archive on
help / color / mirror / Atom feed
* 2.2.19 poor speed creating/deleting interfaces
@ 2001-10-05 22:45 Alex Bligh - linux-kernel
  0 siblings, 0 replies; only message in thread
From: Alex Bligh - linux-kernel @ 2001-10-05 22:45 UTC (permalink / raw)
  To: linux-kernel; +Cc: Alex Bligh - linux-kernel

I am looking at a VRRP implementation which is problematic
on large numbers of interfaces. The configuration has
over 300 interfaces, which, each being on their own
VLAN of the same physical interface, tend to change
state at the same time.

The VRRP stuff runs mostly as a kernel thread, which
on a state change, causes the VRRP virtual interface
to be added/removed. It does this via a call to
devinet_ioctl (with normal segment kludges), and
on the virtual VLAN interface, and a SIOCADDMULTI(*) on
the main VLAN interface. On transition to VRRP backup,
it does the opposite (DELMULTI, the SOICIFFLAGS to
delete the interface).

It all works, but each interface addition / removal
takes over a tenth of a second. This isn't great
when you have over 300 of them and are trying to
do hot standby (>40 seconds for some VLANs is
not so hot).

I'm using Acenics, 2.2.19, patches for VRRP
VLAN, Acenic, to log rather less and not
try and load modules for VLAN interfaces.

Any idea what takes the time in interface
addition / removal and/or multicast addition / removal?

'All' the 300 odd kernel threads do is look
at a state machine, issue IOCTLs, queue
the odd packet, and call interruptible_sleep_on_timeout.
I would have thought the non-ioctl stuff should be efficient.

(*)=don't ask why I need to do this bit

Alex Bligh

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2001-10-05 22:45 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-05 22:45 2.2.19 poor speed creating/deleting interfaces Alex Bligh - linux-kernel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).