xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Wei Liu <Wei.Liu2@citrix.com>
To: Rohit Damkondwar <genius.rsd@gmail.com>
Cc: wei.liu2@citrix.com, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: dynamically set bandwidth limits of a virtual interface
Date: Mon, 31 Dec 2012 11:30:26 +0000	[thread overview]
Message-ID: <1356953426.2917.36.camel@iceland> (raw)
In-Reply-To: <CAHEEu860f4g7vZ0+hHXBtXe95J+7d33OzW9kJ2x5O2au6q3zHA@mail.gmail.com>

On Sun, 2012-12-30 at 12:08 +0000, Rohit Damkondwar wrote:


>         TBH I'm not sure about this either. Again, comparisons and
>         analysis of
>         bottleneck would be helpful.
>         
>         >
>         > I have seen  function "set_qos_algorithm_type" and
>         paramaters
>         > (qos/algorithm type,qos/algorithm params, qos/supported
>         algorithms) in
>         > vif class. Would they be useful ? Are they available only
>         for XEN
>         > Enterprise ?
>         >
>         
>         
>         Do you see those in libxen source code? I don't think they are
>         in use
>         now.
> I didn't know that. The when which library should I look into? I could
> find vif class in libxen folder. So I thought it should be used. I
> read that xl is not matured enough in xen 4.1.3. So which library
> should I look into? Please help. 

There is considerable amount of work to be done.

Tool stack is relatively easy. You can try adding config options to
whatever tool stack you're using. You need to parse the config option
(which is easy, because every tool stack has parser), then write the
option to xenstore so that guest can pick it up.

To modify the kernel is a bit harder. Download kernel package, look for
netback.c and friends, whose location varies depending the kernel you're
using. Grep for 'rate' so that you can have a look at how tx rate limit
is implemented.

The last bit is to upsteam your changes. Please post your changes to
Xen-devel to see if it is suitable for upstreaming. Of course this is
not mandatory. By upstreaming your changes you can 1) relieve your
maintenance burden, 2) benefit others.


Wei.

      reply	other threads:[~2012-12-31 11:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-27  8:46 dynamically set bandwidth limits of a virtual interface Rohit Damkondwar
2012-12-27 12:33 ` Wei Liu
2012-12-27 12:38   ` Pasi Kärkkäinen
2012-12-31 14:14     ` Alex Bligh
2012-12-28  7:46   ` Rohit Damkondwar
2012-12-28 10:35     ` Wei Liu
2012-12-30 12:08       ` Rohit Damkondwar
2012-12-31 11:30         ` Wei Liu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1356953426.2917.36.camel@iceland \
    --to=wei.liu2@citrix.com \
    --cc=genius.rsd@gmail.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).