Re: [PATCH 00/26] IPVS: Add first IPv6 support to IPVS.

To: Julius Volz <juliusv@xxxxxxxxxx>
Subject: Re: [PATCH 00/26] IPVS: Add first IPv6 support to IPVS.
Cc: Simon Horman <horms@xxxxxxxxxxxx>, Vince Busam <vbusam@xxxxxxxxxx>, Ben Greear <greearb@xxxxxxxxxxxxxxx>, lvs-devel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx
From: Patrick McHardy <kaber@xxxxxxxxx>
Date: Wed, 18 Jun 2008 16:19:54 +0200
Julius Volz wrote:
On Wed, Jun 18, 2008 at 10:57 AM, Patrick McHardy <kaber@xxxxxxxxx> wrote:
As I mentioned above, you usually want a MASK in combination
with flags to allow to unset them. This is best done using
a structure.

Hm, I'm not sure if I understand exactly what this struct is supposed
to look like. Could you give an example?

struct {
  u32 flags;
  u32 mask;
} flags;

and then:

obj->flags = (obj->flags & ~flags->mask) |
                  (flags->flags | flags->mask);

Ah, I see. The second line should read "(flags->flags & flags->mask)", right?


Looking at how these "flags" are actually used in ipvsadm, I'm not
sure this would be needed here:

1) destination conn_flags are only set to successive integer values 0,
1, 2... (depending on the forwarding method), which are mutually
exclusive. Only internally in the kernel are other bits of this field
used in a flag-like fashion. So this Netlink attribute could be
renamed to something like *_FWD_METHOD and be a normal value field.

Yes. The internal fields shouldn't be exported to userspace
unless necessary.

2) for the service flags, only one bit is set from userspace
(persistent/nonpersistent service). So this might be not too bad to
have as a single Netlink flag attribute.

And this bit can't be unset (or if it currently can't be,
it also wouldn't make sense to be able to unset it)?
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

<Prev in Thread] Current Thread [Next in Thread>