lars.ellenberg at linbit
Jul 31, 2012, 12:58 AM
Post #2 of 4
On Mon, Jul 30, 2012 at 02:02:38PM -0600, Alan Robertson wrote:
Re: Probable "sub-optimal" behavior in ucast
[In reply to]
> I have a 10-node system with each system having 2 interfaces, and
> therefore each ha.cf file has 18 ucast lines in it.
> If I read the code correctly, I think each heartbeat packet is then
> being received 18 times and sent to the master control process -
> where each is then uncompressed and 17 of them are thrown away...
> Could someone else offer your thoughts on this?
> It looks to be a 2 or 3 line fix in ucast.c to thrown away ucast
> packets that aren't from the address we expect - which would cut us
> down to only one of them being sent from each of the interfaces - a
> 9 to 1 reduction in work on the master control process. And I don't
> have to uncompress them to throw them away - I can just look at the
> source IP address...
> What do you think?
Besides that a ten node cluster is likely to break the 64k message size
limit, even after compression...
You probably should re-organize the code so that you only have
one receiving ucast socket per nic/ip/port.
But I think that a single UDP packet will be delivered to
a single socket, even though you have 18 receiving sockets
bound to the same port (possible because of SO_REUSEPORT, only).
If we, as I think we do, receive on just one of them, where which one is
determined by the kernel, not us, your suggested ingress filter on
"expected" source IP would break communications.
Do you have evidence for the assumption that you receive incoming
packets on all sockets, and not on just one of them?
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
Linux-HA-Dev: Linux-HA-Dev [at] lists
Home Page: http://linux-ha.org/