From: Simon Horman <horms@verge.net.au>
To: Jesse Gross <jesse@nicira.com>
Cc: dev@openvswitch.org, "Michael S. Tsirkin" <mst@redhat.com>,
kvm@vger.kernel.org, virtualization@lists.osdl.org,
netdev@vger.kernel.org
Subject: Re: [ovs-dev] Flow Control and Port Mirroring
Date: Sat, 30 Oct 2010 11:59:33 +0900 [thread overview]
Message-ID: <20101030025932.GG12842@verge.net.au> (raw)
In-Reply-To: <AANLkTi=QXBi4wmJS1TY0P=s+11Vjp0v=AfWOdFb4vrCj@mail.gmail.com>
[ CCed VHOST contacts ]
On Thu, Oct 28, 2010 at 01:22:02PM -0700, Jesse Gross wrote:
> On Thu, Oct 28, 2010 at 4:54 AM, Simon Horman <horms@verge.net.au> wrote:
> > My reasoning is that in the non-mirroring case the guest is
> > limited by the external interface through wich the packets
> > eventually flow - that is 1Gbit/s. But in the mirrored either
> > there is no flow control or the flow control is acting on the
> > rate of dummy0, which is essentailly infinate.
> >
> > Before investigating this any further I wanted to ask if
> > this behaviour is intentional.
>
> It's not intentional but I can take a guess at what is happening.
>
> When we send the packet to a mirror, the skb is cloned but only the
> original skb is charged to the sender. If the original packet is
> delivered to localhost then it will be freed quickly and no longer
> accounted for, despite the fact that the "real" packet is still
> sitting in the transmit queue on the NIC. The UDP stack will then
> send the next packet, limited only by the speed of the CPU.
That would explain what I have observed.
> Normally, this would be tracked by accounting for the memory charged
> to the socket. However, I know that Xen tracks whether the actual
> pages of memory have been freed, which should avoid this problem since
> the memory won't be released util the last packet has been sent. I
> don't know what KVM virtio does but I'm guessing that it similar to
> the former, since this problem is occurring.
I am also familiar of how Xen tracks pages but less sure of the
virtio side of things.
> While it would be easy to charge the socket for all clones, I also
> want to be careful about over accounting of the same data, leading to
> a very small effective socket buffer.
Agreed, we don't want to see over-charging.
next parent reply other threads:[~2010-10-30 2:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20101028115403.GA16206@verge.net.au>
[not found] ` <AANLkTi=QXBi4wmJS1TY0P=s+11Vjp0v=AfWOdFb4vrCj@mail.gmail.com>
2010-10-30 2:59 ` Simon Horman [this message]
2010-11-08 3:11 ` [ovs-dev] Flow Control and Port Mirroring Rusty Russell
2010-11-08 4:59 ` Simon Horman
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=20101030025932.GG12842@verge.net.au \
--to=horms@verge.net.au \
--cc=dev@openvswitch.org \
--cc=jesse@nicira.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=virtualization@lists.osdl.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.