All of lore.kernel.org
 help / color / mirror / Atom feed
From: David L Stevens <david.stevens@oracle.com>
To: Raghuram Kothakota <Raghuram.Kothakota@oracle.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCHv6 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6
Date: Mon, 22 Sep 2014 00:40:27 -0400	[thread overview]
Message-ID: <541FA83B.2050608@oracle.com> (raw)
In-Reply-To: <541B395D.1000809@oracle.com>



> On 09/18/2014 02:49 PM, Raghuram Kothakota wrote:

>> In the virtualization world, we want resources to be efficiently used and memory is
>> still very important resource. My concern is mostly because this memory usage of
>> 32+MB is on a per LDC basis. LDoms today supports a max of 128 domains, but
>> from my experience seen actual deployments of the order of 50 domains. This is
>> going up as the platforms getting more and more powerful.  If there are really
>> that many peers,  then the amount of memory consumed by one vnet instance
>> is 50 * 32+MB = 1.6GB+.  It's fine if this memory is really used, but it seems like this
>> will be useful only when the peer is another linux guest with this version of vnet and
>> also the MTU is configured to use 64K.  The memory is being wasted for all other
>> peers that either don't support 64K MTU or not configured to use it and also 
>> the switch port as obviously it doesn't support 64K MTU today.

I think I have a solution for this -- I'm doing some experimenting, but it may be a few days.

However, fundamentally, the problem is that there are n^2-n links both ways, so 50 LDOMs on the same vswitch
will always be 2450X the resources of a single pair, and lead to scary aggregate numbers. Large installations
really need more vswitches with fewer LDOMs per switch, at least with the current code.

								+-DLS

  reply	other threads:[~2014-09-22  4:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18  0:11 [PATCHv6 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6 David L Stevens
2014-09-18  4:09 ` Raghuram Kothakota
2014-09-18 13:03   ` David L Stevens
2014-09-18 18:49     ` Raghuram Kothakota
2014-09-18 19:58       ` David L Stevens
2014-09-22  4:40         ` David L Stevens [this message]
2014-09-22 16:40           ` Raghuram Kothakota
2014-09-23 16:24     ` David Miller
2014-09-23 16:49       ` David L Stevens
2014-09-23 18:44         ` David Miller
2014-09-24 14:43           ` David L Stevens
2014-09-18  4:23 ` Raghuram Kothakota
2014-09-18 13:21   ` David L Stevens

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=541FA83B.2050608@oracle.com \
    --to=david.stevens@oracle.com \
    --cc=Raghuram.Kothakota@oracle.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.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.