[Xorp-users] Multiple xorp instances performance improvements.

[Pavlin Radoslavov]

Ben Greear <greearb at candelatech.com> wrote:

> It appears that each Xorp instance effectively listens for all xorp
> related packets on all interfaces.  It does filter out the packets that
> are received on interfaces it is not configured for, but that is a lot
> of work.

I presume you are talking about the raw IP interface.

> If we are talking about 10 or 100 xorp instances, then each router packet
> is going to wake 10 or 100 processes (9 or 99 of which don't care),
> causing serious performance penalty.

This might or might not be the case, but I wouldn't call that
"serious performance penalty" without doing some profiling or
measurements that quantify it.

> How hard would it be to make Xorp bind only to the interfaces it
> cares about (for reading, at least)?  I think the write socket can
> remain as it is...

There is a trade-off.
By doing something like this you need to create and bind a receiving
socket for each configured IP address (even in the case when an
interface has 2+ alias IP addresses). If there is a huge number of
configured interfaces/addresses (e.g., think 1000 virtual tunnel
interfaces), this will eat up lots of socket resources. For example,
if each socket is configured with 256KB kernel buffer space, then
you need total of 256MB buffer space which is a lot!

> If nothing else, we might could add a bpf filter to the incoming socket
> so that the kernel discards the non-interesting packets and does not bother
> waking the xorp processes that don't care...

I don't think you can apply BPF filters on raw IP sockets.

If you are thinking about link-layer I/O, actually the link-raw
pcap-based I/O sockets are created and "bind" per interface (simply
because the pcap API mandates that).
Hence, if you really worry about waking up the processes, then you
could try using the link-based I/O sockets. Though, I wouldn't
recommend that for raw IP purpose, because you would end-up doing
lots of extra stuff.

In any case, my feeling is that the extra overhead of waking-up the
FEAa when there are 10 XORP instances is going to be pretty small.
If you are considering 100 XORP instances, the bottleneck probably
is going to be somewhere else (e.g., memory usage or control packet
processing in the protocol modules themselves).

Though, in general I'd say to hold back premature optimizations
until it is clear the optimization is necessary.

Regards,
Pavlin

> Thanks,
> Ben
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users