All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zoltan Kiss <zoltan.kiss@linaro.org>
To: Ronald PIna <pinaronald@gmail.com>, xen-devel@lists.xen.org
Subject: Re: Request for help, implementing a new network scheduler
Date: Tue, 03 Feb 2015 11:54:37 +0000	[thread overview]
Message-ID: <54D0B6FD.4060307@linaro.org> (raw)
In-Reply-To: <54D01961.4090209@gmail.com>



On 03/02/15 00:42, Ronald PIna wrote:
> Hi
>
> I am working for the msc thesis to improve the performance on network
> for guest domains that uses real-time services like voip or video
> streaming servers , i have an idea to implement a network scheduler on
> network backend, the schedulers may be weighted fair queuing or weighted
> round robin,  the idea is to schedule first the packet coming from
> real-time guest services, one of those schedulers could make the job and
> can prioritize the network traffic.
>
> As far as i have studied from previous works explain that the outgoing
> network traffic in xen is scheduled in round robin manner inside the
> function net_tx_action(). Later on the last version of xen this function
> has changed xenvif_tx_action() and have changed his primarily structure.
> My primarily goal is to modify the round robin to more advanced
> scheduler  which introduce priorities. The clear question is that where
> is located the function which schedule in round robin and if possible
> are there any concern about using another network scheduling method in
> netback ?
xenvif_tx_action is called from NAPI polling context, per queue. It 
copies & maps the packets from the guest to Dom0 (at which point it 
doesn't have the slightest idea about the packet content), formats them 
in xenvif_tx_submit to be a well formed skb, and calls netif_receive_skb 
to hand it over to the stack.
You could try doing some reordering in xenvif_tx_submit or introducing 
priorities in the ring buffer, but I would strongly discourage you to do 
that, for similar reasons mentioned by Ian. You would be better off 
using standard Linux tools for doing that, see 'man tc', and I would try 
on the sending side, in the guest, before netfront gets the packet.
Or, if your idea is to prioritize between traffic coming from separate 
guests, then xenvif_tx_action is definitely the wrong place to do that: 
as said above, it deals only with the traffic of one particular queue of 
a netback device. You might want to look into the entity 
switching/routing between the guests and NICs: Linux bridge module, 
openvswitch, the IP routing engine of the backend etc. I think the first 
two could be the reasonable choices, bridge might lacks such 
functionality though.

Zoli


>
> Thanks in advance
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

  parent reply	other threads:[~2015-02-03 11:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-03  0:42 Request for help, implementing a new network scheduler Ronald PIna
2015-02-03 11:05 ` Wei Liu
2015-02-03 11:12   ` Ian Campbell
2015-02-03 20:19     ` ronald pina
     [not found]   ` <CAONBAaei_fdGcwb=AhSZJZCMzrYrs_q1ifjP5d6OkQx+71HXfg@mail.gmail.com>
2015-02-04 10:54     ` Wei Liu
2015-02-03 11:54 ` Zoltan Kiss [this message]
2015-02-03 19:55   ` ronald pina
2015-02-04 11:42     ` Zoltan Kiss

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=54D0B6FD.4060307@linaro.org \
    --to=zoltan.kiss@linaro.org \
    --cc=pinaronald@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.