On Sat, Nov 06, 2010 at 04:07:22PM +0200, Julian Anastasov wrote: > > Hello, > > On Sat, 6 Nov 2010, Simon Horman wrote: > > >I wonder if we could just remove the modular aspect of persistence engines > >as there is currently only one module and no plans on the drawing board > >for any more at this time. That is, compile ip_vs_pe_sip directly > >into ip_vs.ko > > May be it is better svc to hold module refcnt for > PE as currently implemented. If in backup the svc and dest > are not found when creating connection with PE data then just > ignore the connection. As far as I understand, the svc and dest existing hasn't really been a requirement for syncrhonisation, except in corner cases. Personally I think thats a good thing. But making it a requirement would certainly simplify things. > The PE name must match the PE attached > to svc (ip_vs_find_dest). This check must exist. The benefit > comes from the fact that svc is freed after all its connections > are freed, cp->dest->svc is always valid. Then there is no > need for cp->pe. ip_vs_conn_hashkey_conn() has checks for > cp->dest, so there is no point to try to create synced > connections in backup with PE but without cp->dest. But dest could be created as part of failover and thus exist by the time any packets need to be forwarded, right? There are cases, such as where the backup is also a real-server that its rather inconvenient for svc and dst to exist while synchronisation information is being received. > The benefits: > > - no cp->pe, it is not needed, the persistent scheduler > gets PE from svc, i.e. PEs are needed only during > scheduling, so svc, PE and dest are present > > - PEs can be modular These are clear wins. But I think that we need to think carefully when deciding that svc and dest must exist on the backup for successful synchronisation. -- 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
