[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xen-netback: add a pseudo pps rate limit



On Mon, Jun 24, 2013 at 03:42:35PM +0200, William Dauchy wrote:
> Hi Wei,
> 
> Thanks for your reply.
> 
> On Jun24 11:14, Wei Liu wrote:
> > First question, can we achieve the same effect by using existing
> > facility in backend domain, say, tcng in Linux?
> 
> yes indeed, but it looks like way more complicated to configure; we
> thought it was a good option to manage it with the bandwitdh.
> Also, by using tcng, PPS shaping is done on backend level, once packet has
> left the VM; which means after using an additional memory transaction to copy
> packet from frontend. IMHO, at scale, shaping in this way should save some
> memory transactions comparing to tcng.
> 

OK, fair enough. :-)

> > It would be better if you can come up with patch for toolstack as well
> > -- the rate parameter is parsed in libxl (see
> > $XEN/tools/libxl/libxlu_vif.c) -- so that users of this parameter can
> > specify it in their VM config file. But that's another topic and deserve
> > another patch.
> 
> indeed; for now we do have a userland patch but using xend which is out
> of date; that's why we didn't send it along. Are you interested by it
> anyway?
> 

Patch for Xend, no. We're not supposed to add new functionality to it
anyway.

> > Hmm, the replenishing looks simple. I'm not sure if it's over
> > simplified. Could you look at the ring and determine the possible burst
> > value? (note that in the ring txreq != packet). Just my two cents.
> 
> we didn't had a look for now since we were eventually looking for some
> help (and time) on this subject.
> 

Better to wait for Ian Campbell or other interested people to weight in.

> > If you fail to parse "rate" you skip parsing "pps", is this intentional?
> 
> yes; PPS is linked to rate since they are checked within the same
> perdiod.
> "by using the same usecond period, PPS shaping depends on throughput shaping."
> 

It is just now we have two limits and backend should stop processing
when one of the limits is hit. And, if we're to have more limits in the
future (not sure if it is a good idea but let's just be open to this),
they should probably not be dependent on each other.

> Will resend with the small typo you picked.
> -- 
> William



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.