[Xen-devel] Re: [PATCH] Netchannel2 optimizations [2/4]

[Steven Smith <steven.smith@xxxxxxxxxx>]

> > > A possible fix to this issue is to set the event request 
> > flag when we 
> > > send a packet and the sender socket buffer is full.  I just did not 
> > > have the time to look into the linux socket buffer code to 
> > figure out 
> > > how to do that, but it should not be difficult once we 
> > understand the 
> > > code.
> > I'm not convinced by this fix.  It'll certainly solve the 
> > particular case of a UDP blast, but I'd be worried that there 
> > might be some other buffering somewhere, in e.g. the queueing 
> > discipline or somewhere in iptables.  Fixing any particular 
> > instance probably wouldn't be very tricky, but it'd be hard 
> > to be confident you'd got all of them, and it just sounds 
> > like a bit of a rat hole of complicated and hard-to-reproduce bugs.
> > 
> > Since this is likely to be a rare case, I'd almost be happy 
> > just using e.g. a 1Hz ticker to catch things when they look 
> > like they've gone south.  Performance will suck, but this 
> > should be a very rare workload, so that's not too much of a problem.
> > 
> > Does that sound plausible?
>   Yes, a low frequency periodic timer is a good idea.
Okay, there's now a 1Hz ticker which just goes and prods the ring if
there are any messages outstanding.  As expected, performance is dire
if you're relying on it to actually force packets out (~180 packets a
second), but it does avoid the deadlock.

I've also added a (very stupid) adaptation scheme which tries to
adjust the max_count_frags_no_event parameter to avoid hitting the
deadlock too often in the first place.  It seems to do broadly the
right thing for both UDP floods and TCP stream tests, but it probably
wouldn't be very hard to come up with some workload for which it falls
over.

>   We could also make the number of fragments that generate an event
> a configurable paramenter that it could be adjusted (right now it is
> an constant). So a sys admin would have an option to configure it
> with a value compatible with the default socket buffer. What about
> combining the timer with a configurable parameter?
I guess it wouldn't hurt to make this stuff configurable, although I
think you may be overestimating the average sysadmin if you think
they're going to know the default socket buffer size (hell, *I* don't
know the default socket buffer size).

Steven.

signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel