On Thu, 2012-07-19 at 06:45 -0400, Neil Horman wrote:
> On Wed, Jul 18, 2012 at 01:30:58PM -0700, Joe Perches wrote:
> > On Wed, 2012-07-18 at 14:01 -0400, Neil Horman wrote:
> > > I've seen several attempts recently made to do quick failover of sctp transports
> > > by reducing various retransmit timers and counters. While its possible to
> > > implement a faster failover on multihomed sctp associations, its not
> > > particularly robust, in that it can lead to unneeded retransmits, as well as
> > > false connection failures due to intermittent latency on a network.
[]
> > > @@ -878,12 +896,15 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
> > []
> > > + if (ulp_notify) {
> > > + memset(&addr, 0, sizeof(struct sockaddr_storage));
> > > + memcpy(&addr, &transport->ipaddr,
> > > + transport->af_specific->sockaddr_len);
> >
> > Perhaps it's better to do the memcpy then the memset of the
> > space left instead.
> >
> > memcpy(&addr, &transport->ipaddr, transport->af_specific->sockaddr_len);
> > memset((char *)&addr) + transport->af_specific->sockaddr_len, 0,
> > sizeof(struct sockaddr_storage) - transport->af_specific->sockaddr_len);
> >
> hmm, not sure about that. It works either way for me, but I've not changed that
> code, just the condition under which it was executed. I'd rather save cleanups
> like that for a separate patch if you don't mind.
Not a bit.
It's almost certain reversing the order is slower for v4
addresses anyway. It might be slower for v6 too given
the arithmetic.
cheers, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
