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

["Santos, Jose Renato G" <joserenato.santos@xxxxxx>]

> -----Original Message-----
> From: Steven Smith [mailto:steven.smith@xxxxxxxxxx] 
> Sent: Tuesday, February 17, 2009 9:56 AM
> To: Santos, Jose Renato G
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Steven Smith
> Subject: Re: [PATCH] Netchannel2 optimizations [2/4]
> 
> > This patch uses the new packet message flag created in the previous 
> > patch to request an event only every N fragments. N needs 
> to be less 
> > than the maximum number of fragments that we can send or we may get 
> > stuck.  The default number of fragments in this patch is 
> 192 while the 
> > maximum number of fragments that we can send is 256.
> >
> > There is a small issue with this code. If we have a single 
> UDP stream 
> > and the maximum TX socket buffer size limited by the kernel in the 
> > sender guest is not sufficient to consume N fragments (192 for now) 
> > the communication may stop until some other stream sends packets in 
> > either the TX or RX direction. This should not be an issue with TCP 
> > since we willalway have ACKs being erceived what will cause 
> events to 
> > be generated. We will need to fix this sometime soon, but it is an 
> > unlikely scenario in practice that we may let the code get into the 
> > netchannel2 tree for now, especially because the code is still 
> > experimental. But Steven has the final word on that.
> I've applied the patch, along with the others in the series.  
> As you say, this isn't really good enough for a final 
> solution, as it stands, but it'll do for now.
> 
> > 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.
  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?

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