|
Hello,
On Tue, 26 Oct 2010, Hans Schillstrom wrote:
Type: is one of this four
-IPv4
-IPv6
-IPv4 with PE data
-IPv6 with PE data
I'm thinking of different way to provide parameters. If before
now ip_vs_sync_conn_options uses cp->flags & IP_VS_CONN_F_SEQ_MASK
to check for present data now we can allow optional parameters
in such form:
- 1 octet length to next parameter: N
- 1 octet type: IPv4_Addresses, IPv6_Addresses, PE_Data, TCP_Seqs
- N-2 octets for data
The cost is 2 extra octets per parameter data and
that alignment is 2 octets, we must use memcpy for the
addresses.
By this way later we can add more parameters. If we
want master to specify that some parameter is optional
we can allocate 1 bit (bit 7) in 'type' for this. Most
of the parameters must be supported by backup server.
If backup does not recognize some type it will skip the
connection entry if bit 7 is not set.
While parsing the parameters we can set some bits
in local var to detect what params are received: only one of
IPv4_Addresses and IPv6_Addresses, etc.
FWMARK can be added in this way but may be it
is better to be in the mandatory structure.
The only problem is that it is difficult to
predict the entry size in ip_vs_sync_conn().
Also, we should add new define that will mask
all connection flags not supported by backup. Currently,
only IP_VS_CONN_F_HASHED is ignored:
#define IP_VS_CONN_F_BACKUP_MASK (IP_VS_CONN_F_FWD_MASK | \
IP_VS_CONN_F_NOOUTPUT | \
IP_VS_CONN_F_INACTIVE | \
IP_VS_CONN_F_SEQ_MASK | \
IP_VS_CONN_F_NO_CPORT | \
IP_VS_CONN_F_TEMPLATE | \
)
may be IP_VS_CONN_F_ONE_PACKET does not need to
be used in backup and master does not need to sync it.
Ver. Version of specified type right now it's 0
fwmark: Firewall mark from skb.
Is it really needed fwmark to be added in
struct ip_vs_conn_param? May be adding new argument just
to ip_vs_conn_new is enough?
timeout: from ip_vs_conn struct.
May be timeout must be in seconds, in case both
boxes use different HZ.
PATCH STATUS:
- Persistence data is not tested.
QUESTIONS:
In ip_vs_nfct.c
ip_vs_conn_fill_param() fwmark is set to 0,
Do we need to digg for it there ?
(It is a callback from ct ..)
There is no ip_vs_conn_new in ip_vs_nfct.c, so it will
be simpler if fwmark is not added to struct ip_vs_conn_param
Regards
--
Julian Anastasov <ja@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
| 